Move from a vague “checkout is broken” report to a controlled diagnosis and verified recovery.
“Checkout failed” can mean the page never loaded, validation rejected an address, tax or shipping returned no option, a payment was declined, an order was created without confirmation, or a webhook never updated status. Identify the failed stage before changing code.
Stabilize the incident first
Record the start time, affected storefront, business impact, recent changes, and a named incident owner. Avoid repeated live test orders and random plugin toggles. If customers may be charged without seeing confirmation, pause the affected payment method or checkout path using the safest existing control and reconcile provider transactions against orders.
Capture one reproducible case
- Exact time and time zone
- Cart contents, quantities, coupons, currency, and customer type
- Billing and shipping country/region/postcode, using non-sensitive test data
- Browser/device and whether the customer was signed in
- Shipping and payment method selected
- Visible error text and request/correlation/order identifiers
- Provider transaction state, without copying secrets or full payment data
Locate the failing stage
| Stage | Typical symptom | First evidence |
|---|---|---|
| Page/render | Blank, endless spinner, disabled button | Browser console, network requests, PHP error log |
| Cart/session | Items disappear or totals change | Cookies, cache behavior, session storage, cart fragments |
| Address/validation | Required-field or postcode loop | Field payload, locale rules, checkout customizations |
| Shipping/tax | No rates or wrong totals | Zone match, package dimensions, provider response, tax configuration |
| Payment authorization | Decline or generic gateway error | Gateway log and provider dashboard event |
| Order creation | Charge exists but order is missing/failed | WooCommerce logs, database/order notes, request trace |
| Post-payment | Pending status, no email, no fulfillment | Webhook delivery, scheduled actions, email and integration logs |
Compare every system of record
For payment incidents, compare the storefront order, payment-provider event, bank or processor state when available, webhook attempts, and fulfillment system. Do not refund or recapture until you know whether an authorization, capture, void, or refund already exists.
Reproduce outside production
Use the provider’s sandbox and a representative staging copy. Preserve the failing dimensions while substituting safe test data. If staging does not reproduce, list environmental differences: keys, webhook URL, cache, CDN, taxes, shipping credentials, PHP extensions, cron, and traffic rules.
Isolate one layer at a time
Start from the evidence. If a JavaScript exception prevents submission, inspect the component owning that script. If the provider rejected an authorization, read its reason and request. If a webhook is accepted but processing fails, inspect the handler and scheduled action.
A conflict test should use staging or a controlled maintenance plan: default theme, only WooCommerce and the payment component, then restore interacting components in small groups. Keep exact versions and results. The plugin evaluation checklist provides a reusable staging and rollback pattern. If the failure differs by staff account, inspect the effective role and capability boundary.
Verify the whole transaction
- Run the original failing scenario.
- Run a normal card success and an intentional decline.
- Test guest and signed-in checkout where supported.
- Test key shipping zones, taxes, coupons, and high-risk cart types.
- Confirm order notes, stock, emails, provider status, webhooks, and fulfillment.
- Test refresh, back button, and double-click behavior for duplicate protection.
- Monitor the live error rate and reconcile new transactions after release.
Close with a prevention change
Document the trigger, detection gap, correction, verification, and follow-up owner. Add a synthetic test, alert, runbook step, safer deployment check, or clearer customer error when it would detect or reduce recurrence.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- WooCommerce system status documentation Official explanation of the environment, templates, logs, and scheduled-actions information used during diagnosis.