How Card Payments Work: Authorization to Settlement

How a Card Payment Moves From Authorization to Settlement

A card payment separates the decision to approve a purchase from the later exchange of transaction records and money. Authorization, capture, clearing, settlement, merchant payout, and exception handling can involve different systems, times, and responsibilities.

The tap feels like one event because the customer sees one interface. The payment is a lifecycle.

sequenceDiagram
    participant C as Cardholder
    participant M as Merchant
    participant A as Acquirer or processor
    participant N as Card network
    participant I as Issuer
    C->>M: Presents card credential
    M->>A: Authorization request
    A->>N: Routes request
    N->>I: Requests issuer decision
    I-->>N: Approve or decline
    N-->>A: Returns response
    A-->>M: Returns response
    M->>A: Captures approved transaction
    A->>N: Sends clearing record
    N->>I: Calculates obligations
    I-->>A: Interbank settlement
    A-->>M: Merchant payout under agreement

The actors in a common card transaction

The cardholder presents a card or tokenized card credential. The merchant accepts the payment. The issuer is the institution that issued the card and decides whether to approve the attempt. The acquirer contracts with the merchant for card acceptance and settlement. The payment-card network routes information between the acquiring and issuing sides.

A gateway or processor may supply the merchant interface, route messages, tokenize credentials, and manage connections. One company can perform several roles.

The Federal Reserve's Regulation II definitions provide useful U.S. debit-card definitions for acquirer, issuer, merchant, network, processor, and interchange fee. The arrangement for a specific credit, debit, prepaid, wallet, or cross-border transaction can differ.

Authorization answers whether to proceed

At checkout, the merchant submits an authorization request. It can include the amount, merchant information, credential data, transaction type, and authentication results.

The request moves through the acquiring side and network to the issuer. The issuer applies account, credit or funds, fraud, credential, and policy checks. It returns an approval or decline, often with an authorization code.

Approval does not mean the merchant has final funds. It means the issuer approved that payment attempt under the information and rules available at that moment.

An authorization can later expire, reverse, or remain uncaptured. Some merchant categories use estimated amounts or later adjustments under specific rules. The exact behavior comes from the product and merchant agreement.

Capture tells the system what to submit

Capture is the merchant's instruction to submit an approved transaction for clearing. A merchant can capture immediately or later, depending on its integration and rules.

The captured amount can match the authorized amount. In some allowed workflows, the final amount differs because of tips, shipping, partial fulfillment, or another adjustment.

Separating authorization and capture helps a business avoid completing a charge before it knows what it can fulfill. It also creates reconciliation work. The merchant must match the order, authorization, capture, and any reversal.

Clearing exchanges the detailed records

During clearing, acquirers, networks, and issuers exchange the records needed to post transactions and calculate obligations.

This stage applies network rules and fee relationships. Interchange commonly compensates the issuer. Network, acquirer, processor, gateway, fraud, cross-border, and other fees can appear separately under the merchant's contract.

A single public percentage cannot describe every merchant's cost. Pricing depends on card type, geography, merchant category, transaction channel, processor agreement, risk, services, and other conditions.

Settlement moves net positions

Settlement transfers money between the institutions after clearing. The Federal Reserve's four-party-system paper explains the common flow from issuer to merchant acquirer through network settlement arrangements.

Merchant payout is a related but separate event. The acquirer or processor credits a merchant balance and pays the merchant according to its contract, schedule, reserves, risk controls, and bank connection.

“Settled” can therefore refer to interbank settlement, availability in a processor balance, or arrival in the merchant's bank account. A precise explanation names the layer.

Reconciliation proves the money matched the order

The merchant needs to connect orders, authorizations, captures, fees, balance entries, deposits, refunds, disputes, taxes, and accounting records.

A deposit can contain many transactions net of fees and adjustments. Reconciliation explains why the bank amount differs from gross sales and identifies missing, duplicated, delayed, or reversed items.

The operational value of a mature payment rail is not merely message routing. It includes reports, identifiers, network rules, support, and exception processes that help institutions resolve mismatches.

A refund is not the same as a dispute

A refund is initiated by the merchant to return value. It can follow the card rail back toward the cardholder account, and the merchant's available balance may fund it.

A dispute starts when a cardholder challenges a transaction through the issuer. The network and processor carry evidence and decisions under applicable rules. A chargeback can debit the merchant while the claim is resolved or after a decision.

U.S. credit-card billing errors also have statutory and regulatory procedures. The CFPB's current Regulation Z section 1026.13 describes error notices, investigations, timing, disputed amounts, and creditor duties. Those rights should not be generalized to every card type or country.

Fraud and dispute are also different. A transaction can be authorized and later alleged to be unauthorized. A legitimate cardholder can dispute goods or services. A merchant can issue a refund without any dispute.

Why authorization speed is not the whole product

The card network carries a fast approval message, but its value extends into acceptance, rules, risk, clearing, settlement, refunds, disputes, and support.

That full lifecycle explains why a stablecoin transfer cannot be compared with a card payment by confirmation time alone. [[How a Stablecoin Payment Moves From Wallet to Merchant]] maps the other rail. [[Card Payments or Stablecoins A Lifecycle Comparison]] shows how to compare both for one customer and corridor.

Editorial note

This explainer was developed with AI assistance from E043 and the linked Federal Reserve, CFPB, and payment-product sources. Dalton Anderson remains the author. Payments, financial, legal, fee, timing, jurisdiction, product, source, and founder review are mandatory before publication. This page is not financial, legal, tax, accounting, payment-processing, or consumer-rights advice. Publication is not authorized.