How Payments Actually Work

A card payment takes two seconds to approve and one to three business days to settle. The money your bank app shows as "pending" hasn't moved yet.

What happened in those two seconds was a conversation between five parties to decide whether you're good for $4.50. Your bank placed a hold on your available credit, the merchant's bank got a promise, and the actual dollars won't change hands until a batch file runs overnight.

Between the instant approval and the eventual settlement, the transaction passes through three distinct phases. Each involves different parties, runs on a different timeline, and fails in its own way.

Five parties, one transaction

A card payment looks like one interaction: you hand over money, a merchant receives it. Under the surface, five entities coordinate every swipe.

The cardholder is you. The person tapping, swiping, or typing in a card number.

The merchant is the business accepting the payment. They never talk to your bank directly.

The acquirer is the merchant's bank. It receives settlement funds from the network and deposits them into the merchant's account, minus fees.

The card network (Visa, Mastercard, American Express, or Discover) sits in the middle. It routes authorization messages between the acquirer and the issuer, enforces the rules both banks agreed to follow, and runs the clearing and settlement process.

The issuer is your bank. It decides whether to approve the transaction, places a hold on your available credit, and eventually transfers the funds.

There's a sixth entity most merchants interact with more than any of these: the payment gateway. When you integrate with Stripe or Adyen, the gateway is the API layer that accepts the transaction from the merchant's checkout, encrypts it, and forwards it to the acquirer. Some gateways also act as the acquirer, bundling both roles. Stripe does this. So does Adyen. Others, like Braintree, route to a separate acquiring bank. The distinction matters because it determines who holds the merchant's funds during the settlement window and who the merchant negotiates processing rates with.

Some platforms go further, abstracting across cards, ACH, RTP, and FedNow behind a single API so developers never pick a rail directly. That's a different architecture from the gateway-acquirer model.

Authorization: the two-second decision

When you tap your card, the merchant's terminal sends a request through the chain. At a physical terminal, the request goes straight from the terminal to the acquirer. In e-commerce, a gateway sits between the merchant's checkout and the acquirer, handling encryption, tokenization, and the API layer that developers actually integrate with.

A gateway exists because most merchants don't have a direct relationship with an acquiring bank. The acquirer speaks ISO 8583, a binary protocol designed for interbank messaging. The gateway translates the merchant's API call into that format. If you've integrated with Stripe's Charges API or Adyen's checkout SDK, you've talked to a gateway. You've never spoken directly to an acquirer, and you don't need to.

From the acquirer, the request routes through the card network to your issuer. The issuer checks whether the account exists, whether it has enough available credit, whether velocity limits have been exceeded, and whether the fraud models flag anything suspicious.

If everything passes, the issuer sends back an approval code, routed from issuer to network to acquirer to gateway (if present) to terminal. The terminal beeps, and the barista starts making your drink.

What actually happened is that the issuer placed a hold on your available credit for the transaction amount. Your limit dropped by $4.50, but neither the acquirer nor the card network has moved any money. Everyone has agreed that the money will move later, and that agreement is the authorization.

Americans make roughly 514 million card payments per day. Visa's network alone can handle over 65,000 transaction messages per second at peak. Each authorization message follows ISO 8583, a binary format that packs the card number, amount, merchant category, terminal ID, and dozens of other data elements into a single structured packet.

The authorized amount isn't always the final amount. A gas station might authorize $1 just to verify the card, then submit $47 when you're done pumping. A hotel authorizes $500 at check-in and submits $387 at checkout. A restaurant authorizes $50 for dinner, then submits $58 after the tip.

If you're building a payment system, your data model needs authorization and final amount as two separate fields, because they routinely differ.

Clearing: the overnight reconciliation

Hours after your coffee purchase, the merchant's payment system gathers the day's approved transactions into a batch and submits them to the acquirer. The acquirer forwards the batch through the card network. The network sorts every transaction by issuer and delivers each issuer a file of charges their cardholders made that day.

This batch process confirms what happened and calculates who owes whom.

