Design a Credit Card Processing System — System Design Interview Practice

Interview prompt

Design a secure credit-card payment platform that tokenizes card data, authorizes and captures transactions, detects fraud, handles retries, and reconciles with issuers and merchants.

• Keep PAN data inside a tokenization boundary and model authorization, capture, void, refund, dispute, and settlement as a state machine.
• Use idempotency keys, issuer timeouts, an outbox, and reconciliation so retries cannot double-charge or lose a response.
• Run risk checks within a bounded decision budget while sending richer fraud features and review work asynchronously.
• Explain PCI scope, key management, ledger correctness, webhooks, partial failure, chargebacks, and audit evidence.

Requirements and scale assumptions

• Tokenize payment methods, authorize purchases, capture or void funds, issue refunds, and expose transaction status.
• Apply fraud and velocity controls, notify merchants, process issuer webhooks, and reconcile processor settlement files.
• Support idempotent retries, merchant permissions, audit trails, disputes, key rotation, and limited data retention.
• Target p95 payment response below 2 seconds while preserving a durable state transition for every attempt.
• Handle millions of transactions per day with merchant and account partitioning and issuer-specific rate limits.
• Never double-capture or lose a settlement; use conditional transitions, idempotency, and daily reconciliation.
• Return an explicit pending state when an issuer times out instead of guessing success or failure.
• Process 10 million payment attempts per day across 100,000 merchants and multiple processors.
• Partition by merchant and transaction ID; isolate high-volume merchants and processor outage queues.
• Retain tokenized transaction state, signed processor messages, ledger entries, and reconciliation evidence under policy.

• Peak scale: Handle millions of transactions per day — Capacity assumption that drives partitioning and backpressure.
• Latency target: ACID guarantees for transactions — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The source of truth is Process credit card transactions; Tokenization for card security.
• Async boundary: At-least-once workers — Keep Tokenization for PCI compliance, Machine learning for fraud detection, State machine for transaction lifecycle off the synchronous path.

Key entities

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

  Versioned state machine for an authorized credit card processing system money movement.

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

  Append-only double-entry record for the financial effect of credit card processing system.

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

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

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

  Reconciled credit card processing system settlement and discrepancy state.

Data flow

1. 1. Create an idempotent financial intentThe credit card processing 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 credit card processing 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 credit card processing system reconciliation resolves them.
4. 4. Publish status asynchronouslyAn outbox emits committed credit card processing 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 credit card processing 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 credit card processing 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 credit card processing 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.