System design deep dive: card authorization at scale

Card authorization systems process thousands of transactions per second, with large issuers handling 5,000 to 15,000 authorizations per second at peak, such as during holiday shopping or major sales events. The system must respond in under one second end to end, and the issuer's own decision typically takes 100 to 200 milliseconds. To achieve this, the authorization platform runs on in memory data grids, with account balances, card status, and limits held in memory rather than read from disk on every request. Requests are processed by stateless worker pools that scale horizontally, so adding servers adds capacity in a straight line, and the platform is tested at twice the expected peak before every major shopping season. The authorization engine runs a sequence of checks in a fixed order, and it stops at the first failure to save time. It first checks that the card is active and not reported lost or stolen, then checks the account balance and the available credit, then checks the transaction against daily and per transaction limits, and finally checks velocity rules such as the number of transactions in the last hour. Each check is a fast lookup against cached data, and the whole sequence is designed to complete in under 50 milliseconds for a straightforward approval. If any check fails, the engine returns a decline with a specific reason code, such as insufficient funds or exceeded limit, so the merchant and the customer understand what happened. Fraud scoring runs in parallel with the balance and limit checks, so it does not add sequential delay. A fraud model scores each transaction in 20 to 40 milliseconds, using features such as the merchant category, the location, the device, the time of day, and the customer's recent spending pattern. A low score approves the transaction immediately, a high score declines it, and a medium score triggers step up authentication, such as a one time passcode sent to the customer's phone. The model is updated regularly with new fraud patterns, and its decisions are logged with the score and the top contributing features, so analysts can review why a genuine transaction was blocked and tune the rules. Standby authorization keeps cards working when the issuer system is offline. The card scheme or a standby service holds a copy of key account data, including the balance, the limits, and the card status, refreshed every few minutes. If the issuer does not respond within a short timeout, usually 500 milliseconds to one second, the standby service makes the decision using the cached data and conservative limits, for example approving transactions up to 100 or 250 in local currency. These standby decisions are queued and sent to the issuer for reconciliation when it returns, and any transaction that exceeds the standby limit is declined rather than approved blindly. This design keeps customers able to pay during an outage without exposing the bank to unlimited risk. The authorization log records every request and every response, including the card reference, merchant, amount, currency, timestamp, decision, reason code, fraud score, and response time in milliseconds. The log is written asynchronously so it never slows down the authorization itself, and it is stored in a high throughput append only store that can absorb 15,000 writes per second. Operations teams use it to investigate a declined transaction, to prove that a transaction was approved, and to measure performance against the service target. The log is also the input for fraud analysis, limit tuning, and regulatory reporting, and it is retained for at least five years.