Why batch instead of real-time? The arithmetic makes it obvious at scale. Visa processed roughly 259 billion transactions in fiscal year 2024. Settling each one individually would be like running a separate delivery truck for every letter in a city instead of sorting them at a distribution center first.

The network calculates net positions instead. If an issuer's cardholders spent $8 million at merchants using Acquirer A today, while Acquirer A's merchants refunded $200,000 back to those cardholders, the network records a single obligation of $7.8 million. One transfer covers hundreds of thousands of individual purchases.

Clearing is also when the final amount gets locked in. The restaurant's $58 with tip replaces the original $50 authorization. Partial refunds adjust the clearing total. Authorization was a promise, and clearing is the invoice that confirms what's actually owed.

Settlement: when money actually moves

Settlement is when dollars change hands. The card network instructs issuers and acquirers to move net amounts between their settlement accounts, typically held at a designated settlement bank. For Visa and Mastercard in the US, settlement usually happens at T+1 or T+2 from the clearing date.

The acquirer then deposits the net amount into the merchant's bank account, usually as a single daily transfer that covers all settled transactions, minus fees. One deposit for hundreds of individual sales.

Reconciling that deposit back to individual transactions requires understanding the fee schedule and netting logic. The deposit amount is gross sales minus interchange, minus network assessment fees, minus the processor's markup, minus any chargebacks or adjustments that hit during the cycle. Without a model for every deduction, the number in your bank account won't match your internal records.

After settlement, the hold on your credit card converts to a posted charge and the pending label disappears. But settlement doesn't mean the transaction is irreversible. A chargeback can arrive 120 days later, and an ACH return can come back up to 60 days out.

My piece on settlement and finality covers why treating "settled" as a terminal state is a design mistake that breaks your ledger.

The fee stack

Every card swipe carries fees, and they flow in one direction: from merchant to everyone else.

Interchange is the largest piece, going from the acquirer to the issuer. On a typical credit card transaction, interchange runs between 1.5% and 3% of the amount. Debit cards are cheaper at 0.5% to 1%, and the Durbin Amendment caps interchange on regulated debit cards from banks with over $10 billion in assets at roughly 21 cents plus 5 basis points per transaction.

On a $100 purchase, that cap means about $0.26 in debit interchange versus roughly $1.75 on a credit card. The gap explains why merchants push customers toward debit and PIN entry.

Network assessment fees go to Visa or Mastercard. Both networks charge a small percentage, typically around 0.13% to 0.15%, plus a per-transaction fee of a fraction of a cent.

Processor markup goes to whoever handles the technical integration. Stripe's standard rate of 2.9% plus $0.30, for example, bundles interchange, assessment, and their own margin into a single blended price. Under interchange-plus pricing, which larger merchants negotiate, you pay the actual interchange rate plus a fixed markup, so cheaper card types cost you less.

On a $100 credit card purchase, a typical split might be $1.75 to the issuer in interchange, $0.13 to the card network in assessments, and about $0.25 to the processor. The merchant keeps roughly $97.87. Switch to a regulated debit card, and the merchant keeps about $99.36 on the same purchase because interchange drops from $1.75 to $0.26.

What this means if you're building

Authorization and clearing amounts are different values in your data model. If you overwrite one with the other, you'll break reconciliation for any merchant that adjusts after authorization. Restaurants, hotels, gas stations, car rental agencies, and subscription services all produce amounts that change between the two phases.

Chargebacks, returns, and adjustments can arrive weeks or months after settlement. My piece on what chargebacks actually cost covers how disputes cascade well beyond the fee on the statement into network monitoring programs, acquirer termination, and five-year blacklists.

Your bank statement won't show individual card transactions. It shows net settlement deposits after fees. Without a model for the fee schedule, netting logic, and reversal windows, the number in your bank account and the number in your ledger will slowly drift apart. Reconciliation at the aggregate level, not the transaction level, is the only way to keep them aligned.

Each of these phases runs on its own timeline, with its own participants and its own failure modes. Treating a two-second approval as the complete picture is the most expensive assumption in payment engineering.