How Credit Cards Actually Work

Quick answer

When you tap a plastic credit card against a payment terminal in a store, no money leaves your bank account. In fact, no money moves anywhere in the financial system.

What happens in those two seconds is an intricate cryptographic and telecommunication relay known as the Four-Party Model:

1. Cryptographic Handshake: The terminal powers the tiny silicon microchip on your card, which generates a single-use digital signature (ARQC) mathematically bound to the transaction amount, your card's secret key, and a unique counter.
2. Global Network Relay: The terminal sends an electronic message (ISO 8583) through the merchant's payment processor (Acquirer) to a global card switch (VisaNet, Mastercard Network, or RuPay).
3. Credit Verification: The network routes the packet to your card-issuing bank (Issuer), whose Hardware Security Module (HSM) verifies the chip's signature, checks your available credit line, scores the transaction for fraud, and places a temporary authorization hold on your balance.
4. Approval: The issuing bank returns an approval code. The terminal displays "Approved" and prints a paper receipt.

The actual movement of money between institutions happens 24 to 48 hours later, when the merchant uploads its daily sales batch and the card network executes multilateral net settlement across the banks' central reserve accounts.

---

The simple mental model: The Four-Party Relay

A credit card transaction coordinates four separate commercial entities connected by a central clearing switch:

Notice the role division:

• Cardholder: The consumer holding a line of revolving credit.
• Merchant: The business accepting the card payment.
• Acquirer: The merchant's bank or payment gateway that operates the physical terminal and collects card payments.
• Card Network: The global high-speed telecommunication switch (Visa, Mastercard, RuPay, American Express) that standardizes messages and routes packets between banks.
• Issuer: The financial institution that issued the card, granted the credit limit, and takes the risk of cardholder default.

---

Why magnetic stripes were abandoned: The static data vulnerability

To understand the genius of modern EMV smart cards, you must understand how dangerously simple the original credit card design was.

Until the 2010s, credit cards stored account data on a black magnetic stripe on the back of the plastic card. That stripe contained three tracks of unencrypted text:

%B4111111111111111^DOE/JOHN^25121010000000000000000000000000?

This static text included only the 16-digit Primary Account Number (PAN), the cardholder's name, the expiration date, and a static card verification code.

Because magnetic stripes are functionally identical to vintage cassette tapes, an attacker with a $15 magnetic card reader (a "skimmer") installed over an ATM or petrol pump slot could read the raw tracks in a fraction of a second. The attacker could then write that exact magnetic pattern onto a blank piece of plastic and clone your card indefinitely.

The magnetic stripe had zero dynamic cryptography. It told the terminal who you were, but it had no way of proving that the physical card swiped at the counter was the authentic original.

---

The EMV Microchip: A cryptographic computer on plastic

Modern credit cards replace static magnetic tracks with a full-fledged miniature computer called an EMV chip (named after its creators: Europay, Mastercard, and Visa).

Embedded inside that tiny gold-plated square is:

• An 8-bit or 32-bit microprocessor.
• Dedicated cryptographic hardware acceleration (for 3DES and RSA / AES).
• Secure, tamper-resistant EEPROM memory that destroys its contents if physically peeled or probed with an electron microscope.

                [ POS Terminal ]
                       │
                       │ Sends: Amount (e.g., ₹1,450.00) + Terminal Unpredictable Number (UN)
                       ▼
       ┌───────────────────────────────┐
       │ EMV Silicon Microcontroller   │
       │                               │
       │   Master Key (K_AC)           │ <--- Secure enclave (never exported)
       │         +                     │
       │   Application Transaction     │ <--- Monotonic counter (increments every tap)
       │   Counter (ATC = 142)         │
       │         +                     │
       │   Transaction Data            │ <--- Amount, Currency Code, Terminal UN
       │         │                     │
       │         ▼ Cryptographic Hash  │
       │   Authorization Request       │
       │   Cryptogram (ARQC)           │
       └───────────────────────────────┘
                       │
                       │ Returns: ARQC (e.g., 0xA9 0xF4 0x12 0x8C)
                       ▼
                [ POS Terminal ]

The Three Inputs to the Cryptogram

Every time you insert or tap your card, the chip executes an algorithm to generate an Authorization Request Cryptogram (ARQC). It hashes together three critical inputs:

1. A Unique Session Key ($K_{AC}$): Derived inside the chip from a secret master key installed at the card factory and unique to your piece of plastic. This key never leaves the chip.
2. The Application Transaction Counter (ATC): A hardware counter inside the chip that increments by exactly 1 on every single transaction and can never be rolled backward.
3. Transaction Context: The exact transaction amount, currency code, date, and a cryptographically random number generated by the merchant terminal (the Unpredictable Number).

Because the chip's internal counter increments with every tap, no two cryptograms generated by your card are ever the same.

