The merchant sends an authorization request: 0100 in a dual-message flow, or 0200 where the authorization and the financial record travel together as one message (single-message, typical of ATM and PIN debit). The issuer checks limits and risk and replies 0110/0210. Note that pre-authorization is not what separates 0100 from 0200 — that distinction is dual-message versus single-message; whether a transaction is a pre-auth is carried in DE3 and the POS-related fields. On approval the issuer places a hold on the amount (not a debit) and returns an auth code (DE38) and response code (DE39=00). No real money moves here.
Once the merchant ships or completes the service, it submits a capture, marking the auth as "collect for real". Restaurant tips and hotel incidental adjustments happen here — the captured amount can differ from the authorized amount.
On a fixed cycle (usually daily) the network exchanges all captured transactions in batches, producing amounts owed between acquirer and issuer and computing interchange. This is where reconciliation lives — the STAN (DE11) and RRN (DE37) in the message are what match an authorization to its clearing record.
Based on clearing, funds actually move between banks: the issuer pays the network (minus interchange), which pays the acquirer, which pays the merchant (minus its fees). The cardholder is billed by the issuer on the statement date. Only now does money truly move.
| What | Initiated by | |
|---|---|---|
| Refund | A settled sale returned to the card | Merchant |
| Reversal | Cancels an auth not yet cleared (timeout/duplicate) | Acquiring system |
| Chargeback | Cardholder dispute, issuer forces funds back | Issuer/cardholder |
👉 Next: Reading ISO 8583: MTI, Bitmaps & Data Elements — the 0100/DE39/DE11 above, explained.