A gateway timeout is ambiguous: the customer may see failure after the provider has already accepted the payment. The safe design assumes the browser can lose the response and therefore protects order creation and capture with stable identifiers and reconciliation.
Do not tell the customer to retry immediately
First check whether an order/payment intent exists. A blind retry can create a second charge before the first callback arrives.
Use idempotency where the gateway supports it
Tie the payment request to a stable checkout/order key. Repeating the same network request should return the same payment operation, not create another one.
Keep the order before leaving the site
Create a recoverable order/session state with enough correlation data to reconcile the provider response after a browser timeout.
Handle late webhooks
A delayed success event must be able to move the existing order to paid exactly once. Stock, emails and fulfilment should also be idempotent.
Reconcile ambiguous cases
Build an operational view for “customer saw error / provider state unknown”. Compare provider transaction ID, amount and order key before any manual capture/refund.
For a related duplicate-order symptom see the duplicate order/charge pattern (Spanish) or use payment tracing for a provider-neutral method.
Design the customer recovery state
After an ambiguous timeout, the safest customer message is neither “payment failed” nor “payment succeeded” until reconciliation finishes. Keep the order in a recoverable state, show that confirmation is being checked and prevent rapid duplicate submission. Support should be able to search that state by order and provider reference.