Timeout is not failure; query first

What it is

When the client clock waiting on the rail rings first, the page did not get a packet. It does not mean the rail refused or did not capture. Timeout ≠ failure: the next step is lookup with the intent id—success becomes a receipt, decline becomes failure handling, still unknown stays unknown. This lands “don’t guess unknown” on timeout as a trigger. It is not how decline copy is written, and not how stock is released.

Why it happens

Timeout is a local or gateway wait cap, not the same event as the rail’s ledger. Slow nets, late callbacks, and backgrounding make the page give up while an authorization may already have succeeded. Painting timeout as a red failure makes people pay again; double capture starts here. Lookup is a read-only ask of the rail with that intent id, not a new intent. People need “timed out, asking for the result,” not “failed, retry,” which translates timeout into refusal.

Studying it

With the rail accepted but the callback later than client timeout, compare: timeout equals failure and pay-again, timeout forces lookup, timeout keeps spinning until callback.

Independent variables: timeout threshold, new intents forbidden after timeout, lookup retry count. Dependent variables: double authorization, false failure (actually succeeded), whether people can say “still don’t know.”

Mock delay is the clean lab. Live jitter needs logs that split client timeout from rail decline codes. Final recon is not the only metric—if failure copy already appeared in process, timeout was treated as failure.

Where it stops holding

Lookup itself has a bound; after several empty answers, escalate to a human rather than a forever lookup page. Only when the rail returns a timeout-class code and states nothing was booked can you treat it as failure and offer another method. Offline, lookup is impossible; store the intent id and look up when the net returns, rather than allowing another pay while offline.

Applying it

• Client timeout enters “result not confirmed + lookup”; the pay control stays off until lookup returns decline or a human takes over.
• Lookup uses the original intent id; show the order id so people can check the bank.
• Lookup success goes straight to the confirmation receipt, not through a failure page.
• Verify by letting the rail succeed with a callback slower than page timeout: the UI looks up, not fails; extra taps before lookup returns still yield one authorization on the rail.

Related

• Within the group: H7.13.2 Released stock and coupons must return promptly · H7.13.3 Channel/order mismatch should read as processing · H7.13.4 Auto-refund for double charge needs a stated arrival window
• Adjacent: H7.06 Payment failure · I1.06 Timeout strategy · H7.05 Order confirmation
• Search terms: payment timeout · query before retry · async capture