Timeout strategy is the set of rules a system uses to decide how long to wait for a response from another service and what to do when none arrives. In payments the second part matters more, because a timed-out charge has an unknown outcome rather than a failed one. For each hop between merchant, gateway, acquirer, network and issuer, it sets a connect timeout, a read timeout, a total budget and a recovery action. Safe handling uses idempotency keys, then status queries instead of blind retries, then webhooks or cancellation. Slow issuers can take 10 to 20 seconds, so a merchant read timeout below the gateway's own limit creates orphaned authorizations. Unresolved timeouts produce double charges, held funds and chargebacks.
What is timeout strategy in payments
A payment request crosses several hops: merchant server, gateway, acquirer, card network, issuer. A timeout at any hop leaves the caller unsure whether money moved. A timeout strategy defines, for each hop, the connect timeout (how long to wait for a connection), the read timeout (how long to wait for the answer), the total budget for the whole call, and the recovery action once the budget is spent.
Card authorizations often complete in well under a second, yet slow issuers can take 10 to 20 seconds. Setting the merchant's read timeout below what the gateway itself allows guarantees orphaned authorizations.
How does payment timeout handling work
The safe sequence has three steps. First, every request carries an idempotency key, so a repeated call returns the original result instead of creating a second charge. Second, after a timeout the client queries the transaction status rather than retrying blindly. Third, if the status is still unknown after a set window, the system either waits for an asynchronous webhook or cancels the attempt.
At network level, acquirers do the cancelling automatically. If a terminal or host gets no authorization reply, it sends a timeout reversal so the issuer releases any funds it may have held.
Designing the numbers
A common API timeout strategy uses a short connect timeout (2 to 5 seconds), a longer read timeout sized to the upstream's own limit plus a margin, and exponential backoff with jitter for status polling: 1, 2, 4, 8 seconds, capped. Circuit breakers stop sending traffic to a provider after repeated timeouts and hand it to a backup, which is where timeout handling meets failover.
A numeric example
A PSP processes 500,000 card payments a day and sees 0.1% timeouts: 500 payments in an unknown state daily. Without status checks, a naive retry would double-charge some of those customers; without reversals, others would see funds held for days with no order. Either outcome produces disputes, and at a typical chargeback fee of EUR 15 to 25, even a fraction of 500 daily cases adds up quickly.
What reviewers look for
In technical diligence of a payment company, timeout handling is a quick signal of engineering maturity. Useful evidence includes documented timeout values per provider, an automated job that resolves unknown-state transactions, reconciliation reports showing how many stayed unresolved, and incident logs for provider outages.