Skip to content

Instantly share code, notes, and snippets.

@aungkyawminn

aungkyawminn/00-Card-Payments-Basics.md

Last active September 15, 2025 09:47
Show Gist options
  • Save aungkyawminn/d430b774f2ef630271fa05d8637dc602 to your computer and use it in GitHub Desktop.
Save aungkyawminn/d430b774f2ef630271fa05d8637dc602 to your computer and use it in GitHub Desktop.
Download ZIP
Card Payments Basics
Raw
00-Card-Payments-Basics.md

Card payments processing is the global system that enables money to move securely between cardholders, merchants, banks, and networks. The lifecycle covers multiple stages — from the first tap or swipe at a POS terminal, to settlement of funds, reconciliation of records, and handling of exceptions like disputes or refunds.

Understanding these steps is essential for anyone entering the payments domain, because each process has its own purpose, participants, and standard ISO 8583 messages.

This guide walks you through 13 key processes with short explanations and visual Mermaid sequence diagrams.

A) Core sequential phases — backbone of most card payments

  1. Authorization
  2. Clearing
  3. Settlement
  4. Network & Fee Settlement
  5. Reconciliation

B) Channel or device specific flows — front-end variants of Authorization

  1. POS Merchant Authorization
  2. E-commerce with 3DS
  3. ATM Cash Withdrawal
  4. Pre-Authorization & Completion

C) Exceptions and after-the-fact handling — only when needed

  1. Reversal
  2. Refund
  3. Chargebacks Lifecycle
  4. Exception & Dispute Handling
Raw
01-Authorization.md

The real-time approval step when a card is used at a Channel Varients like POS or E-commerce Website/App or ATM. The issuer checks if the card is valid, has sufficient funds or credit, and whether the transaction should be approved or declined.

  • What: Real time decision to approve or decline
  • When: At transaction time
  • Who: Merchant or ATM → Acquirer → Network → Issuer
  • Signals: ISO 8583 0100 and 0110, approval code, risk checks, limits
flowchart LR
    subgraph Channel Variants
        POS[POS Merchant]
        Ecom[E-commerce Merchant]
        ATM[ATM Device]
        PreAuth[Pre-Auth Merchant]
    end

    POS --> Auth
    Ecom --> Auth
    ATM --> Auth
    PreAuth --> Auth

    subgraph Authorization Flow
        A1[Acquirer]
        A2[Network]
        A3[Issuer]
    end

    Auth -.0100 Req.-> A1
    A1 -.0100 Req.-> A2
    A2 -.0100 Req.-> A3
    A3 -.0110 Resp.-> A2
    A2 -.0110 Resp.-> A1
    A1 -.0110 Resp.-> Auth
Loading
Raw
02-Clearing.md

The end-of-day process where merchants send all their approved transactions in batches. The acquirer forwards them through the card network to issuers, who record the amounts on the cardholder’s account.

  • What: Move captured items to issuers for posting.
  • When: End-of-day or intraday batches.
  • Who: Merchant → Acquirer → Network → Issuer.
  • Signals: 0200/0210 or scheme clearing files; tips/adjustments/FX flags.
sequenceDiagram
    autonumber
    participant Merchant
    participant Acquirer
    participant Network
    participant Issuer

    Note right of Merchant: At end of day merchant closes batch
    Merchant->>Acquirer: Send captured transactions
    Acquirer->>Network: Send ISO 8583 financial messages MTI 0200 or clearing files
    Network->>Issuer: Forward clearing transactions
    Issuer->>Issuer: Post debit to cardholder account
    Issuer-->>Network: Send acknowledgement 0210
    Network-->>Acquirer: Relay acknowledgement
    Acquirer-->>Merchant: Confirm cleared
Loading
Raw
03-Settlement.md

The actual movement of money between banks. The card network calculates net amounts owed, issuers pay the network, acquirers receive funds, and merchants are credited after deducting fees.

  • What: Actual funds movement between banks.
  • When: T+1/T+2 typically.
  • Who: Network netting; Issuers pay, Acquirers receive; merchants funded.
  • Signals: Scheme settlement reports; bank credits/debits.
sequenceDiagram
    autonumber
    participant Acquirer
    participant Network
    participant Issuer
    participant MerchantAccount

    Note over Network: Network calculates net positions
    Issuer->>Network: Pay net owed to scheme
    Network->>Acquirer: Release net funds to acquirer
    Acquirer->>MerchantAccount: Credit merchant account minus fees
Loading
Raw
04-Network-&-Fee-Settlement.md

Card networks also settle fees, interchange, and scheme charges between acquirers and issuers.

  • What: Settlement of interchange, scheme fees, and other charges.
  • When: Alongside principal settlement cycles.
  • Who: Network, Issuer, Acquirer, Merchant (via MDR).
  • Signals: Fee statements, interchange summaries, net positions.
