Head of Product – Cards Business


# Inside a Card Transaction: Auth, Clearing, Settlement Explained

When you tap your card at a coffee shop, three distinct processes execute across multiple parties in different time windows. Understanding authorization, clearing, and settlement is fundamental to working in payments.

## The Players

Before diving into stages, meet the participants:

- **Cardholder**: You, with your Visa or Mastercard
- **Merchant**: The coffee shop
- **Acquirer**: The merchant's bank (processes payments on their behalf)
- **Card Network**: Visa, Mastercard, Amex (routes messages, sets rules)
- **Issuer**: Your bank (issued the card, holds your account)

## Stage 1: Authorization (Real-Time, <5 Seconds)

### The Flow

1. **Merchant terminal captures** card data (PAN, expiry, CVV) via chip, swipe, or contactless NFC
2. **Acquirer receives** transaction details: amount, merchant ID, card details
3. **Network routes** authorization request to the issuer based on card BIN
4. **Issuer evaluates**:
   - Is the card active and not blocked?
   - Does the account have sufficient funds?
   - Is this transaction consistent with spending patterns (fraud check)?
5. **Issuer responds**: Approve (00), Decline (05), or Call Issuer (01)
6. **Network routes** response back to acquirer
7. **Terminal displays** result to cardholder

### Authorization Data

The auth message includes:
- **Transaction amount** and currency
- **Merchant Category Code (MCC)**: 5812 for restaurants, 5541 for gas stations
- **Card-present vs card-not-present** indicator
- **Terminal capabilities**: chip, contactless, PIN-capable

### Holds and Reserves

Upon approval, the issuer **places a hold** on funds. This isn't a transfer—it's a reservation. The actual money movement happens later during settlement.

**Edge case**: Gas station pre-auths often hold $100-$150, then settle for actual pump amount days later. This is why you see temporary charges larger than what you spent.

## Stage 2: Clearing (Batch, Typically End-of-Day)

Hours after the coffee purchase, the merchant submits the transaction for clearing.

### The Process

1. **Merchant batches** all day's transactions (usually end-of-business)
2. **Acquirer aggregates** transactions from all merchants
3. **Network receives** clearing files from acquirers globally
4. **Network sorts and routes** to issuers based on card BIN
5. **Issuers receive** clearing records with final amounts

### Why Clearing Matters

Clearing reconciles authorization with actual transaction details:

- **Amount adjustment**: Pre-auth $100, actual $87.50 (gas station scenario)
- **Tip addition**: Restaurant auth $45, clears $54 after 20% tip
- **Offline transactions**: Subway fare gates without real-time connectivity

### Data Enrichment

Clearing messages are richer than auth:
- **Full merchant name and address**
- **Enhanced transaction metadata**
- **Tax and tip breakdowns** (in some jurisdictions)

This is when your bank statement gets populated with "STARBUCKS #8472 SEATTLE WA" instead of just "MERCHANT 12345".

## Stage 3: Settlement (Batch, T+1 or T+2)

Settlement is the actual exchange of funds between banks.

### The Flow

1. **Network calculates net positions**: If Bank A's cardholders spent $10M at Bank B's merchants, and vice versa spent $8M, Bank A owes Bank B a net $2M
2. **Central bank accounts** are debited/credited via wholesale payment systems (Fedwire in US, CHAPS in UK)
3. **Acquirer credits** merchant's bank account (minus MDR fees)
4. **Issuer debits** cardholder's account (or adds to credit card balance)

### Timing

- **Domestic cards**: Usually T+1 or T+2 (1-2 business days after transaction)
- **International cards**: Can extend to T+3 or longer due to currency conversion and cross-border settlement
- **Real-time settlement**: Emerging in some markets, but not yet standard for card networks

### Interchange Fees

During settlement, **interchange fees** are calculated and transferred. If you bought $100 coffee with a Visa Signature card:

- Merchant receives: ~$97.50 (after ~2.5% MDR)
- Breakdown of MDR:
  - **Interchange**: ~1.8% goes to issuer (rewards funding, fraud liability)
  - **Network fee**: ~0.15% to Visa/Mastercard
  - **Acquirer margin**: ~0.55% to merchant's bank

