Payments 101 — How Money Actually Moves

The Mental Model

When you tap your card at a store, 12 different systems talk to each other in under 2 seconds. Understanding this flow is what separates a fintech engineer from a generic backend developer.

The Payment Ecosystem — Who Does What

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ Customer │ →  │ Merchant │ →  │ Acquirer │ →  │ Network  │ →  │  Issuer  │
│ (You)    │    │ (Store)  │    │ (Bank)   │    │(Visa/MC) │    │ (Bank)   │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
   Has card      Has terminal     Processes       Routes          Approves/
                                  for merchant    transaction     declines

A Card Payment — Step by Step

In one picture — the request races up the chain to the issuer and the approval races back down:

sequenceDiagram
    participant C as Cardholder
    participant M as "Merchant POS"
    participant A as "Acquirer bank"
    participant N as "Card network"
    participant I as "Issuer bank"
    C->>M: Tap or insert card
    M->>A: Send transaction
    A->>N: Forward request
    N->>I: Route to issuer
    Note over I: Valid card<br/>Enough balance<br/>Not fraud
    I-->>N: Approve or decline
    N-->>A: Relay result
    A-->>M: Relay result
    M-->>C: Show Approved or Declined

1. Customer taps card on POS terminal
2. Terminal reads card data (EMV chip interaction — APDU commands)
3. Terminal sends transaction to Acquirer
4. Acquirer forwards to Card Network (Visa/MC)
5. Network routes to Issuer (customer's bank)
6. Issuer checks:
   - Is the card valid?
   - Does the customer have enough balance/credit?
   - Does this look fraudulent?
7. Issuer sends approval/decline back through the chain
8. Terminal shows "Approved" or "Declined"

Total time: 1-3 seconds. But the money hasn’t actually moved yet.

Authorization vs Settlement (Critical to Understand)

Authorization (instant): “Yes, this customer has Rs. 500. I’m holding it.”

Settlement (hours/days): “OK, actually move the Rs. 500 from issuer to acquirer to merchant.”

Day 0 (3 PM): Customer buys coffee for Rs. 200
              → Authorization: Rs. 200 held on card
              → Customer sees Rs. 200 "pending" in bank app

Day 0 (11 PM): Batch settlement runs
              → Acquirer sends all day's transactions to network
              → Network sends to issuers
              → Issuers debit actual amounts

Day 1-2:      → Funds arrive in merchant's bank account
              → Customer's "pending" becomes "completed"

Why this matters for engineers: When building payment systems, you handle authorizations (real-time, needs to be fast) separately from settlements (batch, needs to be accurate). These are different systems with different requirements.

UPI — India’s Revolution

UPI (Unified Payments Interface) skips the card network entirely:

Customer's Phone → NPCI (UPI switch) → Customer's Bank
                                      → Merchant's Bank

No card network in the middle — the PSP app talks to NPCI, and NPCI moves money account-to-account:

flowchart LR
    P["Payer app<br/>GPay or PhonePe"] --> N["NPCI<br/>UPI switch"]
    N --> PB["Payer bank<br/>debit"]
    N --> MB["Merchant bank<br/>credit"]
    PB -.-> N
    MB -.-> N
    N -.-> P

• Real-time settlement (unlike cards which take days)
• No intermediary fees (or very low)
• Account-to-account (no card involved)

Key UPI concepts:

• VPA (Virtual Payment Address): darshan@upi
• PSP (Payment Service Provider): The app — Google Pay, PhonePe, Paytm
• NPCI: The central switch that routes UPI transactions

Money Rules Every Fintech Engineer Must Know

1. Never Use Float/Double for Money

// THIS IS A BUG
double price = 0.1 + 0.2;
System.out.println(price); // 0.30000000000000004

// THIS IS CORRECT
BigDecimal price = new BigDecimal("0.1").add(new BigDecimal("0.2"));
System.out.println(price); // 0.3

Why: IEEE 754 floating point cannot represent 0.1 exactly. In a financial system processing millions of transactions, these tiny errors accumulate into real money.

2. Store Amounts in Smallest Unit

// Store Rs. 150.50 as 15050 (paise)
// Store $10.99 as 1099 (cents)
// No decimal arithmetic needed. Integer math is exact.
long amountInPaise = 15050;

3. Idempotency — The #1 Rule

If a payment request is sent twice (network timeout, retry), it should only be processed ONCE.

// Every payment request has a unique idempotency key
POST /payments
{
    "idempotency_key": "pay_abc123_1234567890",
    "amount": 15050,
    "currency": "INR"
}

// Server logic:
// 1. Check if this idempotency_key was already processed
// 2. If yes → return the previous result (don't process again)
// 3. If no → process and store the key with the result

4. Double-Entry Bookkeeping

Every financial transaction has TWO entries — a debit and a credit. They must always balance.

Customer buys coffee for Rs. 200:
  DEBIT:  Customer account  -200
  CREDIT: Merchant account  +200
  NET: 0 (always zero)

If your ledger doesn’t net to zero, something is wrong.

Interview Questions You’ll Get

1. “What happens when you tap your card at a POS terminal?”
2. “What’s the difference between authorization and settlement?”
3. “Why can’t you use float for money in Java?”
4. “What is idempotency and why does it matter in payments?”
5. “How does UPI work differently from card payments?”

You should be able to answer all five after reading this page.

Module done? Add it to today’s tracker