- Interchange fee → issuer’s earning per transaction.
- MDR (Merchant Discount Rate) → merchant’s cost of acceptance.
- Networks charge scheme fees for using their rails.

sequenceDiagram
    autonumber
    participant Network
    participant Issuer
    participant Acquirer
    participant Merchant

    Note over Network: Calculate net settlement and fees
    Network->>Issuer: Provide fee and interchange reports
    Network->>Acquirer: Provide fee and interchange reports
    Issuer->>Network: Pay scheme fees and interchange
    Network->>Acquirer: Credit acquirer net funds
    Acquirer->>Merchant: Credit merchant net amount after MDR and fees
Loading
Raw
05-Reconciliation.md

The process of matching records across systems (merchant, acquirer, issuer, network) to ensure all transactions, fees, and settlements align.

  • What: Match records across systems to find misses/dups/out-of-balance.
  • When: Post-settlement daily; also intraday for high-volume ops.
  • Who: Merchant finance, Acquirer ops, Issuer ops.
  • Signals: Merchant vs acquirer vs network vs CBS ledgers; exception queues.
- Merchant Reconciliation → compares POS totals vs. acquirer settlement reports.
- Issuer Reconciliation → matches network files vs. CBS postings.
- Helps detect missing, duplicate, or misposted transactions.

sequenceDiagram
    autonumber
    participant Merchant
    participant Acquirer
    participant Network
    participant Issuer
    participant MerchantLedger
    participant IssuerCBS

    Merchant->>Acquirer: Send daily totals and itemized reports
    Acquirer->>Network: Compare clearing files and settlement reports
    Network->>Acquirer: Provide scheme reports and fee details
    Acquirer->>Merchant: Provide settlement file and fee statement
    Merchant->>MerchantLedger: Match POS records versus acquirer file
    Issuer->>Network: Receive clearing files and settlement positions
    Issuer->>IssuerCBS: Post to cardholder accounts and fees
    IssuerCBS->>Issuer: Generate reconciliation exceptions
    Note right of MerchantLedger: Investigate missing duplicate and out of balance items
Loading
Raw
06-POS-Merchant-Authorization.md
  • What: Card-present EMV/contactless auth at terminal.
  • When: At checkout.
  • Who: POS → Acquirer → Network → Issuer.
  • Signals: 0100/0110, EMV/CVM data; capture to batch if approved.

POS Merchant Authorization

sequenceDiagram
    autonumber
    participant Cardholder
    participant MerchantPOS
    participant Acquirer
    participant Network
    participant Issuer

    Cardholder->>MerchantPOS: Present card and enter PIN or tap
    Note right of MerchantPOS: Terminal creates ISO 8583 message MTI 0100 Authorization Request
    MerchantPOS->>Acquirer: Send 0100 Authorization Request
    Acquirer->>Network: Forward 0100
    Network->>Issuer: Deliver 0100
    Issuer->>Issuer: Check card validity funds limits fraud
    Issuer-->>Network: 0110 Authorization Response with approval code or decline
    Network-->>Acquirer: Relay 0110
    Acquirer-->>MerchantPOS: Relay 0110
    MerchantPOS-->>Cardholder: Show Approved or Declined
Loading
Raw
07-E-Commerce with 3DS (3-D Secure).md

A card-not-present (CNP) transaction with extra security. The cardholder is authenticated (via OTP, biometric, or risk checks) before authorization, shifting liability for fraud away from the merchant.

  • What: Card-not-present auth with 3-D Secure to reduce fraud and shift liability.
  • When: Before sending auth.
  • Who: Merchant/PSP ↔ Directory Server ↔ Issuer ACS; then normal auth path.
  • Signals: 3DS result token CAVV/ECI → included in 0100; 0110 response.
sequenceDiagram
    autonumber
    participant Cardholder
    participant Merchant
    participant DirectoryServer
    participant IssuerACS
    participant Acquirer
    participant Network
    participant Issuer

    Cardholder->>Merchant: Enter card details
    Merchant->>DirectoryServer: Send authentication request 3DS
    DirectoryServer->>IssuerACS: Forward request
    IssuerACS->>Cardholder: Challenge with OTP or biometric if needed
    IssuerACS-->>DirectoryServer: Send authentication result token
    DirectoryServer-->>Merchant: Relay token
    Note right of Merchant: Merchant adds 3DS token to ISO 8583 0100
    Merchant->>Acquirer: Send 0100 Authorization Request with 3DS data
    Acquirer->>Network: Forward 0100
    Network->>Issuer: Deliver 0100
    Issuer->>Issuer: Validate funds and 3DS authentication
    Issuer-->>Network: 0110 Authorization Response
    Network-->>Acquirer: Relay 0110
    Acquirer-->>Merchant: Relay 0110
    Merchant-->>Cardholder: Show Approved or Declined