If an eavesdropper intercepts the electronic signal transmitted between your card and the terminal, that captured data is useless. If they attempt to replay that exact message at another store ten minutes later, the issuing bank's server will inspect its database, notice that counter value 142 has already been spent, and instantly decline the fraudulent transaction.

---

The 2-Second Journey: Inside the ISO 8583 Message

Once the terminal receives the cryptogram from the chip, it packages the payment into a standardized electronic telegram defined by ISO 8583 (the international standard for financial transaction card messaging).

A standard authorization request is known as an ISO 8583 0100 Message:

Message Type Identifier (MTI): 0100 (Authorization Request)
Bitmap: Indicates which data fields are present in the payload
  Field 3:   Processing Code (000000 = Purchase of Goods)
  Field 4:   Amount, Transaction (000000145000 = ₹1,450.00)
  Field 11:  Systems Trace Audit Number (STAN = 849201)
  Field 14:  Expiration Date (2712 = December 2027)
  Field 22:  Point of Service Data Code (051 = EMV Chip Contactless)
  Field 41:  Card Acceptor Terminal Identification (POS918234)
  Field 49:  Currency Code (356 = INR)
  Field 55:  Integrated Circuit Card (ICC) System Data:
               Tag 9F26: ARQC (Cryptogram)
               Tag 9F36: Application Transaction Counter (ATC)
               Tag 9F37: Unpredictable Number (UN)
               Tag 9F02: Amount, Authorized

The Global Routing Switch

The merchant's terminal sends this packet over a secure TLS link to its Acquiring Processor (such as Pine Labs, Razorpay, Worldpay, or Chase).

The Acquirer reads the first six to eight digits of the card number—known as the Bank Identification Number (BIN) or Issuer Identification Number (IIN):

• Cards starting with 4 route to VisaNet.
• Cards starting with 5 route to Mastercard Banknet.
• Cards starting with 60 or 65 in India route to the RuPay Switch (operated by NPCI).
• Cards starting with 34 or 37 route to American Express.

The card network switch operates global high-throughput private optical fiber rings. In less than 150 milliseconds, the switch reads the BIN, identifies that your card was issued by HDFC Bank in Mumbai, and fires the ISO 8583 packet into HDFC Bank's authorization gateway.

The Issuer's Verification

Inside the issuing bank, the incoming packet is handed to a dedicated Hardware Security Module (HSM). The bank's HSM:

1. Loads the master derivation key for that card's portfolio.
2. Regenerates the session key $K_{AC}$.
3. Runs the exact same mathematical hash on the transaction fields.
4. Compares its calculated cryptogram with the ARQC emitted by your card.

If the two cryptograms match, the bank has mathematical proof that:

• The authentic, physical card microchip generated the message.
• The transaction amount was not altered in transit between the store and the bank.

The bank then executes an automated credit check:

• Does the cardholder have sufficient available credit?
• Does the machine-learning fraud model flag any anomalies (such as an in-person swipe in Tokyo thirty minutes after a swipe in Delhi)?

If everything clears, the bank emits an ISO 8583 0110 Authorization Response:

• Action Code: 00 (Approved).
• Authorization Code: AUTH 084912.
• ARPC (Authorization Response Cryptogram): A cryptographic signature generated by the bank's HSM to prove to your card chip that the response genuinely came from your bank, completing mutual authentication.

---

The Dual-Message System: Authorization vs. Clearing vs. Settlement

One of the most confusing aspects of credit card accounting is that a successful transaction does not move any money.

Credit cards use a Dual-Message Architecture:

Day 1 (14:32:01) — Authorization (Message 1)
  Terminal -> Switch -> Issuer -> Terminal (Takes 1.8 seconds)
  Action: Issuer places an Authorization Hold on your credit line.
  Money moved: ₹0.00.

Day 1 (23:30:00) — Batch Capture & Clearing (Message 2)
  Merchant terminal closes daily batch.
  Acquirer sends clearing files (ISO 8583 0200 / IPM files) to Card Network.

Day 2 (10:00:00) — Multilateral Settlement
  Card Network calculates net obligations across all banks.
  Network settles funds via central bank accounts:
    - Issuer transfers ₹1,421.00 to Acquirer.
    - Acquirer credits merchant ₹1,421.00 (₹1,450 minus ₹29 fee).

1. Authorization (Real-Time)

When the terminal prints "Approved", the issuing bank does not deduct funds. It places an Authorization Hold on your available credit limit.

If your credit limit is ₹1,00,000 and you spend ₹1,450 at a restaurant, your available credit drops to ₹98,550 immediately so you cannot overspend. But your current balance remains unchanged, and the merchant has not received a single rupee.

2. Clearing (End-of-Day Batch)

At the end of the business day, the merchant runs a terminal command called Batch Settlement (or "settling the batch").