## Authorization vs Settlement Mismatches

What happens when auth and settlement amounts differ?

- **Partial reversals**: Hotel pre-auths $500, settles $300 after early checkout. Issuer releases $200 hold.
- **Incremental auths**: Car rental auths $100/day, extends stay and adds $100 more. Multiple auths, one settlement.
- **Timeout reversals**: Auth approved but merchant never submits for clearing (network disconnects). Auto-reversal after 7-10 days.

## Chargebacks: The Exception Flow

If the cardholder disputes a transaction:

1. **Issuer initiates chargeback** via the network (up to 120 days post-transaction)
2. **Acquirer debits** merchant's account
3. **Merchant can accept** or **dispute with evidence** (proof of delivery, signed receipt)
4. **Arbitration**: Network decides if merchant evidence stands

Chargebacks reverse the settlement flow. Funds move back from merchant to cardholder.

## Key Takeaways

- **Authorization** is real-time approval, not fund movement
- **Clearing** provides transaction details and reconciles amounts
- **Settlement** is the actual money transfer between banks
- **Timing** varies: auth is instant, settlement is days later
- **Fees** are calculated during settlement, not authorization

Understanding this three-stage model is critical for building payment products, debugging transaction issues, and explaining why "pending" charges can take days to finalize or reverse.


A technical deep dive into the three-stage journey of a card transaction from authorization to final settlement.

Inside a Card Transaction: Auth, Clearing, Settlement Explained


# Wallet Tokenization Across Apple/Google/Samsung Pay

When you add a card to Apple Pay, Google Pay, or Samsung Pay, the actual card number (PAN) never touches the payment terminal. Instead, a **token**—a surrogate number with no intrinsic value—represents your card. This is payment tokenization, and it's the security foundation of mobile wallets.

## Why Tokenization Exists

Traditional card payments expose the PAN at multiple points:
- On the physical card (embossed or printed)
- In merchant databases (for card-on-file subscriptions)
- In transmission to payment processors

A compromised database or intercepted transaction = stolen card credentials = fraud.

Tokenization solves this by **de-coupling the payment instrument from its identifier**.

## How It Works: The Token Lifecycle

### 1. Card Provisioning (Adding to Wallet)

When you add a Visa to Apple Pay:

1. **Apple collects** card details via camera scan or manual entry
2. **Issuer authenticates** you (SMS OTP, bank app verification, call center)
3. **Apple requests token** from Visa Token Service
4. **Visa generates**:
   - **DPAN** (Device PAN): A 16-digit number that looks like a card number but isn't
   - **Cryptographic keys**: Unique per device, used to generate transaction-specific codes
5. **Apple stores** DPAN and keys in the device Secure Element (tamper-resistant chip)

The original PAN never leaves the issuer's systems. The wallet only knows the DPAN.

### 2. Transaction Authorization

When you tap to pay:

1. **Wallet generates** a one-time cryptogram using:
   - DPAN
   - Transaction amount
   - Device-specific keys
   - Counter (increments with each transaction)
2. **Terminal receives**: DPAN + cryptogram (not PAN)
3. **Acquirer routes** to card network
4. **Token service** (Visa/Mastercard) translates DPAN → PAN
5. **Issuer authorizes** using real PAN but only sees DPAN in logs
6. **Approval flows back** through the chain

### 3. Token Lifecycle Management

Tokens aren't permanent:

- **Suspend**: User reports phone lost → issuer suspends DPAN via token service → Apple Pay can't transact, but physical card still works
- **Resume**: Phone found → issuer resumes DPAN
- **Delete**: User removes card from wallet → token permanently deleted
- **Re-tokenize**: New device, new DPAN (same physical card can have multiple active tokens)

## Platform Differences

### Apple Pay

- **Storage**: Secure Element (dedicated hardware chip)
- **Authentication**: Face ID, Touch ID, or passcode required per transaction
- **Coverage**: iPhone, Apple Watch, Mac (with Touch ID), iPad
- **Issuer control**: High. Banks must integrate with Apple's APIs and pay fees
- **Offline transactions**: Limited support (transit systems via Express Transit)

### Google Pay

