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. Dual-Layer Chip Cryptography: The terminal powers the tiny silicon microchip on your card. First, the terminal locally verifies the card's authenticity using asymmetric public-key cryptography (Offline Data Authentication, such as DDA or CDA). Second, the chip computes a single-use symmetric Message Authentication Code (ARQC via 3DES or AES) mathematically bound to the transaction amount, the terminal's random challenge, your card's secret issuer-shared key, and a monotonic transaction 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) recomputes and verifies the chip's symmetric ARQC cryptogram, 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 and an ARPC response cryptogram. 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: Public-Key Offline Authentication vs. Symmetric Cryptograms (ARQC)

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 both asymmetric public-key signatures (RSA or Elliptic Curve Cryptography, used during Offline Data Authentication—DDA or CDA—so the merchant terminal can locally verify a certificate chain signed by the Card Scheme Root CA and Issuer CA proving the chip is not a counterfeit clone; see How Public-Key Cryptography Works) and symmetric block ciphers (3DES or AES-128, used to generate online transaction cryptograms).
• 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
       │         │                     │
       │         ▼ Symmetric MAC       │
       │   Authorization Request       │
       │   Cryptogram (ARQC)           │
       └───────────────────────────────┘
                       │
                       │ Returns: ARQC (e.g., 0xA9 0xF4 0x12 0x8C 0x3B 0x71 0xE0 0x19)
                       ▼
                [ POS Terminal ]

The Three Inputs to a Credit Card Cryptogram

While Offline Data Authentication (DDA/CDA) uses asymmetric public-key signatures so the terminal can verify the card locally, online authorization to the issuing bank uses a faster, ultra-compact symmetric Message Authentication Code (MAC) (EMVCo Book 2). Every time you insert or tap your card, the chip derives a single-use session key and executes a 3DES or AES CBC-MAC algorithm to generate an 8-byte Authorization Request Cryptogram (ARQC). It binds together three critical inputs:

1. A Unique Symmetric Session Key (K_AC): Derived inside the chip from a secret card master key (MK_AC) installed at personalization and shared only between that individual chip and the issuing bank's Hardware Security Module (HSM). The merchant terminal does not possess this key and cannot verify the ARQC itself.
2. The Application Transaction Counter (ATC): A 16-bit 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, terminal country code, date, card verification results, and a cryptographically random 32-bit challenge generated by the merchant terminal (the Unpredictable Number, Tag 9F37).

The Four EMV Cryptogram Types (ARQC, TC, AAC, and ARPC)

Depending on risk rules programmed into the chip and terminal, an EMV transaction produces specific cryptogram types:

• ARQC (Authorization Request Cryptogram): Generated when the chip requires real-time online approval from the issuing bank. Virtually 100% of modern credit card transactions in India and the US emit an ARQC.
• TC (Transaction Certificate): Generated when both the chip and terminal agree to approve a low-value transaction offline (such as a subway turnstile or an in-flight purchase), serving as mathematical proof during later clearing.
• AAC (Application Authentication Cryptogram): Generated when the chip itself declines a transaction offline (for example, if offline velocity limits or PIN retry counters are exceeded).
• ARPC (Authorization Response Cryptogram): Returned by the issuing bank's Hardware Security Module (HSM) over the network back to the chip, proving that the online approval came from the genuine issuer and was not spoofed on the merchant's local wire.

Because the chip's internal counter (ATC) and the terminal's Unpredictable Number (UN) change on 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 (IMK_AC) for that card's portfolio and derives the card's unique master key (MK_AC) from the PAN and PAN sequence number.
2. Regenerates the single-use session key K_AC using the transaction's ATC.
3. Computes the symmetric MAC over the transaction fields, ATC, and terminal UN.
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)? For card-not-present online transactions, the issuer also enforces 3-D Secure challenge verification (detailed in How OTP and Two-Factor Authentication Work).

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 symmetric response MAC generated by the bank's HSM using K_AC to prove to your card chip that the approval 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 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 consumer credit card transaction, they do not receive ₹1,000. In a typical standard consumer credit card transaction (an illustrative benchmark of 2.0% MDR, though actual rates vary from 0.3% capped debit/regulatory categories to 1.5%–3.5% for premium rewards, corporate, or cross-border cards), the merchant receives 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 EMV Payment Tokenization Standards

In recent years, physical cards are increasingly replaced by smartphone taps (Apple Pay, Google Wallet, Samsung Pay) and RBI-mandated Card-on-File (CoFT) e-commerce tokens.

When you tap your smartphone at a store or pay with a saved card online, the merchant never receives your actual 16-digit card number.

The EMVCo Payment Tokenization Architecture

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 Payment Token or DPAN. This token is cryptographically locked into the phone's dedicated hardware Secure Element (SE) or Host Card Emulation (HCE) enclave.
2. Domain Restriction & Token Cryptograms (TAVV): Every token is mathematically bound to a specific channel—either a single physical smartphone or a single online merchant (under RBI's Card-on-File Tokenization mandate). Every checkout requires a fresh Token Authentication Verification Value (TAVV) cryptogram. 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 Consumer Device CVM (CDCVM): Before the Secure Element will compute the transaction cryptogram, you must authenticate using Face ID, Touch ID, or your phone's biometric fingerprint reader—replacing static PIN pads with hardware-backed local authentication.

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 symmetric and public-key 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 Banks.