Every check spends the same budget

A card authorisation is a conversation with a clock running. The scheme expects an answer within a fixed window, and when the answer does not come, one is given for you: a decline, or an approval under the scheme's own fallback rules, which you did not write. Either way, the decision has left your hands.

Inside that window sit all the checks a licensed platform has to make before it can say yes: that the card is active, that the account holds the funds, that the payment is within the customer's limits, and that nothing about it looks like fraud. Each check is reasonable on its own. Together they are a budget, and most platforms discover it only when they overspend it.

Divide the budget before building anything

The useful first step is arithmetic. Take the window, subtract the network's share and the scheme's, and what remains is yours. Then give each check an allowance before any of them is built, and write the allowance down where the team will see it.

This changes the conversation about every later feature. A new rule is no longer a free addition; it is a request for time that has to come from somewhere. Teams that skip this step end up with a latency figure that nobody chose, spread across checks that nobody would have funded at that price.

One pass, not a chain

The most common shape is a chain: check the card, then the balance, then the limits, then call out for a fraud score. It is easy to write and easy to reason about, and its latency is the sum of every step.

Most of those checks do not depend on each other. Run them in a single pass, gather the answers, and make one decision at the end. The latency becomes that of the slowest check rather than all of them added together, and the decision logic lives in one place where it can be read, tested and explained.

Decide what a late answer means

Sooner or later a check will not answer in time. A remote fraud service will be slow, a cache will be cold, a dependency will be restarting. What matters is what the platform does when that happens.

That is a product and risk decision, not a timeout setting. Some checks can fall back to a conservative local rule. Some should decline. Some can approve up to a lower limit. Each fallback should be chosen deliberately, check by check, before the first incident chooses it for you.

Measure the tail

An average latency says almost nothing here. The authorisations that matter are the slow ones, because they are the ones at risk of missing the window. Watch the 95th and 99th percentiles on real traffic, and alert on the budget itself rather than only on errors.

The test is simple. Ask how much of the window is left at p99 today, and which check you would cut if a new one had to fit. If nobody knows, the budget is being spent without being managed.