Your authorisation host is answering some requests and timing out on others. Who decides whether a card is approved while that is happening, and what do you inherit afterwards?

A timeout is not a decline, and it is not an approval either

The first thing to establish is that an authorisation request has a deadline measured in a small number of seconds and a chain of parties who each have a view on what happens when it expires. A terminal that gets no answer does not sit and wait; the acquirer that gets no answer from the scheme does not sit and wait; and the scheme that gets no answer from you does something specific rather than nothing. The design question is not how to keep your host up. It is what you have told the rest of the chain to do while it is not.

The message flow in card authorisation is request and response — in the classic message standard, an authorisation request and its paired response — travelling terminal to acquirer to scheme to issuer, with the answer coming back along the same path. Separately from that live pair there is a category of message that reports something already decided, and those messages are the reason an outage does not simply vanish when your host comes back. Something approved without you generates an advice you must post, and posting it is where the consequences land.

flowchart TD
  T[Terminal and chip] --> A[Acquirer]
  A --> N[Scheme network]
  N --> I[Issuer host]
  N --> S[Scheme stand-in]
  I --> R[Real time decision]
  S --> V[Advice to issuer later]

The branch to look at is the one that does not reach your host at all: the decision still happens, and the only thing you contributed to it was a set of parameters you configured at some earlier date.

Three places the decision can be taken

The outermost is the card and the terminal. Chip transactions carry risk-management logic that can approve below a floor limit without going online, governed by the card's own settings and the terminal's configuration, with the issuer's preferences expressed through the action codes personalised onto the card. This is the layer that exists precisely because connectivity has never been guaranteed, and it is why a small contactless purchase can complete in a tunnel. It is also why a card issued with permissive offline settings is a standing exposure that no amount of host availability fixes.

The middle layer is scheme stand-in. When the network cannot reach an issuer, it can decide on that issuer's behalf using parameters the issuer has lodged with it: approve up to an amount, approve up to a count within a window, decline particular categories, always decline a card that has been listed. This is the layer that matters in the scenario, and the interesting part is that it is your risk appetite encoded somewhere you rarely look. An issuer that has never revisited its stand-in configuration is running an outage policy written by whoever completed the onboarding form.

The innermost layer is your own degraded mode, and it is the one you control. If your authorisation service can no longer reach the ledger, the fraud model or the customer profile, you can still answer — with a cached balance, a conservative limit and no scoring — and answering conservatively is usually better than being absent, because being absent hands the decision to the middle layer with wider limits. Building that path means deciding in advance which dependencies are optional and what the answer is without them, and then exercising it, because a degraded mode nobody has run is a hypothesis.

Choosing the parameters is choosing the loss

Stand-in is a trade between approving fraud and declining genuine spending, and both sides cost real money. Declining everything protects the balance sheet and puts your cardholders at a till in front of a queue with a card that does not work, which is the most damaging retail moment a bank has. Approving generously keeps commerce moving and guarantees that some approvals will be for cards already reported stolen, some for accounts with no funds, and some for the same card fifteen times in an hour because the velocity check that would have caught it lives in the host that is not answering.

The parameters therefore differ by product in ways worth saying out loud. A credit card has headroom by construction, so a modest stand-in ceiling costs you little in exposure. A debit card is drawing on someone's actual money, so the same ceiling produces unauthorised overdrafts you may have to write off and customers who overdraw without knowing. The other necessary asymmetry is the negative list: whatever else stand-in does, cards you have blocked must be declined, which means your blocking path has to reach the scheme promptly and independently of the host that is down.

Recovery is the part candidates forget

When the host returns you are handed the transactions you did not see. Each advice must be posted, which is straightforward until it is not: an account can now be past its available balance because two stand-in approvals were granted against the same funds; a hold may exist for a transaction that was also approved offline; and the advices may arrive out of the order in which the purchases happened. Applying them requires the same idempotency discipline as any other payment path, keyed on the scheme's own transaction identifiers, because replayed advices during a backlog drain are common and a double posting here is a customer complaint about their balance.

There is also a reporting obligation to yourself. The set of transactions authorised in your absence is the measurable cost of the outage, and it is the only evidence that will tell you whether your stand-in parameters were right. Counting them, splitting them into those you would have approved and those you would not, and totalling the second group is the review that turns an incident into a parameter change.

A host that answers slowly is worse than one that is down

The specific shape in the question — some requests answered, some timing out — is harder than a clean failure and is the more common shape in practice. A clean outage is detectable, and the chain fails over to stand-in decisively. A host that responds to most traffic and stalls on the rest may never trip a failover threshold, so every stalled request burns the full timeout at the terminal, cardholders see an unpredictable mixture of successes and declines, and your availability dashboard reports the service as up because it is answering. Health has to be defined on the metric that matters, which is the proportion of requests answered inside the deadline rather than the proportion answered at all, and shedding load to stand-in deliberately when that proportion falls is a better outcome than letting each transaction discover the problem for itself.

What this failure looks like in the wild

In June 2018, Visa's European card processing was disrupted for several hours after a component in one of its two data centres failed partially rather than cleanly, and the standby site did not take over the full load as it was designed to. Authorisations failed intermittently while the platform remained nominally available, so shops and cardholders saw an unpredictable mixture of successes and declines. An interviewer raising this wants you to notice that an authorisation path more often degrades than dies, and that a design with no defined behaviour for a component that is alive but sick is only half a design.