Design a Payment System

A robust, secure payment system processes financial transactions globally while guaranteeing idempotency and zero data loss.

1. High-Level Design

Payment systems must interface with external, unreliable third-party Payment Service Providers (PSPs) like Stripe, PayPal, or Visa.

Client App ---> API Gateway ---> Payment Service (Pending) ---> PSP Gateway (Stripe)
                                          |
                                    Idempotency Key (Redis)

Components

1. Idempotency Service: Utilizes a Redis cache to store transaction tokens. If a client retries due to network failure, the token prevents double-charging.

2. Payment Service: Orchestrates transaction states (PENDING, SUCCESS, FAILED) and logs audit records to database.

3. PSP Gateway: Interfaces with external financial processors.

4. Reconciliation Service: A background processor comparing internal ledger tables with daily settlement reports from PSPs.

2. Potential Deep Dives

• Idempotency Mechanics:

On page load, the client requests a unique idempotency token. When clicking "Pay", this token is sent in the header. The server attempts to store the token in Redis with a distributed lock. If the token already exists, the server returns the cached response instead of processing the transaction again.

• Dual-Write Mitigation:

Use the transactional outbox pattern. Write both the transaction record and the corresponding event to the database in a single transaction, then emit to Kafka asynchronously.

3. References & Tech Blogs

• Stripe Engineering: How We Build Idempotent API Keys
• Uber Tech Blog: Architecture of Our Global Financial Ledger