Practice: Design Payment Processing System
End-to-end payment processing: authorization, capture, settlement, refunds/chargebacks, with multi-provider failover, strong consistency for balances, and full audit trail.
Build this system yourself on the canvas below. Add components, connect them, and run traffic simulations to see where your design holds up and where it breaks.
Functional requirements
- Authorize, capture, void, refund, and settle payments.
- Idempotent APIs for all payment mutations with client-provided keys.
- Multi-provider gateway with failover and per-provider routing.
- Risk checks before authorization; velocity and device rules.
- 3DS/SCA flows with challenge and fallback handling.
- Provider webhooks ingestion with verification and retries.
- Immutable double-entry ledger for balances and audit.
- Reconciliation jobs against provider statements; chargeback handling.
Non-functional requirements
- Availability: 99.95%+; no single-AZ failure should halt charges.
- Performance: checkout auth p95 < 300 ms; capture enqueue < 50 ms; webhook ack < 200 ms.
- Consistency: strong for ledger and idempotency; eventual for analytics.
- Security: PCI isolation for payment service; tokens in KMS; HMAC-verified webhooks.
- Durability: immutable audit logs and ledger with backups and point-in-time recovery.
- Resilience: timeouts, circuit breakers, retries/backoff, DLQs; provider failover.
- Observability: metrics/logs/traces for auth success, latency, retries, DLQ depth, and ledger drift.
- Compliance: audit trails for every state transition with user/actor attribution.
