Stripe Payment Processing Architecture

Every mutating Stripe API request includes an idempotency key — a client-generated UUID. The server stores the key and its associated response in a durable idempotency store. If the same key is sent again (due to network retry, client timeout, or duplicate webhook), the server returns the stored response without re-executing the operation. This is critical for payments: if a charge request times out and the client retries, the card is charged exactly once. The idempotency store uses a compound key of (API key + idempotency key) and entries expire after 24 hours.

Stripe records every payment state transition as an immutable event in an append-only log: payment_created → payment_authorized → payment_captured → payment_settled. The current state of any payment is derived by replaying its event history. This provides a complete, tamper-proof audit trail required by financial regulators (PCI DSS, SOX). Event sourcing also enables temporal queries ('what was the state of this payment at 3:47 PM?') and makes debugging production issues straightforward — you can replay the exact sequence of events that led to any state.

Stripe's ledger uses double-entry bookkeeping: every financial transaction creates two entries — a debit and a credit — that must sum to zero. When a customer pays $100, the ledger debits the customer's payment account and credits the merchant's pending balance. When settlement occurs, the pending balance is debited and the merchant's bank account is credited. This centuries-old accounting principle ensures that money never appears or disappears — the total across all accounts always balances. Any imbalance triggers an immediate alert and investigation.

A payment flow involves multiple external systems: fraud check → card network authorization → capture → settlement → merchant payout. Traditional distributed transactions (2PC) are impractical across third-party systems. Instead, Stripe uses the saga pattern: each step is an independent transaction with a compensating action. If authorization succeeds but capture fails, the system automatically executes a void (the compensating transaction). A saga orchestrator tracks the current step and ensures either all steps complete or all completed steps are compensated. Each step is idempotent, making retries safe.

Stripe Radar evaluates every transaction with an ML model that scores fraud probability in under 100ms — it must not add perceptible latency to checkout. The model uses hundreds of signals: card fingerprint, IP geolocation, device attributes, transaction velocity, behavioral biometrics, and merchant risk profile. Features are served from a low-latency feature store. The model is trained on billions of historical transactions across Stripe's entire network — a merchant-level system wouldn't have enough data. High-risk transactions are blocked or stepped up to 3D Secure authentication automatically.