Real-time decisioning
Every other call on this platform runs in the direction you expect: you ask, we answer. An authorization runs the other way. The card network asks, and something has to answer approve or decline while the cardholder stands at the terminal.
How it works
Card networks give the issuer seconds to make an authorization decision, not minutes. That constraint shapes the whole flow. There is no queue to wait in and no retry loop. The system making the decision has to read the card state, check the funds available, apply the relevant rules, and return an answer within a budget that also includes the network round trips.
The decision is made somewhere in the issuing path. In some programs we make it ourselves; in others, the processor does. Which one applies depends on how the program is set up. That distinction is intentionally hidden from you. If integrations could depend on it, we would lose the ability to move that responsibility later.
What matters is the behavior you can rely on. A card that is not spendable will not authorize. A transaction for more than the available funds will be declined. Declines show up as authorization reasons, not as errors from one of your API calls, because your call did not fail—the authorization itself was declined.
An approval does not immediately move money. It places a hold for the authorized amount. The actual movement happens later, when the transaction clears, and the cleared amount may be different from the original authorization.
If the system cannot make a decision—for example, because a required read fails or the authorization times out—it declines the transaction. For a prepaid program, that is the safer default. Approving a transaction without being able to verify the balance could mean approving against funds that are not there. A decline is inconvenient for the cardholder, but an unchecked approval can effectively turn into unsecured credit.
Related
- Transactions — the settled record a decision produces, and the only part of the sequence exposed today