- **Storage**: Host Card Emulation (HCE) or Secure Element (device-dependent)
- **HCE**: Tokenization handled in cloud, cryptograms generated server-side
- **Authentication**: Device unlock (PIN, fingerprint, face) or per-transaction prompt
- **Coverage**: Android phones, Wear OS watches
- **Issuer control**: More flexible integration options than Apple
- **Offline**: Rare, primarily cloud-connected

### Samsung Pay

- **Storage**: Secure Element (Knox-protected)
- **Authentication**: Fingerprint, iris scan, or PIN
- **Unique feature**: MST (Magnetic Secure Transmission) emulates a mag-stripe card swipe—works at non-NFC terminals (being phased out)
- **Coverage**: Samsung Galaxy devices
- **Issuer control**: Similar to Apple Pay, requires direct partnership

## Token Domains

Not all tokens work everywhere. EMVCo defines token **domains**:

- **Contactless (NFC)**: Tap-to-pay at physical terminals
- **E-commerce**: Online transactions (rare, mostly card-on-file uses different token types)
- **In-app**: Payments within mobile apps using wallet SDKs

An Apple Pay DPAN provisioned for contactless won't work for e-commerce. Each domain requires separate tokenization.

## Security Advantages

### 1. Merchant Breach Immunity

If a retailer's database is compromised, attackers get DPANs—useless without:
- Device-specific cryptographic keys (stored in Secure Element)
- Biometric authentication to unlock wallet
- Proximity to NFC terminal (can't replay online)

### 2. No Static CVV

Physical cards have a static CVV2 printed on the back. DPAN transactions use **dynamic CVVs**—the cryptogram changes every transaction. Replay attacks fail.

### 3. Device Binding

Each token is tied to a specific device's Secure Element. Cloning the DPAN to another device doesn't work—the cryptographic keys don't transfer.

### 4. Granular Control

Issuer can suspend a token without blocking the physical card. User switches phones → old token deleted, new one provisioned, no new plastic needed.

## Challenges and Limitations

### Issuer Integration Complexity

Supporting wallets requires:
- **Token Service Provider (TSP) integration**: Visa Token Service, Mastercard MDES
- **Cardholder verification**: SMS, app-based auth, call centers
- **Real-time provisioning APIs**: Approve/decline token requests in <5 seconds
- **Lifecycle management**: Sync suspend/resume/delete events

Smaller issuers often outsource this to processors.

### Cross-Platform Fragmentation

A cardholder with both iPhone and Samsung has **two separate DPANs** for the same card. Fraud patterns and spending limits must account for multi-device scenarios.

### Limited Merchant Acceptance

Tokenized NFC payments require:
- Contactless-enabled terminals
- Processor support for cryptogram validation

Not universal, especially in cash-heavy or legacy-infrastructure markets.

### Offline Transaction Constraints

Cryptogram generation typically requires network connectivity. Transit systems using Express Transit pre-load a limited number of offline cryptograms, but this isn't scalable for general retail.

## The Future: Cloud-Based Wallets

Emerging trend: **cloud tokens** instead of device-bound ones. Benefits:
- User switches phones → no re-provisioning, same token follows
- Multi-device sync (pay with phone, watch, laptop using same DPAN)
- Easier fraud detection (single token view across devices)

**Tradeoff**: Security moves from hardware (Secure Element) to cloud HSMs (Hardware Security Modules). More convenient, slightly higher remote attack surface.

## Key Takeaways

- **Tokenization** replaces card numbers with device-specific surrogates
- **DPANs** are worthless without the device's cryptographic keys
- **Each wallet platform** (Apple, Google, Samsung) has unique architectures
- **Issuers** must integrate with token service providers and handle provisioning
- **Security gains** are significant: breach immunity, dynamic CVVs, granular control
- **Future** is cloud-native, cross-device token portability

Payment tokenization is why mobile wallets are safer than plastic cards. The physical card is the legacy liability; the token is the secure future.


Understanding how mobile wallets secure card data through tokenization and how it works across different platforms.

Payment Systems

Inside a Card Transaction: Auth, Clearing, Settlement Explained

Wallet Tokenization Across Apple/Google/Samsung Pay