Loading
Raw
08-ATM-Cash-Withdrawal.md

When a cardholder withdraws cash from an ATM. If the ATM belongs to the same bank (on-us), the request stays internal; if it belongs to another bank (off-us), the request goes via the card network.

sequenceDiagram
    autonumber
    participant Cardholder
    participant ATM
    participant Acquirer
    participant Network
    participant Issuer

    Cardholder->>ATM: Insert card and enter PIN
    ATM->>Acquirer: Send ISO 8583 0100 cash withdrawal
    alt On-Us same bank
        Acquirer->>Issuer: Process request internally
        Issuer-->>Acquirer: 0110 Response
    else Off-Us different banks
        Acquirer->>Network: Forward 0100
        Network->>Issuer: Deliver 0100
        Issuer-->>Network: 0110 Response
        Network-->>Acquirer: Relay 0110
    end
    Acquirer-->>ATM: Relay 0110
    ATM-->>Cardholder: Dispense cash or show decline
Loading
Raw
09-Pre-Authorization-and-Completion.md

Used when the final transaction amount is not yet known (e.g., hotels, fuel stations, car rentals).

  • What: Reserve funds first, finalize later when amount is known.
  • When: Hotels, fuel, rentals.
  • Who: Merchant → normal auth path; later completion to finalize.
  • Signals: Pre-auth 0100/0110 hold; completion 0200/0210 posts final amount.
- Merchant requests a pre-auth hold (e.g., $100).
- Later, merchant sends completion with the final amount (e.g., $87).
- Ensures funds are reserved but adjusted later.

sequenceDiagram
    autonumber
    participant Cardholder
    participant Merchant
    participant Acquirer
    participant Network
    participant Issuer

    Cardholder->>Merchant: Present card where final amount unknown
    Merchant->>Acquirer: Send ISO 8583 0100 pre authorization request
    Acquirer->>Network: Forward 0100
    Network->>Issuer: Deliver 0100
    Issuer-->>Network: 0110 pre authorization approved with hold
    Network-->>Acquirer: Relay 0110
    Acquirer-->>Merchant: Relay 0110
    Note right of Merchant: Hold reserves funds for a maximum validity window
    Merchant->>Acquirer: Send ISO 8583 0200 completion final amount
    Acquirer->>Network: Forward 0200
    Network->>Issuer: Deliver 0200
    Issuer-->>Network: 0210 completion response
    Network-->>Acquirer: Relay 0210
    Acquirer-->>Merchant: Relay 0210
    Note right of Merchant: Completion replaces hold with final posting during clearing and settlement
Loading
Raw
10-Reversal.md

A cancellation of a transaction before it is cleared.

  • What: Cancel prior auth/financial to remove a pending hold or duplicate.
  • When: Timeouts, POS failures, ATM no-cash situations.
  • Who: Merchant/ATM → Acquirer → Network → Issuer.
  • Signals: 0420/0430; clears pending amounts.
- Example: POS connection lost after authorization, or ATM did not dispense cash.
- Uses ISO 0420/0430 messages.
- Prevents double charges or unresolved “pending” amounts.

sequenceDiagram
    autonumber
    participant Cardholder
    participant MerchantPOS
    participant Acquirer
    participant Network
    participant Issuer

    Cardholder->>MerchantPOS: Attempt transaction
    MerchantPOS->>Acquirer: Send ISO 8583 0100 authorization request
    alt Authorization succeeded but completion failed
        MerchantPOS->>Acquirer: Send ISO 8583 0420 reversal request
        Acquirer->>Network: Forward 0420
        Network->>Issuer: Deliver 0420
        Issuer-->>Network: 0430 reversal response
        Network-->>Acquirer: Relay 0430
        Acquirer-->>MerchantPOS: Relay 0430
    else Authorization failed or timed out
        MerchantPOS->>Acquirer: Cancel local hold and notify customer
    end
    Note right of MerchantPOS: Reversal removes pending hold and prevents duplicate posting
Loading
Raw
11-Refund.md

A reverse payment initiated by the merchant to return funds to the cardholder (for returned goods or service issues).

  • What: Merchant voluntarily returns funds to cardholder.
  • When: Post-sale adjustments, returns, service issues.
  • Who: Merchant → standard financial path.
  • Signals: 0200/0210 refund; clears and settles like a sale but credit.
- Unlike a chargeback, it is voluntary by the merchant.
- Flows like a financial transaction (ISO 0200).

