Most people picture a card payment as one event. The terminal beeps, the screen says approved, the money moves. That mental model is wrong in a way that matters, because almost every operational headache in card payments comes from confusing the three distinct processes hiding behind that beep.
A swipe (or tap, or dip, or card-not-present charge) sets off authorization, clearing, and settlement. They run on different clocks, carry different messages, and answer different questions. Authorization asks "is this good for the money?" Clearing asks "what exactly do we owe each other?" Settlement actually moves the cash. Knowing where each one starts and stops is the difference between debugging a payment problem in minutes versus guessing for a day.
This module sits between the four-party model (who the players are) and interchange (what they charge each other). Here we follow the money and the messages through one transaction.
The cast, in one line
The cardholder pays. The merchant accepts. The acquirer is the merchant's bank or processor and the merchant's connection into the network. The issuer is the cardholder's bank. The network (Visa, Mastercard, and others) is the switch in the middle that routes messages and tallies the obligations. Keep these four straight, because the message hops between them in a fixed order.
Step 1: Authorization (seconds)
Authorization is a real-time round trip. The cardholder presents the card, the terminal or gateway captures the card data, and the acquirer builds an authorization request and sends it into the network.
The network routes that request to the issuer. The issuer runs its checks in the moment: is the card valid and not reported lost or stolen, is there enough credit or balance, and does the transaction trip any fraud or velocity rules. It returns an approval or a decline code back through the same chain, network to acquirer to terminal, usually within a couple of seconds.
These messages ride on ISO 8583, the international standard for card transaction messages. Each message carries a four-digit Message Type Indicator. An authorization request from the acquirer is a 0100; the issuer's response is a 0110. Visa and Mastercard each layer their own dialect on top of the base standard, but the skeleton is shared.
What authorization does not do
No money moves during authorization. On a credit card, the approved amount is placed on hold against the cardholder's available credit; on a debit card, the funds are earmarked. The hold is a promise, not a transfer.
Holds also expire. Visa and Mastercard set maximum validity windows, commonly around seven days for a standard transaction and longer for specific categories like hotels and car rentals. If the merchant never captures the transaction, the hold simply falls off and nothing settles. This is why a cancelled order can still show a "pending" charge for several days: the authorization happened, the capture never did.
Step 2: Clearing (hours to a day)
Authorization confirms the money is good. Clearing establishes what is actually owed.
After the sale, the merchant captures the transaction, often by batching the day's approved transactions and submitting them through the acquirer. The acquirer sends the captured records into the network's clearing system, which matches each captured transaction back to its original authorization record.
Clearing is the exchange of final transaction detail between acquirer and issuer through the network: the confirmed amount, currency, merchant category, and the fees that apply. It is reconciliation, not a cash movement. The output of clearing is a precise set of obligations: issuer X owes acquirer Y this net amount across all the transactions that cleared in this cycle.
A useful nuance: the authorized amount and the cleared amount can differ. A restaurant authorizes the check, then captures the check plus tip. A fuel pump authorizes a placeholder amount, then clears the actual gallons pumped. Clearing is where the real number gets locked in.
Step 3: Settlement (one to two business days)
Settlement is the only step where money actually moves. Working from the cleared obligations, the network calculates the net position between each issuer and acquirer and instructs the transfer of funds. The issuer pays the network's settlement account, the network pays the acquirer, and the acquirer credits the merchant, typically one to two business days after the sale.
The amounts settled are net of fees, not gross. Interchange (set by the network, paid by the acquirer to the issuer) is deducted in this flow, which is the mechanical reason the merchant receives less than face value. We cover how interchange is priced in the next module; here the point is that fees are baked into the settlement math, so the merchant never sees the full ticket amount land in the account.
A worked example
A customer buys a $100 pair of shoes on a consumer credit card.
- Authorization. The terminal sends a 0100 for $100. The issuer approves, returns a 0110, and places a $100 hold on the cardholder's available credit. Elapsed time: about two seconds. Money moved: zero.
- Clearing. That night, the merchant batches the day's sales. The $100 transaction clears, matched to its authorization, with the merchant category and applicable interchange attached. The network now records that the issuer owes the acquirer for this transaction, net of interchange. Money moved: still zero.
- Settlement. A day or two later, the network nets all obligations between this issuer and this acquirer and moves funds. Suppose interchange on this transaction is roughly $1.80 (we will price this properly in module 3). The issuer remits, the network routes funds to the acquirer, and the acquirer credits the merchant. After the acquirer's own markup, the merchant might receive around $97.50. The cardholder is billed the full $100 by the issuer.
Three steps, three clocks, one purchase. The customer experienced a single beep. The system ran three separate processes to make it real.
Why this matters when you ship
Almost every payment incident maps to one of these three stages. A declined checkout is an authorization problem; look at the issuer's response code. A "charge I cancelled is still showing" complaint is an authorization hold that has not yet expired, with no capture behind it. A reconciliation gap between what the merchant rang up and what hit the bank is a clearing-versus-settlement question, usually fees or a captured amount that differed from the authorized amount. Funds that are "missing" on day one are almost always just in flight, because settlement runs on a one-to-two-day cycle by design, not as a delay.
Read every payment problem by first asking which of the three stages it lives in. Authorization, clearing, settlement. Get that right and the fix is usually obvious. Skip it and you will debug the wrong layer.