⚡ Authorization

How an authorization request travels

Authorization is the request in which the acquirer asks the card issuer whether it agrees to pay for a specific transaction. It is the first step in a card transaction's life cycle, ahead of capture and then clearing. In under two seconds, the request leaves the terminal (or payment page), passes through the acquirer and the card network (scheme), and reaches the issuer. The answer comes back the same way. At this stage, no money moves: the issuer simply places a hold on the funds in the cardholder's account and commits, subject to conditions, to pay. Funds only move at clearing, after capture.

ISO 8583 messages

The ISO 8583 standard defines the messages exchanged among acquirers, networks, and issuers. Every message starts with a 4-digit MTI (Message Type Indicator), which encodes the version (0xxx = 1987, 1xxx = 1993), the message class (x1xx = authorization, x2xx = financial, x4xx = reversal, x8xx = network management), the function (xx0x = request, xx1x = response, xx2x = advice), and the origin. In France, the CB2A protocol governs terminal-to-acquirer communication, using the same message logic.

The message body is made up of numbered fields (Data Elements, or DEs), whose presence is flagged by one or more bitmaps. Key fields include DE2 (PAN), DE3 (processing code), DE4 (amount), DE11 (STAN), DE14 (expiration date), DE18 (MCC), DE22 (POS entry mode), DE37 (RRN), DE38 (authorization code), DE39 (response code), DE41/DE42 (terminal and merchant IDs), DE49 (currency), and DE55 (EMV data).

MTI  : 0100                authorization request
DE2  : 497010######1234    PAN (masked here; all 16 digits in clear on the network)
DE3  : 000000              processing code: purchase of goods/services
DE4  : 000000012550        amount: 125.50 (12 digits, 2 implied decimals)
DE7  : 0711123456          transmission date/time MMDDhhmmss (UTC)
DE11 : 001234              STAN - System Trace Audit Number
DE14 : 2812                expiration date YYMM (December 2028)
DE18 : 5812                MCC: restaurants
DE22 : 051                 entry mode: EMV chip + PIN
DE37 : 619214001234        RRN - Retrieval Reference Number
DE41 : 00012345            terminal ID (TID)
DE42 : 000000001234567     merchant ID (MID)
DE49 : 978                 transaction currency: EUR (ISO 4217 numeric)
DE55 : 9F2608A1B2C3D4...   EMV data: ARQC, ATC, TVR, UN... (TLV)

Response codes: reading a decline

The response code is the value the issuer uses to explain its decision, carried in field DE39 of the response message. It drives the retry strategy, because not every decline reason calls for the same action. Declines fall into two groups: hard declines (stolen card, invalid card) and soft declines (insufficient funds, authentication required). A soft decline can succeed if something about the transaction changes.

French issuers also respond with CB-specific codes carried in private fields, which PSPs roll up into categories such as “bank decline,” “technical decline,” and “fraud.” Managing the approval rate requires the PSP to return the raw DE39 codes for every transaction, because these aggregated categories lump together reasons that call for opposite responses.

Pre-authorization and capture: one-step and two-step sales

A card sale involves two separate operations: authorization, which secures the issuer's commitment, and capture, which submits the final amount for settlement. Depending on the business, the two happen at the same time or at different times. In a one-step sale, authorization and capture happen together, and the authorized amount goes into clearing unchanged the same evening (typical of in-store retail). In a two-step sale, the steps are separate: a pre-authorization holds an estimated amount. The capture then sets the amount actually owed, sometimes several days later; it can be partial or supplemented by incremental authorizations.

• Partial capture: capturing less than the authorized amount (the balance must be released with a partial reversal).
• Multiple captures: several captures against a single authorization (split shipments), supported depending on the scheme and acquirer.
• Incremental authorization: increasing the amount held without a new transaction (hotels, car rental).
• Zero-amount authorization (account verification): checking that a card is valid without holding funds. This is the proper way to save a card on file, instead of €1 pre-auths.

Stand-in processing: when the issuer does not respond

Stand-in processing is the mechanism by which the network makes the authorization decision on behalf of an issuer it cannot reach because of an outage, maintenance, or a timeout. Visa calls it STIP, Mastercard calls it Stand-In, and in the CB ecosystem it is known as backup processing. The scheme applies parameters agreed in advance with the issuer: limits by MCC and time period, checks against blocked card lists, and velocity checks. It can even validate the cryptogram if the issuer has shared its keys.

Stand-in is also a deliberate business continuity tool. Some issuers hand overnight decisions or very low-risk transactions to the network to smooth their load. Conversely, a transaction declined in stand-in (code 91 or a parameter-based decline) is worth retrying once the issuer is back online: the decline came from the network's parameters, not from an issuer decision on that account.

Reversals, voids, timeouts, and repeats

A reversal (0400/0420 messages) cancels all or part of an authorization before clearing, and the issuer releases the held funds immediately. A refund is a separate operation: a reverse financial transaction processed after clearing. In PSP terminology, a void is a third operation: canceling a transaction that has been captured but not yet submitted for clearing.

A timeout occurs when the terminal or PSP has sent a 0100 and received no 0110 within the allowed time, typically 30 to 60 seconds on the terminal side. The issuer may have approved or declined the transaction, and the sender has no way of knowing which, so it must never treat a missing response as a decline. Instead, the system sends a reversal advice (0420) to cancel any phantom authorization, then repeats it (0421, the repeat mechanism) until it receives a 0430 acknowledgment, usually through a store-and-forward (SAF) queue.

t0        : send 0100 (STAN 001234, RRN 619214001234)
t0 + 45 s : no 0110 received -> TIMEOUT
t0 + 45 s : send 0420 (reversal advice)
            DE90 = original data: MTI 0100, STAN 001234,
                   date/time DE7, acquirer/issuer IDs
            reason (DE25/DE22 depending on dialect) = "timeout / unable to complete"
t0 + 75 s : no 0430 -> repeat as 0421 (same content)
...         repeats at intervals (SAF) until 0430 acknowledgment
result    : if the issuer had approved, the hold is released;
            if it had received nothing, the 0420 is simply ignored.

• Full reversal: releases the entire authorization (cart abandoned after authorization, timeout).
• Partial reversal: brings the hold down to the actual amount (fuel, partial capture).
• Advice vs. request: the 0420 (advice) is fire-and-forget with repeats, suited to post-incident cleanup; the 0400 (request) waits for a synchronous response.
• Idempotency: on the PSP/API side, every payment creation request must be idempotent (idempotency key) so it survives HTTP timeouts without duplicating the authorization.