sequenceDiagram
    autonumber
    participant Cardholder
    participant Merchant
    participant Acquirer
    participant Network
    participant Issuer

    Cardholder->>Merchant: Request refund for goods or service
    Merchant->>Acquirer: Send ISO 8583 0200 refund request
    Acquirer->>Network: Forward 0200
    Network->>Issuer: Deliver 0200
    Issuer->>Issuer: Validate original sale and card status
    Issuer-->>Network: 0210 response approved or declined
    Network-->>Acquirer: Relay 0210
    Acquirer-->>Merchant: Relay 0210
    Merchant-->>Cardholder: Inform refund result
    Note right of Merchant: Refund will clear and settle like a financial transaction
Loading
Raw
12-Chargeback-Lifecycle.md

The dispute process when a cardholder challenges a transaction. The issuer reverses the transaction through the card network, the acquirer and merchant can respond with evidence, and the case may escalate to arbitration.

  • What: Cardholder dispute process where a transaction is pushed back to the merchant.
  • When: Days to months after the original transaction.
  • Who: Cardholder → Issuer → Network → Acquirer → Merchant.
  • Signals: Scheme chargeback messages, reason codes, representment documents, possible pre-arbitration or arbitration.
sequenceDiagram
    autonumber
    participant Cardholder
    participant Issuer
    participant Network
    participant Acquirer
    participant Merchant

    Cardholder->>Issuer: Dispute transaction
    Issuer->>Network: Raise chargeback
    Network->>Acquirer: Forward chargeback
    Acquirer->>Merchant: Request evidence
    alt Merchant sends documents
        Merchant->>Acquirer: Provide evidence
        Acquirer->>Network: Submit representment
        Network->>Issuer: Forward representment
        Issuer->>Issuer: Decide to accept or continue dispute
    else Merchant no response
        Acquirer-->>Issuer: Accept chargeback
        Issuer-->>Cardholder: Credit account
    end
Loading
Raw
13-Exception-&-Dispute-Handling.md

Beyond chargebacks, there are also:

  • What: Broader dispute processes including retrieval requests, pre-arbitration, and arbitration.
  • When: After a chargeback if not resolved, may take weeks or months.
  • Who: Issuer ↔ Network ↔ Acquirer ↔ Merchant.
  • Signals: Retrieval requests, pre-arbitration filings, arbitration rulings, scheme fee assessments.
- Retrieval Request → issuer asks acquirer for a copy of sales receipt.
- Pre-Arbitration / Arbitration → higher-level scheme processes when issuer and acquirer cannot agree.

sequenceDiagram
    autonumber
    participant Cardholder
    participant Issuer
    participant Network
    participant Acquirer
    participant Merchant

    Cardholder->>Issuer: Request copy of transaction or raise issue
    Issuer->>Network: Send retrieval request
    Network->>Acquirer: Forward request
    Acquirer->>Merchant: Ask for sales slip or receipt
    Merchant->>Acquirer: Provide evidence
    Acquirer->>Network: Forward evidence
    Network->>Issuer: Relay evidence
    Issuer->>Cardholder: Share copy or explanation
    alt Cardholder still disputes
        Issuer->>Network: Raise chargeback or pre arbitration
        Network->>Acquirer: Forward dispute
        Acquirer->>Merchant: Request response
        Note over Issuer,Acquirer: May escalate to arbitration with scheme
    end
Loading
Raw
14-References.md

Card Payments Basics — References & Fact Validation (by section)

Last reviewed: 2025-09-10 (Asia/Singapore)

This file maps each of the 13 sections in the gist to authoritative references that validate the main facts (flows, roles, message types, and terminology).

01) Authorization

02) Clearing

03) Settlement

04) Network & Fee Settlement (Interchange, MDR, Scheme fees)

05) Reconciliation

06) POS Merchant Authorization (card‑present)

07) E‑commerce with 3‑D Secure (EMV 3DS)

08) ATM Cash Withdrawal (On‑Us vs Off‑Us)

09) Pre‑Authorization & Completion

10) Reversal

11) Refund

12) Chargebacks Lifecycle

13) Exception & Dispute Handling (retrieval, pre‑arb, arbitration)

Notes & Nuances

  • MTIs vary slightly by network/processor. The listed MTIs (0100/0110 auth, 0200/0210 financial/completion, 0420/0430 reversal) are industry‑standard patterns (see ISO 8583 and processor guides). Actual field usage is scheme‑specific.
  • Settlement timing (e.g., T+1/T+2) varies by market, product, and acquirer funding practice; treat as indicative.
  • 3DS (EMV 3DS) authentication results (CAVV/ECI) are indeed included in the authorization request; see Visa CAVV guidance and the EMV 3DS white paper.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment