Charged once

Case presses Pay. The spinner spins, and keeps spinning.

Three seconds. Five. Somewhere between Case’s kitchen and Ledgerline, a parcel is having a slow morning, and every runner alive knows what Case does next. Case presses Pay again.

The thread, pulled

Scene 4 left a warning: repeat a POST and something might happen twice. Two payment requests just left one phone. This is the morning’s last mystery: why Case is about to be charged once.

First, the machinery of giving up. A client will not wait forever — it carries a timeoutConcept · lights on your maptimeoutA limit on how long a system will wait for an operation to finish. Vital, and subtle: a timeout means no answer arrived in time. It does not prove the other side did nothing., and the subtlety in its definition is the entire drama here. When a payment request times out, the money might not have moved, or might have moved with the receipt lost on the way back. Silence is not a no.

Trying again after a failure is a retryConcept · lights on your mapretryAnother attempt after a failure or a silence, on the theory that many failures are temporary. Retries must be limited, spaced out, and above all safe to repeat, which is what idempotency provides., and Case’s second press was one, performed by thumb. Systems retry on their own for the same reason. Which makes the real question: how does anyone retry a payment safely?

The answer is idempotencyConcept · lights on your mapidempotencyDesigning an operation so repeating it has the same effect as doing it once. The client attaches a unique key to the attempt; a retry carries the same key, and the server recognises it and returns the original result instead of acting twice.. Both of Case’s presses carried the same hidden key, minted for this one attempt. Ledgerline saw the key twice, charged on the first, and answered the second with the receipt it already had. Case will never know two requests left the phone. The bank statement will show one line, which is the whole art.

The entry becomes real

Payment confirmed, Ledgerline has one job left: telling Traversal. It does not wait to be asked. It sends a webhookConcept · lights on your mapwebhookOne system automatically notifying another when an event happens: you register a URL, and the provider sends a request to it when the event occurs. Polling asks over and over; a webhook means the other side calls you., a request travelling the opposite direction to everything else this morning, from the vendor to Traversal, knocking on a URL that Traversal registered for exactly this purpose months ago and has kept ready ever since: payment succeeded. That arrival is the moment the entry becomes real. 10:02. Case is in the draw.

One guard stood over all of it. On a morning when forty thousand people arrive at once, every door checks a rate limitConcept · lights on your maprate limitA cap on how much a client may ask of a service in a period. It protects the provider from loops, abuse, and any one client consuming everything. Exceed it and the answer is a status code: 429, too many requests., and the over-eager get a 429 and a moment to think. Case’s two presses sailed under it. The person refreshing forty times a minute since 9:55 did not.

Two minutes, again, and this time it is nobody’s copy

The screen said yes at 10:02. Semaphore’s email, the one with the entry number in it, arrives at 10:04, and this lag is a different animal from lottery day’s. Nothing here is stale. Traversal answered Case first and then, separately, put send the email on a list of work to be done, and a machine with forty thousand emails to send got to Case’s in two minutes. The yes was urgent. The letter was not. Doing the urgent thing now and the slow thing soon is most of how race-day systems survive, and Act III will make that sentence the whole plot.

10:04, registration morning. The entry is real, the charge is single, the email is sitting above the receipt for the socks. Eighteen weeks to race day. Case laces up and goes for a run.