Design a Payment System, stage 2 of 13: decide
Should checkout wait for the provider?
The buyer clicks Pay. Most charges complete in 1-2 seconds, a few take 10, some hang, and 3-D Secure payments complete only after the buyer finishes a challenge. The load balancer cuts requests at 30 seconds. The buyer should get an answer or a clear "processing" state within about 10 seconds.
System so far· 4 parts
Select a component to see what it is responsible for and which state it owns.
- 1Buyer's browser → Payment provider: Card entry and 3-D Secure in hosted fields
- 2Buyer's browser → Checkout API: Pay (Idempotency-Key header); poll status
What you need to know
A request has a deadline set by things outside your code: the load balancer here cuts requests at 30 seconds. If your code waits longer than that, the buyer sees the load balancer's generic error, and your handler loses control of the response.
So any wait inside a request needs its own timeout, set shorter than the load balancer's, with a plan for what to return when it fires.
Work it out
Provider p99 latency is 10 s. With an 8-second wait, roughly what percentage of buyers would see 'processing' instead of an immediate answer?The "processing" path only works if something will resolve it later. That's possible only if a durable record of the attempt exists before the provider is called, so a webhook or a periodic check can find it and finish it.
3-D Secure payments always take this path: the buyer completes a challenge minutes later, and the result arrives by webhook.
Check
The browser confirms a payment with the provider's SDK. Why shouldn't the server mark the order paid when the browser says so?