The Three-Phase Life of a Card Transaction
Part II · Cards (Chapters 4–8) Builds on: Chapter 2 (clearing, settlement, finality), Chapter 5 (the four-party model; authorization and funds paths running in opposite directions), Chapter 6 (interchange) New concepts in this chapter: authorization, capture, void, refund, chargeback, pre-authorization, ISO 8583
Save this chapter's status table — authorization, capture, posting, settlement, void, refund, chargeback — somewhere you can find it. The chapters on risk, compliance, and reconciliation all come back to it.
This chapter uses a credit card as its example. A debit card runs the same three phases; the only thing that differs is when the money actually leaves your account — a table right after the status table sets the two side by side.
1. The Three-Second Illusion¶
The previous chapter ended on a question: three seconds after the swipe, when the screen says "Approved," has the merchant received its $97.70 ($100 swiped, minus $2.30 in fees — the merchant's actual take)? Has the $100 left your account?
This chapter is about what actually happens in those three seconds.
You swipe your card at a store. The POS flashes "Approved."
What has actually happened at that moment is far less than the word on the screen:
| What you think happened | What actually happened |
|---|---|
| The $100 left your account | It didn't. Your deposits haven't moved a cent, and nothing has reached your statement yet; all that moved is your available credit |
| The merchant received $97.70 | It didn't. The merchant hasn't seen a cent |
| The transaction is over | It isn't. It has finished the first of its three phases |
Exactly one thing has happened: the issuer said yes to this transaction and placed a hold on part of your credit line.
2. The Three Phases¶
| Phase | Name | Who acts | When | Does money move? |
|---|---|---|---|---|
| First | authorization | merchant → acquirer → card network → issuer, then back along the same path | 1 to 2 seconds | No |
| Second | clearing / presentment | merchant's end-of-day batch → acquirer → card network → issuer | T+1 | No |
| Third | settlement | issuer → (net amounts computed by the network) → acquirer → merchant | T+1 to T+2 | Yes |
(T+1 means the first business day after the transaction date.)
Phase one: authorization
In that second or two, the issuer does three things: checks the card is valid, checks the available credit covers it, runs a risk score. Then it returns approve or decline.
Approval comes with a hold placed in the issuer's own system: your credit limit still reads 1,000 and nothing has hit your statement, but your available credit is now 900.
Hold this up against clearing and settlement: this step is neither clearing nor settlement — it is nothing but an exchange of information. Card networks manage second-level speed precisely because they split the fastest part (asking "yes or no?") completely away from the slowest part (actually moving the money).
Here is the route that information takes, at the terminal or behind the spinner on a checkout page:
Notice what the merchant does not do in that second or two: it picks neither the network nor the issuer. It hands the card details to one acquirer, and the card itself decides the rest of the route — which network, which issuer, which of that issuer's accounts. That is the whole value of the grid in the middle: one connection buys the merchant reachability to every issuer hanging off it. The approve-or-decline then walks the same path in reverse.
Phase two: clearing
At end of day, the merchant packs everything authorized that day into a batch and hands it to its acquirer. The acquirer aggregates and submits to the card network. The network runs the netting described in clearing and settlement and works out who owes whom, between every issuer and every acquirer.
The fee split from the previous chapter — 1.80 to the issuer, 0.13 to the network, 0.37 to the acquirer — gets computed at this step.
Phase three: settlement
The issuer moves the netted amount to the acquirer, and the acquirer pays the merchant on whatever cycle their contract sets. The money never passes through the network's own account — as the four-party model said, the network only counts and instructs.
T+1 or T+2 is typical. For new merchants and high-risk industries, though, acquirers deliberately stretch it to T+7 or longer — and hold back a slice on top.
That held-back slice is called a rolling reserve: the acquirer withholds a small cut of every settlement for a while, as cover against future refunds and chargebacks. It has nothing to do with the reserves parked at the central bank in the hierarchy of money — the two just collide on a word. Why the design exists is unpacked when the course reaches the five risks of payments.
Reserves are not the only word that collides here, and the bigger overlap is "clearing" and "settlement" themselves. The clearing and settlement in phases two and three are the card network's own: run under scheme rules, between the network's own member banks. They are not the interbank clearing and settlement of clearing and settlement — they sit one layer above it. The net positions the network works out between issuers and acquirers still have to turn into a real transfer, and that transfer moves over accounts the member banks hold at banks. Those banks in turn settle with the central bank, which is a separate topic — the chapter comparing the four US rails picks it up. So the mechanics rhyme — net first, then move only the difference — but two things do not carry across. Whose rules govern: a private scheme's, not a central bank's. And finality: a wire is final on arrival, while a card transaction that has fully settled can still be clawed back by chargeback 120 days later.
With all three phases run, the questions at the top of this chapter have answers. Put the three numbers on one timeline, each changing at its own moment:
The three lines bend at three different moments — and the "Approved" the user sees corresponds only to the leftmost one.
3. Authorization is not a charge: the full set of states that grows from it¶
This is the most useful table in the chapter.
| Step | Industry term | What happens | What the user sees |
|---|---|---|---|
| Authorize | authorization | A hold is placed on the balance | Pending |
| Capture | capture | The merchant confirms it wants the money; the transaction joins the day's batch | Still pending, until clearing completes |
| Post | posting | The captured transaction clears; the hold becomes a real charge | Pending disappears; a finalized charge appears on the statement |
| Settle | settlement | Money moves through the clearing network from issuer to acquirer, then on to the merchant | Nothing changes on the user's side; the merchant is paid at T+1 to T+2 |
| Void | void / reversal | Canceled after authorization, before capture | The pending entry disappears; the hold lifts immediately |
| Expire | expiry | The merchant never captures; the hold lapses on its own | The hold typically releases after 7 to 30 days |
| Refund | refund | A brand-new transaction in the opposite direction | The original stays; a separate refund entry appears |
| Charge back | chargeback | The cardholder appeals to the issuer, which forces the money back | The merchant is debited, plus a separate dispute fee |
The first four rows are one transaction's normal path end to end: authorization → capture → posting → settlement — the three phases pushed all the way through, with the money truly reaching the merchant only at the final settlement step. The last four rows are the exits along the way — money stopped, sent back, or clawed back before it finishes the trip.
Why are authorization and capture separate steps?
Because plenty of businesses don't know the final amount at the moment the card is presented. The hotel at check-in doesn't know whether you'll raid the minibar. The gas pump doesn't know how much you'll fill when you insert the card. The delivery app doesn't know whether you'll add a tip.
So the flow is: authorize an estimated amount to claim the funds, then capture once the real amount is known. This is a pre-authorization.
Where a Debit Card Differs
Every state above, all three phases, all these timings — a debit card is identical. Exactly one thing differs: when the money actually leaves your account.
| Credit card | Debit card | |
|---|---|---|
| What the authorization holds | Credit headroom. Your deposits are untouched | Real money in your deposit account. The balance is still there, but you can't draw on it |
| Where the money comes from at posting | It goes onto the current statement; deposits still don't move | Debited straight out of the deposit account |
| How long the issuer fronts it | From settlement day to the payment due date. The earlier in the statement cycle you spend, the longer it runs — a statement cycle plus a grace period can reach fifty-odd days | A day or two. It comes out of your account at posting, at almost the same time the issuer pays the acquirer |
So "no money moved at the moment you tapped" holds for both cards, but "when the money leaves you" differs by an order of magnitude. If it feels to you like the money vanished the instant you paid, that was almost certainly a debit card — it debits at posting, with no statement layer in between.
This difference shows up immediately in the first trap of the next section: the $100 the gas station holds is credit headroom on a credit card, and real money in your account on a debit card.
4. Three Real-World Traps¶
Trap one: the pre-authorization amount doesn't match the real amount
The gas station holds $100 when you insert your card; you pump $40.
| Moment | Amount held | Amount captured | User's available balance |
|---|---|---|---|
| Card inserted | 100 | — | Down 100 |
| Tank filled | 100 | 40 | Still down 100 |
| After clearing completes | Released | 40 | Back to down only 40 |
That middle stretch is where the complaints pour in: the user sees "100 taken" when they only spent 40. If you're building the product, either explain it plainly up front, or the moment the real amount is known, send a void (void / reversal — a cancellation after authorization, before capture) and re-authorize for 40.
Trap two: a refund is not a void, and the fees don't come back
A refund is a brand-new transaction running the opposite direction, and it walks the full three-phase lifecycle all over again — which is why the user waits 3 to 5 days to see the money return.
The sharper point: the fees the merchant already paid usually don't come back with the refund. Interchange never does — the issuer already did its work and already carried the risk. The acquirer's share, under most contracts, doesn't either.
Run the numbers from the previous chapter:
| Step | Merchant's cash |
|---|---|
| Collect $100 | +97.70 |
| Refund $100 in full | −100.00 |
| Net result | −2.30 |
The merchant returned every cent of the purchase price — and is out another $2.30 in fees on top. This is why high-return categories (apparel, shoes) get hit unusually hard on payment costs.
Trap three: authorization expiry varies by industry
A hotel pre-authorization can sit for 30 days; ordinary retail, 7. Build your reconciliation system on one uniform expiry and you'll pile up authorized-never-captured items hanging open — miserable to chase down.
5. Side by Side: Void, Refund, Chargeback¶
The three words get used interchangeably, but they differ completely in timing, cost, and consequence.
| Dimension | Void | Refund | Chargeback |
|---|---|---|---|
| When it happens | Wrong order or changed amount, before the merchant captures | Money already received; customer returns or cancels; merchant agrees | The cardholder skips the merchant and goes straight to the issuer: a stolen card, a merchant refusing to respond, goods not as described |
| Who initiates | Merchant | Merchant | Cardholder |
| Timing | Before capture | After capture | After the transaction, with a window that can run past 120 days |
| Did money actually move? | Never moved | Moved, then went back | Moved, then forcibly clawed back |
| Fees | None | MDR already paid usually not returned | Merchant pays a separate dispute fee, commonly $15 to $25 |
| Mark on the merchant's record | None | None | Counts toward the chargeback ratio |
| Can the merchant fight it? | Not applicable | Not applicable | Yes — submit evidence and contest; the industry word is representment |
Why would a merchant rather refund voluntarily than take a chargeback?
Because chargebacks count toward the merchant's chargeback ratio, and the card networks set monitoring thresholds on that ratio. Cross the line and the merchant lands in a monitoring program and gets fined; stay over it and acquiring service can be cut off entirely — which means the business is over.
(The exact thresholds and counting rules keep shifting; when you build, go by the networks' currently published rules. For scale: the line sits below 1%.)
That's why so many e-commerce merchants agree to a refund the moment a dispute appears, even when they're in the right. It isn't generosity. It's spending $100 of merchandise money on insurance against one more entry in the chargeback count.
6. What the Message Looks Like: ISO 8583¶
A light touch only — you don't need to write it, but you need to know it exists and what constraints it imposes.
ISO 8583 is the card transaction message standard finalized in 1987, and the overwhelming majority of card authorizations worldwide still run on it today. It is a compact binary format that uses a "bitmap" to mark which fields are present in a given message.
A few common fields:
| Field | Meaning | Example |
|---|---|---|
| MTI | Message type | 0100 authorization request, 0110 authorization response |
| DE2 | Primary account number — the card number | — |
| DE4 | Transaction amount | Fixed-length digits with an implied decimal point |
| DE39 | Response code | 00 approved, 51 insufficient funds, 05 declined with no reason given |
| DE41 | Terminal ID | — |
Two things worth remembering:
- This is a 1987 standard — older than the commercial internet. It was designed to push an authorization across painfully thin leased-line bandwidth.
- A surprising number of today's inexplicable product constraints trace straight back to it. The amount field is fixed-length, so there are amount ceilings. Fields are numeric or a fixed character set, so merchant names show up on statements as strings of odd all-caps abbreviations. Response codes are two digits, so "transaction failed" often comes with no usable reason — DE39 returning 05 means the issuer flatly declined and won't say why.
The next chapter's 3DS (a flow in which the issuer verifies the cardholder's identity before authorization) and tokenization (swapping the real card number for a substitute, so the merchant never touches the real one) are both patches on this old skeleton, applied without ever overturning ISO 8583.
7. The Question This Chapter Leaves Open¶
Everything above rests on two premises: the card is present, and the person is present.
There is a physical card to put in a reader, and a live human to sign or key in a PIN. That is what keeps the issuer's risk manageable.
Buy something online and both premises vanish at once. The merchant gets nothing but a string of digits — no card in sight, no person in sight. A string of digits can be copied, resold, and used from any corner of the world.
So the question becomes: who proves the transaction was made by the cardholder? And when it can't be proven and fraud happens, whose loss is it?
The next chapter takes up those two questions, and the thirty-year technology arms race fought over them.
8. Self-check questions¶
- A user sees a "pending" transaction in their app. Using this chapter's vocabulary, say exactly whose hands the money is in at that moment.
- An apparel e-commerce business: average order $200, return rate 20%, gross margin 30%, payment fees at 2.3%. For every 100 orders sold, what is its true payment cost?
- Why are 3DS and tokenization "patches on the old skeleton" rather than a replacement for it?
9. Answers¶
Answer for yourself before reading on.
The money has not left anyone yet. All that happened is that the issuer placed a hold, shrinking the available credit; nothing has reached the statement and the cardholder's deposits haven't moved either. The merchant has received no funds either; what it holds is a promise that the issuer will pay. Only once clearing and settlement complete does money actually flow from issuer to acquirer to merchant. (On a debit card this step differs — see the comparison table after the status table: the hold sits on real money in the deposit account.)
Step by step:
- Sell 100 orders: volume 100 × 200 = $20,000; fees 20,000 × 2.3% = $460.
- 20 orders come back: refunds 20 × 200 = $4,000. The $4,000 in merchandise money goes back in full, but the matching 4,000 × 2.3% = $92 in fees is not returned.
- Orders kept: 80, for $16,000 in sales and 16,000 × 30% = $4,800 in gross profit.
- True payment cost = $460 (including the $92 in sunk fees on the returned orders).
- As a share of gross profit: 460 ÷ 4,800 ≈ 9.6%.
Cross-check: with zero returns, fees would be 16,000 × 2.3% = $368, or 7.7% of gross profit. The $92 between the two figures is exactly the sunk fees on returned orders — consistent with the calculation above.
Because neither touches the structure of the ISO 8583 authorization message itself. Tokenization only swaps the real card number inside DE2 for a substitute — and the substitute is itself a format-valid card number, so not one byte of the message changes. 3DS runs a separate flow of its own before authorization is initiated, and stuffs the result into the existing message as extra fields. Hundreds of thousands of institutions worldwide run on this standard; replacing it is impossibly expensive, so every innovation must start from "stays compatible with the old message." Which also explains why technical evolution in payments always looks like patch upon patch upon patch.
Previous: Chapter 6 · Interchange: The Economic Core of the Payments Industry Next: Chapter 8 · Card Not Present: A Thirty-Year Fraud Arms Race