Digital Payment System — System Design Interview Practice

Interview prompt

Design a secure payment platform for authorization, capture, refunds, payouts, and disputes across cards, bank rails, and wallets, with an auditable ledger and exactly-once financial effects.

• Define payment intents, authorization/capture/refund state machines, double-entry ledger entries, idempotency keys, and provider reconciliation.
• Keep card data out of the core where possible, enforce tokenization and least privilege, and handle asynchronous webhooks and unknown outcomes.
• Separate user-facing payment orchestration from immutable ledger, risk checks, settlement, payouts, disputes, and reporting projections.
• Explain retries, timeouts, fraud/3DS, provider failover, audit retention, privacy, observability, and safe pending status.

Requirements and scale assumptions

• Create payment intents, authorize and capture funds, handle partial/full refunds, tokenize methods, and emit merchant/customer receipts.
• Support bank transfers, wallets, payouts, disputes, 3DS/risk decisions, webhook ingestion, and reconciliation reports.
• Guarantee idempotent financial effects, immutable audit history, ledger balancing, provider timeout recovery, and controlled data deletion.
• Return an accepted/pending/failed payment decision with p95 under 2 seconds while never duplicating a ledger effect.
• Scale to 10M transactions per day and provider webhook bursts without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 10M transactions/day, 100k webhook events/minute, multi-currency ledger
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 10M transactions/day; 100k webhooks/min — Capacity assumption that drives partitioning and backpressure.
• Latency target: decision p95 < 2s; ledger balanced — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The immutable double-entry ledger and provider reconciliation records are authoritative; status views are derived.
• Async boundary: At-least-once workers — Keep Database transactions and consistency, Encryption for sensitive data, Event sourcing for audit trails off the synchronous path.

Key entities

• PaymentIntentintentId, merchantId, amount, currency, status, version, idempotencyKey

  Versioned state machine for an authorized digital payment system money movement.

• LedgerEntryentryId, intentId, accountId, direction, amount, currency, createdAt

  Append-only double-entry record for the financial effect of digital payment system.

• ProviderAttemptattemptId, intentId, provider, requestHash, status, providerRef

  Retry-safe external attempt with an unknown-outcome reconciliation path.

• SettlementRecordsettlementId, intentId, batchId, gross, fees, status

  Reconciled digital payment system settlement and discrepancy state.

Data flow

1. 1. Create an idempotent financial intentThe digital payment system gateway authenticates the merchant, validates amount and currency, tokenizes the instrument reference, and records the idempotency key.
2. 2. Authorize and capture safelyThe orchestrator advances the digital payment system state machine with conditional writes and creates exactly one ledger effect for each business transition.
3. 3. Resolve external outcomesProvider responses and webhooks are stored as immutable attempts; timeouts remain unknown until digital payment system reconciliation resolves them.
4. 4. Publish status asynchronouslyAn outbox emits committed digital payment system events for merchant status, risk, notifications, and settlement without blocking the financial commit.
5. 5. Reconcile and repairSettlement jobs compare provider reports, ledger entries, and internal intents; discrepancies become auditable repair tasks rather than silent edits.

Deep dives and trade-offs

• Exactly-once financial effectsUse the idempotency key at the API, orchestrator, provider-attempt, and ledger boundaries. Make capture, refund, reversal, and cancellation transitions conditional on the current intent version. Treat provider timeouts as unknown and resolve them through status lookup or signed webhook reconciliation.
• Ledger and reconciliation correctnessKeep digital payment system ledger entries append-only and derive balances or views from them. Reconcile gross amount, fees, currency, provider reference, and settlement batch with tolerances that are explicit. Never repair by deleting history; append a compensating entry and preserve the operator reason.
• Risk, privacy, and availabilityKeep digital payment system instrument data tokenized and minimize PCI or sensitive-data scope. Apply risk decisions before irreversible effects and make provider failover policy explicit. Expose pending and unknown states instead of retrying blindly or showing a false success.
• Single provider versus multi-provider routingStart with one provider behind an adapter and add routing only when availability, geography, or cost justifies it. Failing over an unknown digital payment system outcome can double-charge unless reconciliation proves the first attempt’s result.
• Synchronous confirmation versus asynchronous completionReturn a durable pending state quickly and complete provider, webhook, and settlement work asynchronously. Holding an HTTP request open across provider and risk systems creates ambiguous retries and poor tail latency.
• Ledger-first versus provider-first stateMake the internal intent and ledger the source of truth for recorded effects while treating provider state as an external fact to reconcile. Letting a provider response directly mutate balances bypasses audit and correction controls.