What to check first when checkout starts failing

When checkout starts failing, you need to establish which step is broken before choosing a response. Keep the first investigation narrow enough that another engineer can follow it.

Identify the failing step

Try to distinguish page loading, customer authentication, payment submission, and confirmation. Record the time, affected application version, and an example request identifier. Keep payment details and customer content out of shared incident notes.

Check recent deployments and your provider’s incident reports alongside your own logs. A vendor incident is a useful lead; it does not rule out an internal failure happening at the same time.

Protect the payment state

An error shown to a user does not necessarily mean that a payment failed. Confirm the state before asking them to try again. For a Stripe integration, use its error-handling documentation (opens in new tab) and idempotency guidance (opens in new tab) to review how retries behave.

Communicate what you have confirmed. If the result is uncertain, say that and tell the customer what to expect next. Use a fallback only if your team has tested its payment and reconciliation behaviour.

Measure the impact after the incident

Count affected attempts and reconcile completed payments. Separate abandoned sessions from confirmed lost sales. Multiplying every failed attempt by an average cart value can count retries and customers who later completed their purchase.

Keep the timeline, actions taken, and gaps in your evidence. Those records are useful for improving the runbook and, where a contract allows it, reviewing an SLA claim.

For a Stripe integration, the payments, webhooks and checkout guide gives checks for each part of that path.

Editorial correction, September 6, 2026: an earlier version presented an unsourced checkout story and revenue figures. Those figures have been removed.