Slow Mobile Checkout: Recover the Session Without Replaying the Payment

Header image: conceptual illustration.

A customer switches from checkout into a wallet app, loses connectivity, and returns to a browser that appears frozen. The merchant must help them recover the existing session without replaying the payment as though nothing happened.

Weak-network design is partly a speed problem and partly a state-integrity problem. A lightweight page helps, but the most important rule is that a browser connection does not decide whether a financial action occurred.

Preserve server-side attempt identity

Create a durable attempt tied to the order before the provider operation progresses. Keep its provider resource, account scope, expected amount and currency on the server. A page refresh, reconnect or app return should retrieve that attempt rather than initiate another one.

Non-sensitive display state may be preserved locally where appropriate, but the browser must not be the authoritative payment ledger. Do not place credentials or sensitive payment payloads into offline storage to simplify recovery.

The safe payment retry guide explains why a new request after an uncertain response can create a second effect. On slow connections, the same principle applies to automatic reconnect logic.

Separate connectivity from financial status

Use two distinct observations: whether the client can reach the merchant now, and what the merchant last verified about the payment. A browser's online indicator does not prove the provider is reachable. A cached status does not prove the current financial state.

If displaying an older observation, label when it was checked. Do not present a cached successful balance or pending payment as a fresh provider response. An offline page should not claim a lookup, refund or confirmation has just happened.

web.dev's offline UX guidance recommends explicit, useful offline experiences rather than unexplained failure. Apply that UX principle conservatively to payments: preserve navigation and order context, not an automated financial outbox that silently replays charges later.

Avoid competing recovery requests

Do not let each browser timer, reconnect event and page tab independently launch status checks. Use a controlled status-read path and ensure checks do not overlap unnecessarily. Space requests and follow the provider's documented limits.

Stripe's payment-status guidance warns that polling is less reliable than webhook-based asynchronous handling and can trigger rate limits. Use the merchant's own verified status view for the customer, with a bounded recovery mechanism behind it when necessary.

A frontend timeout should clear the busy state and expose the existing order status. It should not automatically mark the attempt failed or enable a fresh financial operation without verifying what happened.

Worked hypothetical reconnect journey

Invented example: DEMO-ORDER-NET expects BDT 750. The server has recorded a provider attempt before the customer's mobile connection drops. The browser retains the order reference and shows that it cannot refresh confirmation while offline.

When connectivity returns, the page requests the existing order status. The server has already processed a verified success webhook for the correct merchant, order, amount and currency and credited once. The browser reads that result and shows completion.

In a second run, the payment remains unresolved. The page shows that confirmation is not available and provides a support path. It does not queue a new charge automatically. Only a definitive failed or expired prior attempt can permit a controlled new bKash or Nagad attempt under the established workflow.

Reduce payload without weakening verification

Keep essential checkout text and controls available before optional images or analytics finish loading. Optimize media and avoid blocking the payment path on nonessential third-party requests. A compact page can recover faster, but provider verification and server-side checks must remain intact.

Keep the amount, currency and merchant identity stable while the page loads. Layout shifts can cause accidental taps or make a customer unsure which action was submitted. A disabled or processing state should communicate the existing request without implying that disabling a button alone prevents server-side duplicates.

Slow-network test checklist

• Disconnect before initiation, during provider response and after provider success.
• Return from the wallet app after the browser has been suspended.
• Refresh and reopen the order in another tab.
• Verify no reconnect event creates a new financial request.
• Check that old observations are labelled and not treated as fresh confirmation.
• Simulate status-read errors without converting them into payment failures.
• Confirm the order can be found without collecting credentials.
• Ensure critical controls remain usable while optional assets load.

Use the uptime and failover guide for infrastructure resilience, while keeping browser connectivity problems separate from a declared provider outage.

Frequently asked questions

Should we automatically send stored payment requests when the browser reconnects?

Not as a generic recovery pattern. A delayed financial replay can surprise the customer or duplicate an existing operation. Use a verified attempt and the documented provider flow.

Is an offline indicator proof that payment never reached the provider?

No. It only describes a connectivity observation. Resolve the existing operation through server-side verification.