System Design: Payment Gateway — Authorization, Settlement, Idempotency, and Fraud Prevention

Requirements

A payment gateway processes card transactions between merchants and issuing banks. Core flow: customer enters card details → merchant sends authorization request → gateway routes to card network (Visa/Mastercard) → issuing bank approves/declines → response returned in < 2 seconds. Additional responsibilities: settlement (actual money movement), refunds, idempotency (no double charges), fraud detection, and PCI-DSS compliance. Scale: Stripe processes hundreds of billions of dollars annually. PayPal handles ~40 million transactions per day. Visa's network peaks at 65,000 transactions per second globally. This is one of the most detail-rich system design questions — correctness and reliability matter more than raw scale.

Authorization Flow

Step-by-step authorization: (1) Customer submits payment on merchant checkout. JavaScript SDK tokenizes the card (card number → token) client-side — raw card data never reaches the merchant’s server. (2) Merchant server sends authorization request to the gateway API: {token, amount, currency, merchant_id, idempotency_key}. (3) Gateway decrypts the token, retrieves card data from its secure vault (PCI-DSS zone). (4) Gateway enriches the request with fraud signals (device fingerprint, IP geolocation, velocity checks). Fraud score computed by ML model in < 50ms. (5) Gateway constructs an ISO 8583 message and routes to the appropriate card network (Visa/Mastercard/Amex) via a dedicated leased line or Mastercard/Visa APIs. (6) Card network routes to the issuing bank. Bank checks: card validity, available credit, fraud rules. Approves or declines. Response back to gateway in < 1.5 seconds end-to-end. (7) Gateway records the authorization (auth_code, approved amount, expiry) and returns to merchant. Merchant fulfills the order. The authorization hold reserves funds but does not move money yet.

Idempotency and Double-Charge Prevention

The most critical reliability requirement: a payment must be processed exactly once even under retries, network failures, and timeouts. Idempotency keys: every payment request includes a client-generated idempotency_key (UUID). The gateway stores a mapping: idempotency_key → {result, created_at} in a distributed store (Redis or database). On each request: check if the key exists. If yes: return the stored result immediately without reprocessing. If no: process and store the result. TTL: idempotency keys expire after 24 hours (Stripe’s default). Database-level protection: unique constraint on (merchant_id, idempotency_key). If two concurrent requests race: the second gets a unique constraint violation and returns the stored result. Idempotency at every layer: the gateway must also be idempotent with the card network. Network timeouts require retrying with the same transaction ID to avoid double charges. The card network uses the transaction ID for deduplication.

Settlement and Reconciliation

Authorization ≠ settlement. Authorization holds funds; settlement moves money. Settlement timing: T+1 or T+2 (1-2 business days after transaction). Batch settlement: the gateway sends a batch of authorized transactions to the card network at end of day. The card network debits the issuing bank and credits the acquiring bank. Acquiring bank credits the merchant’s account (minus interchange fees). Reconciliation: every transaction has a corresponding settlement record. Daily reconciliation job: match authorization records against settlement records. Mismatches: uncaptured authorizations (not settled), settled without authorization (fraud), amount mismatches. Reconciliation runs nightly; alerts fire on discrepancies. Refunds: the gateway credits the customer’s account by reversing a previous settlement. Partial refunds are supported (refund_amount ≤ original_amount). Chargebacks: customer disputes a charge with their bank. Bank reverses the payment. Gateway notifies the merchant who can provide evidence to contest. Chargeback rate > 1%: Visa/Mastercard may terminate merchant account.

Fraud Detection Architecture

Fraud detection runs synchronously in the authorization path (< 50ms budget). Feature signals: transaction amount vs. merchant category typical amount, velocity (how many transactions on this card in the last hour/day), device fingerprint (new device for this cardholder?), IP geolocation (IP country ≠ billing address country?), time of day, merchant risk category (travel = high risk, grocery = low risk). ML model: gradient boosted trees (XGBoost/LightGBM) trained on historical fraud labels. Inference in < 20ms at the gateway. Score thresholds: score 0.7: decline. Rules engine alongside ML: hard rules for known fraud patterns (velocity > 5 transactions in 1 min: block). Rules are faster to update than retraining a model. Feedback loop: chargebacks and fraud reports are labeled and fed back into model retraining (weekly batch job). Feature store: precomputed features (rolling counts, averages) are stored in Redis with TTL matching the window (1-hour window: 1-hour TTL).

Interview Tips

Idempotency is the most important reliability property — explain it in depth with the idempotency key pattern.
Distinguish authorization (hold) from capture (settlement) — many candidates conflate them.
Fraud detection must be synchronous and fast (< 50ms) — an async approach would allow fraud to complete before detection.
PCI-DSS compliance shapes the architecture: card data only in the vault, tokenization on the client, no raw PANs in logs.

{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”What is the difference between payment authorization and settlement?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Authorization reserves funds on the customer's card without moving money — the bank confirms the card is valid and funds are available, placing a hold. Settlement (capture) is the actual transfer of money from the issuing bank to the merchant's acquiring bank, typically processed in a nightly batch (T+1 or T+2). A merchant can authorize and capture simultaneously (for immediate purchases) or separately (authorize now, capture when the item ships).”}},{“@type”:”Question”,”name”:”How do idempotency keys prevent double charges in a payment gateway?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Every payment request includes a client-generated UUID as an idempotency key. The gateway stores a mapping of idempotency_key → result. On each request, it first checks this store. If the key exists, it returns the stored result without reprocessing. If the key is new, it processes the payment and stores the result. A unique database constraint on (merchant_id, idempotency_key) handles concurrent duplicate requests at the database level.”}},{“@type”:”Question”,”name”:”Why must card data be tokenized on the client side?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”PCI-DSS compliance requires that raw card numbers (PANs) never touch systems outside the PCI-DSS scope. Client-side tokenization (via a JavaScript SDK) converts the card number to a token before the form is submitted. The merchant's server receives only the token — never the raw card number — which dramatically reduces the merchant's PCI compliance burden and attack surface.”}},{“@type”:”Question”,”name”:”How does fraud detection run synchronously in under 50ms?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Pre-computed features (rolling counts, velocity checks) are stored in Redis with appropriate TTLs, so feature extraction is a fast Redis read rather than a slow database aggregation. The ML model (gradient boosted trees) is loaded into memory and runs inference in under 20ms. Hard rules (velocity blocks, known bad IPs) are checked first and can short-circuit the ML call entirely. Total budget: feature retrieval ~5ms + ML inference ~20ms + overhead = well under 50ms.”}},{“@type”:”Question”,”name”:”What is a chargeback and how does it affect merchants?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”A chargeback occurs when a customer disputes a charge directly with their card-issuing bank. The bank reverses the payment, debiting the merchant's account. Merchants can contest chargebacks by providing evidence (shipping confirmation, signed receipts). Merchants with chargeback rates above 1% risk fines from Visa/Mastercard and eventual account termination. High-risk merchants pay higher interchange fees to account for chargeback risk.”}}]}