The terminal packages all the approved transactions collected over the past 24 hours and transmits them as an electronic clearing batch to the Acquirer. The Acquirer forwards these clearing records to the card network (Visa, Mastercard, or RuPay), which validates them against the original authorizations.

3. Settlement (Institutional Netting)

The card network operates a global clearinghouse. It nets out all credits and debits between member banks worldwide.

On Day 2 or Day 3, the card network executes settlement across the banks' accounts. The issuing bank pays the acquiring bank in sovereign central bank reserves (as detailed in How Money Moves Between Indian Banks), and the acquiring bank deposits the proceeds into the merchant's business checking account.

---

The Hidden Economics: Where the 2% Fee Goes

When a merchant accepts a ₹1,000 credit card transaction, they do not receive ₹1,000. They typically receive approximately ₹980.

The ₹20 deduction is called the Merchant Discount Rate (MDR). Where does that money go?

Customer swipes card for ₹1,000.00
Merchant receives: ₹980.00 (MDR = 2.0%)
                               │
               ┌───────────────┼───────────────┐
               ▼                               ▼                               ▼
    Interchange Fee (~1.4%)         Acquirer Markup (~0.45%)        Scheme Fee (~0.15%)
         (₹14.00)                        (₹4.50)                         (₹1.50)
               │                               │                               │
       Goes to Issuer Bank             Goes to Acquirer                Goes to Network
   - Covers credit loss risk        - Terminal hardware / POS      - Maintains global fiber
   - 45-day interest-free loan      - Merchant onboarding          - Real-time routing engines
   - Reward points & cashbacks      - Payment gateway software     - Fraud detection switches

1. Interchange Fee (Largest Share, ~70%): Paid by the merchant's bank to the card-issuing bank. The issuer receives this fee because it takes the primary financial risk: it loaned the consumer the money, pays the merchant even if the customer later defaults, provides a 45-day interest-free grace period, and funds credit card rewards programs and airport lounge access.
2. Acquirer Markup (~22%): Kept by the merchant's payment processor (e.g. Pine Labs, Razorpay, or HDFC Merchant Services) to cover terminal leasing, cellular data connections, software APIs, and customer support.
3. Assessment / Scheme Fee (~8%): Kept by the card network (Visa, Mastercard, or RuPay) for operating the global telecommunications switches, managing brand acceptance, and running real-time fraud monitoring systems.

---

Mobile Wallets and Tokenization: Why Apple Pay and Google Wallet are Even Safer

In recent years, physical cards are increasingly being replaced by smartphone taps (Apple Pay, Google Wallet, Samsung Pay) and tokenized e-commerce checkouts.

When you tap your smartphone at a store, the phone does not transmit your actual 16-digit card number over the air.

The EMV Payment Tokenization Architecture

[ During Wallet Enrollment ]
  Physical Card PAN: 4111 2222 3333 4444
        │
        ▼ Provisioned through Visa / Mastercard Token Service Provider (TSP)
  Device PAN (DPAN): 4892 1049 2819 0192 (Tied exclusively to your iPhone SE)

[ During Store Checkout ]
  Phone taps POS terminal:
    - Transmits DPAN (never your real 16-digit number)
    - Hardware Secure Element computes dynamic cryptogram
        │
        ▼ Reaches Card Network
  Token Service Provider (TSP) Vault:
    - Translates DPAN back to real PAN
    - Validates device cryptogram
        │
        ▼ Forwards real PAN to Issuer Bank for authorization

1. The Device Account Number (DPAN): When you add a card to your phone, the card network's Token Service Provider (TSP) creates a surrogate 16-digit number called a Token or DPAN. This token is cryptographically locked into the phone's dedicated hardware Secure Element (SE).
2. Domain Restriction: The token is mathematically bound to that single physical phone. If a hacker breaches a merchant's database and steals millions of stored token numbers, those tokens are completely useless on any other device or website.
3. Biometric Authorization: Before the Secure Element will compute the transaction cryptogram, you must authenticate using Face ID, Touch ID, or your phone's biometric fingerprint reader—eliminating the risk of stolen card PINs.

---

Why this matters

The credit card network is one of the largest distributed transaction engines ever constructed:

• It connects billions of cards to tens of millions of merchants across over 200 countries.
• It completes asymmetric cryptographic signatures, multi-hop routing, credit verifications, and fraud scoring across continents in under two seconds.
• It enforces strict risk partitioning through the Four-Party Model, ensuring that merchants never have to trust consumers, and consumers never have to expose their bank accounts to merchants.

To understand why card payments occasionally hang, why international transactions are declined by fraud models, and how networks use Stand-In Processing when an issuing bank crashes, explore the companion explainer on Why a Card Payment Sometimes Takes a Few Seconds to Confirm. You can also discover how account-to-account payments bypass these interchange fees entirely in How UPI Works and How Money Moves Between Indian Banks.