Core Payments Fundamentals
The primitives every Payments PM should be able to whiteboard cold — issuer/acquirer/network/processor, auth vs settle, decline codes, 3DS, chargebacks, and why none of this is in your direct control.
The four-party model
For card payments — still the dominant fiat rail in most markets — the four-party model is the floor.
| Party | Role | Example |
|---|---|---|
| Cardholder | The consumer who initiates the payment | Your the company customer in São Paulo |
| Issuer | The bank that issued the card. Decides whether to approve. | Itaú, Bradesco, HDFC, Lloyds |
| Acquirer | The bank that takes the merchant's side. Sends the request to the network. | Adyen, Worldpay, Stone, Cielo |
| Network / scheme | The rails between issuer and acquirer. | Visa, Mastercard, Amex, Elo, RuPay, Mada |
A processor (also called a PSP — payment service provider) is the technology layer in front of the acquirer. Sometimes the same company is both (Stripe, Adyen). The gateway is the API surface; functionally often synonymous with processor.
"Cardholder taps. PSP forwards to acquirer. Acquirer routes through network. Network reaches issuer. Issuer approves or declines. The same chain runs in reverse on settlement and on chargeback."
Authorization vs settlement — different events, different rails, different failure modes
Most PMs new to payments collapse these into "the payment." They are separate, and the distinction is in 80% of payments interview questions.
| Authorization | Settlement | |
|---|---|---|
| When | At checkout / deposit time | Later — same day to T+2 typically |
| What it does | Reserves funds; issuer says yes/no | Actually moves funds, issuer → acquirer → merchant |
| Reversible? | Yes — auth can be voided | Harder — needs refund, not void |
| What you measure | Authorization rate (AAR) | Settlement success, settlement speed |
| Where it fails | Soft decline, hard decline, network timeout | Acquirer batch fail, FX issue, partner reconciliation gap |
Real-time rails like UPI and PIX collapse the timeline — auth and settlement happen in seconds — but the two events still exist conceptually. Even on PIX you can have a successful auth-equivalent (PIX message accepted) and a later reconciliation failure.
Anatomy of a card payment — what's in the message
Any Payments PM should know the field-level vocabulary. You won't write ISO 8583 messages, but interviewers will use these terms.
| Term | What it is |
|---|---|
| PAN | Primary Account Number — the full card number |
| BIN | Bank Identification Number — first 6-8 digits of PAN, identifies the issuer |
| MCC | Merchant Category Code — 4-digit code identifying merchant type (6051 = quasi-cash / crypto) |
| AVS | Address Verification Service — issuer checks billing address vs. submitted |
| CVV / CVC | Card Verification Value — the 3-4 digit code |
| Network token | A scheme-issued token replacing the PAN, lifecycle-managed by Visa/MC |
| 3DS / 3DS2 | 3-D Secure — issuer-side strong customer authentication step (OTP, biometric) |
| SCA | Strong Customer Authentication — PSD2 requirement in EU; 3DS2 is how you satisfy it |
MCC 6051 is worth memorizing. It's the "quasi-cash" code many crypto purchases run under, and many issuers selectively block or step-up authenticate it. Half of crypto auth-rate work is about how your purchases get coded.
Decline codes & retry strategy
Not every decline is equal. Knowing the family matters because retry policy depends on the decline reason.
| Family | Examples | Retry behavior |
|---|---|---|
| Hard decline | Stolen card, lost, account closed, fraud-confirmed | Never retry. Scheme rules prohibit. |
| Soft decline | Insufficient funds, do-not-honor, generic decline | Retry with backoff; consider rail switch |
| Issuer-side step-up | Authentication required (3DS) | Don't retry — escalate to 3DS challenge |
| Network / system | Timeout, response code 91, unable to route | Retry quickly; prefer same rail |
| Velocity / risk | Issuer suspects velocity attack | Wait, retry later, or switch BIN/rail |
Smart retry is one of the most measurable AAR levers. A naïve retry-everything policy tanks AAR because schemes count repeat-on-hard-decline against you. See 06.
3DS2 and SCA — the step-up tax
3DS (3-D Secure) is the protocol that lets the issuer step the customer up for authentication mid-payment. 3DS2 (the current version) is smarter than 3DS1: it does risk-based authentication, often frictionless (no challenge to the user) when the issuer is confident.
Why a PM cares:
- Liability shift. If 3DS succeeds and the txn is later disputed as fraud, liability moves from merchant to issuer.
- Friction cost. Every challenge step-up adds dropout. PIN-OTP UX on a slow Indian network costs you points of conversion.
- SCA mandate. In EU, PSD2 requires SCA for most txns; 3DS2 is the implementation. In emerging markets, 3DS requirement varies by scheme and country.
- Exemptions. Low-value, recurring, trusted-beneficiary, and TRA (transaction risk analysis) exemptions exist. Knowing how to claim them is a real lever.
Chargebacks & the dispute lifecycle
A chargeback is when the cardholder disputes a transaction with their issuer. The funds reverse out of the merchant. The lifecycle:
- Retrieval request — issuer asks merchant for evidence (sometimes skipped).
- Chargeback filed — funds pulled; merchant has a window to respond.
- Representment — merchant submits evidence to defend.
- Pre-arbitration / arbitration — if issuer disputes the representment.
- Final ruling — scheme decides.
Scheme thresholds matter: Visa's VDMP (Visa Dispute Monitoring Program) flags merchants above ~0.9% dispute rate. Above scheme thresholds you face fines, then de-platforming. For crypto, dispute rates historically run hot — managing them is core PM work.
Bank-rail primitives (the non-card world)
Card is one rail. Bank rails — wires, ACH, faster-payments — are the other floor. Quick reference:
| Rail | Geography | Speed | Reversibility |
|---|---|---|---|
| SWIFT wire | Global | Hours-days | Limited; manual |
| ACH | US | Same-day to 2 days | R-codes; ~60 days |
| SEPA Credit Transfer | EU/EEA | 1 business day | Recall available |
| SEPA Instant (SCT Inst) | EU/EEA | ~10 seconds | Very limited |
| FPS (Faster Payments) | UK | ~Seconds | Very limited |
| UPI | India | ~Seconds | Dispute via NPCI |
| PIX | Brazil | ~Seconds | MED return window |
| FedNow / RTP | US | ~Seconds | Very limited |
The unifying pattern: real-time / instant rails are fast and irreversible. That irreversibility is a fraud and recovery problem for you. See 08-error-handling.
Why payments PM is uniquely vendor-dependent
Almost every modern PM job has dependencies. Payments has capabilities-as-a-vendor in a way few others do.
- You don't own the rails. Visa, NPCI, BACEN do. You consume them through licensed acquirers.
- You don't own the auth decision. The issuer does.
- You don't own your uptime. Your PSP, your acquirer, your bank partner all stand in front of you.
- You don't fully own your cost. Interchange and scheme fees move by category and region; FX spreads move by counter-party.
- You don't fully own your roadmap. If your PSP doesn't ship a feature, you can't ship it either, unless you change PSPs.
The senior posture: treat vendor management as primary PM craft, not as side admin. Most of your leverage is in partner selection, partner SLAs, and partner cadence. See 05-deep-dive-secondary.
A single-page mental model
If you can answer these five questions cold, you have the floor:
- What's the difference between auth and settle, and where can each fail?
- What does a BIN tell you, and how would you use it in product?
- Why is retry-on-hard-decline forbidden, and what's the alternative?
- What's the liability shift in 3DS, and when wouldn't you want it?
- Why is instant-rail fraud different from card fraud?
If any of these are fuzzy, return here before the loop.