Checkout is where intent becomes revenue. This guide covers payment providers, checkout fields, taxes and shipping, and a go-live checklist so you launch without silent payment failures or surprise totals at the last step.
Prerequisites: a Commerce store with at least one purchasable SKU, sandbox credentials for your card processor, and clarity on the regions you sell to.
Providers
Connect card processors and wallets from Commerce Payments. Use sandbox credentials on preview; promote live keys only after a successful test order. Prefer providers with strong 3-D Secure / SCA support in your markets.
Enable card checkout first. Wallets (Apple Pay, Google Pay) and local methods improve conversion once the baseline card flow is reliable. Each additional method is another surface to QA on mobile and desktop.
- Create a sandbox account and API keys at the provider.
- Store keys in the environment vault; never commit them.
- Configure webhooks for succeeded, failed, and disputed payments.
- Map settlement currency to your store currency policy.
Payments
├── Card (required for launch)
├── Wallets (after card happy path)
├── Webhooks → order + dispute handlers
└── Vault: LIVE_ vs TEST_ keys separated
Rotate keys if they appear in tickets, screenshots, or chat logs. Scope keys to the minimum permissions your integration needs.
Checkout fields
Collect only what you need to fulfill. Extra fields increase abandonment. Guest checkout should remain available unless accounts are required for your business model (subscriptions with self-serve portals are a common exception).
Address forms should use country-aware formats and postal validation where available. Phone numbers: require them only if fulfillment or fraud review truly needs them.
- Show order summary with tax and shipping estimates before payment authorization when possible.
- Surface shipping promises honestly — “arrives by” beats vague “fast shipping”.
- Keep marketing opt-ins unchecked by default where regulations require it.
- Preserve cart state across login so account creation does not wipe the order.
Error messaging should be specific (“Card declined — try another card or contact your bank”) without leaking sensitive processor codes to attackers.
Taxes & shipping
Define tax regions and shipping rates before advertising delivery promises. Show estimated totals as early as the cart when possible so the payment step is not a surprise.
Tax inclusive vs exclusive display must match how you market prices. Cross-border selling may require registration and collection rules — coordinate with finance before enabling new countries.
Shipping: offer a small number of clear options. Free shipping thresholds can lift AOV; test them against margin. Local pickup needs its own confirmation flow and inventory reservation rules.
Run test checkouts to addresses in each shipping zone and tax region you claim to support — configuration bugs hide in the second country you enable.
Go-live checklist
- Live API keys rotated and vaulted; test keys removed from production
- 3-D Secure / SCA settings reviewed for your markets
- Failed-payment and timeout messaging tested on mobile
- Receipt and fulfillment emails verified with authenticated sending domain
- Refund path tested; support macros updated
- Dispute / chargeback contacts documented
- One low-value real purchase completed end to end
Troubleshooting
Wallets not showing: check domain verification, HTTPS, and browser/device eligibility.
Tax mismatch vs spreadsheet: confirm origin address, product tax category, and inclusive display settings.
Double charges: ensure idempotency keys on create-payment calls and that shoppers cannot double-submit.
Best practices
Optimize for completion rate and trust, not maximum payment logos. Revisit decline rates monthly with your provider. Keep checkout copy calm — urgency tactics that conflict with inventory truth backfire. Align fraud rules with customer experience so legitimate buyers are not trapped in review hell during launches.
Prerequisites & preparation
Before changing production settings for payments and checkout, align the people who own content, DNS, analytics, and approvals. A fifteen-minute kickoff that names owners prevents multi-day Slack archaeology later. Capture decisions in the workspace notes so the next teammate inherits context instead of guesswork.
Gather credentials and access: workspace admin or editor role, DNS control when hostnames are involved, payment or API sandbox accounts when money paths are involved, and a shared checklist link. Confirm which environment you will rehearse in — preview first, production only after a green run.
Sandbox credentials ready, regions defined, and finance aligned on capture vs authorize behavior.
Detailed walkthrough
Work the happy path slowly the first time. Narrate what you expect to see after each click: a status badge, a DNS record, a webhook delivery, a Lighthouse metric. When reality diverges, stop and resolve the mismatch instead of clicking ahead — most outages begin as ignored yellow states.
- Enable card checkout in sandbox; vault keys separately from live.
- Trim checkout fields to fulfillment necessities; keep guest checkout if possible.
- Configure tax and shipping; test addresses in each zone.
- Exercise success, decline, and 3-D Secure challenge paths.
- Complete the go-live checklist including a low-value real charge.
Edge cases & failure modes
Plan for partial failure. Networks drop, registrars delay, providers rate-limit, and humans approve the wrong revision. Your runbook should say what “abort” looks like: leave preview up, roll back the release, or freeze campaigns until metrics recover.
- Sandbox and live keys crossed between environments.
- Tax inclusive labels disagreeing with checkout math.
- Webhooks delivered twice without idempotent handlers.
QA checklist before you announce
- Happy path verified on mobile and desktop
- Failure path messaging reviewed
- Owners named for the first hour after launch
- Rollback or freeze path documented
Operating the change
After launch, watch the metrics that prove the change worked — not vanity charts. Pair quantitative signals with one qualitative check (support ticket themes, sales feedback). Schedule a follow-up within a week to remove temporary flags, raise DNS TTLs, or archive the experiment.
Monitor decline and conversion rates weekly; revisit wallet enablement after card baseline is solid.
Treat payments and checkout as a repeatable playbook. The second time your team runs it should be faster because the checklist and owners already exist.
Every extra checkout field is a potential abandonment reason — justify each with a fulfillment need.
Show estimated totals early so payment is not the first time tax and shipping appear.
Idempotency on payment creation prevents double charges when shoppers double-submit.
Wallet buttons need domain verification and HTTPS; test on real devices, not only desktop Chrome.
Fraud rules should protect margin without trapping legitimate launch traffic in manual review forever.
Receipt email authentication (SPF/DKIM) is part of checkout trust; fix deliverability before launch ads.
Implementation checklist
Confirm field minimization at checkout on preview before you promote. Name who approves the change, which environment is authoritative, and what “done” looks like in measurable terms.
Document early tax and shipping estimates in cart where the team already looks — workspace notes or the engineering handbook — not only in a meeting memory.
Operating it with your team
Rehearse 3-D Secure paths on mobile devices against written acceptance checks. If you cannot name the verification event (order, DNS lookup, deploy health, or signed API call), you are not ready to announce.
Measure idempotent payment creation keys with anonymized but realistic data, and keep logs, headers, or screenshots for at least one release cycle so regressions have a baseline.
When you finish this guide, you should be able to explain the happy path, the abort path, and the metrics that prove success. If any of those are fuzzy, revisit the walkthrough with your teammates before you scale traffic, spend, or automation.