Checkout Timed Out: Was the Payment Failed or Just Unconfirmed?

Header image: conceptual illustration.

A spinning checkout stops and displays a network error. That tells you something about the connection between systems; it does not necessarily tell you what happened to the money. The request may never have reached the provider, or the provider may have completed it before the response was lost.

Merchants need separate language and recovery rules for an unknown outcome, a provider-confirmed failure and an expired checkout session. Treating all three as failed is a common route to duplicate attempts and confusing support conversations.

Identify which component timed out

Start with the request boundary. Was it the browser waiting for the merchant, the merchant waiting for the provider, a wallet-app return, or a webhook worker? Record the affected attempt and a sanitized request identifier. A generic timeout message without that context makes diagnosis much harder.

Also distinguish the checkout container from the financial operation. A session can expire while a related operation needs separate verification. A return page can load successfully while the payment still needs customer action. Neither a working redirect nor a broken redirect is authoritative proof of payment status.

Stripe's PaymentIntent status documentation illustrates the distinction: processing, requiring customer action, requiring capture and succeeded are different states. Those labels are Stripe-specific, but the principle of verifying the actual operation applies more broadly.

Use a three-way customer status model

For an unknown result, explain that confirmation is not yet available and that the existing attempt is being checked only if a real checking process exists. Avoid saying payment failed or payment succeeded without evidence.

For a provider-confirmed failure, show the available safe reason and explain the permitted next step. Do not disclose internal credentials or raw provider errors. For an expired unpaid session, explain that the checkout ended and determine whether a new attempt is allowed from the verified payment record.

Keep the customer's order reference visible. Support should be able to find the existing attempt without asking the customer to repeat a financial action. Never ask for a wallet PIN, OTP or password to diagnose a timeout.

Recover before offering another payment

1. Retrieve the durable attempt record, including provider and environment.
2. Check whether initiation was recorded and whether a provider resource identifier exists.
3. Use the documented status lookup or recovered webhook to resolve uncertainty.
4. Verify successful final status, merchant/order reference, expected amount and currency before crediting.
5. Commit crediting idempotently; update the order view from that verified record.
6. Escalate unresolved or inconsistent outcomes rather than converting them to a failure.

If a request may have been executed, retry that request only using the provider's documented idempotency mechanism and its supported scope. Creating a fresh key for the same uncertain operation can create a second financial effect. See the failed-payment retry guide for the broader retry controls.

For bKash and Nagad, do not interpret a browser timeout as definitive expiration. Permit a controlled new attempt only after the previous attempt has definitively failed or expired.

Worked hypothetical timeout

Invented example: DEMO-ORDER-T expects BDT 2,000. The merchant receives a provider resource identifier, but its confirmation request times out. The browser offers a status page rather than another pay button.

A subsequent authenticated lookup confirms the correct merchant, order reference, amount and currency and a successful final status. The merchant credits once. The late webhook then arrives and is recognized as another signal for the same payment.

In a second scenario, the provider definitively reports that the attempt failed before any successful payment. A new attempt is allowed under the merchant's documented policy. The team links it to the same order but gives it its own attempt identity, preserving the failed history rather than overwriting it.

Keep checkout uncertainty observable

Measure unknown outcomes separately from declines. An increase after a release may indicate a response-handling issue even if provider payments are succeeding. Compare browser errors, server request failures, webhook delays and succeeded-but-not-credited cases.

Do not call every timeout a provider outage. A slow device, broken redirect, stale session or merchant deployment can produce similar symptoms. The payment API overview helps locate these boundaries without making assumptions about which system caused the delay.

Timeout handling checklist

• An interrupted connection preserves the existing attempt identifier.
• Refresh and back-navigation do not initiate another charge.
• Unknown, failed and expired states have different customer wording.
• A status lookup uses the correct provider account and environment.
• Only a verified payment result changes financial value.
• A retry cannot bypass the one-active-attempt rule.
• Support can explain what is known without promising an unverified refund or completion time.

Frequently asked questions

Does a customer leaving the page cancel payment?

Not necessarily. Check the provider resource and method-specific cancellation rules.

Can we mark every unresolved timeout failed after a timer?

No. An internal investigation deadline should trigger escalation. It does not manufacture a provider-confirmed financial outcome.