Design a Payment System: System Design Interview Walkthrough (2026)

When an interviewer asks you to design a payment system, they are looking for three things: how you gather requirements, how you translate those requirements into a clean set of components, and how you reason about the hard problems that arise at scale. Below is a practical walkthrough you can follow in a real interview.

1. Clarify Requirements Early

Start by asking the candidate (you) to list the functional and non‑functional requirements. This shows you can drive the conversation and avoid building an unnecessary architecture.

Functional

• Process a payment request from a payer to a payee.
• Support multiple payment methods (card, bank transfer, digital wallet).
• Provide idempotent request handling.
• Expose status of a transaction (pending, succeeded, failed, refunded).
• Allow refunds and partial refunds.
• Support recurring payments (subscriptions).

Non‑functional

• Low latency (sub‑second for approval, a few seconds for settlement).
• High availability (99.9%+ uptime).
• Strong consistency for balances and ledger entries.
• Scalability to handle burst traffic (e.g., sales events).
• Security and compliance (PCI‑DSS, GDPR).
• Auditable audit trail.

If the interviewer wants to narrow the scope (e.g., “only one‑time credit‑card payments”), acknowledge the trade‑off and adjust the design accordingly.

2. Identify Core Entities and Data Model

A payment system revolves around a few key domain objects. Use clear names; avoid invented traffic numbers.

The immutable Transaction and LedgerEntry tables give you a reliable audit trail and simplify reconciliation.

3. Sketch a High‑Level Architecture

Use a text diagram to keep the interview focused. You can draw it on a whiteboard or share a simple ASCII sketch.

+----------------+      +----------------+      +-------------------+
|   API Gateway  | ---> | Auth Service   | ---> |   Rate Limiter    |
+----------------+      +----------------+      +-------------------+
        |                        |                     |
        v                        v                     v
+----------------+      +----------------+      +-------------------+
| Payment API   | ---> | Fraud Service  | ---> | Settlement Engine |
+----------------+      +----------------+      +-------------------+
        |                        |                     |
        v                        v                     v
+----------------+      +----------------+      +-------------------+
|  Account Svc  | <--> | Ledger Service | <--> |   Data Stores     |
+----------------+      +----------------+      +-------------------+

Key services

• API Gateway: entry point, TLS termination, routing.
• Auth Service: token validation (OAuth/JWT), permissions.
• Payment API: thin façade exposing CreatePayment, GetStatus, Refund.
• Fraud Service: rule‑based and ML scoring, can reject or flag.
• Settlement Engine: batches settlements to external networks (Visa, ACH).
• Account Service: reads/writes balances, enforces idempotency.
• Ledger Service: writes immutable entries, supports replay for audit.
• Data Stores: relational DB for accounts, NoSQL for high‑throughput logs, message queue for async pipelines.

4. Dive Into the Hard Parts

4.1 Idempotency

Payments must be safe against retries. Use a client‑generated request_id that is stored with the transaction. On a repeat call, look up the existing transaction and return its status.

4.2 Consistency vs. Latency

Balances need strong consistency, but you also want low latency. A common pattern is read‑through cache with a write‑through path:

• Write a transaction → Ledger Service writes to DB and publishes an event.
• Account Service updates the cached balance after the write succeeds.
• If the cache is stale, a fallback to the DB ensures correctness.

4.3 Fraud Detection

Fraud is a soft real‑time problem. You can run a quick rule check synchronously (e.g., velocity limits) and then enqueue the request for deeper ML scoring. If the ML model flags high risk, you can place the transaction in a pending state and trigger manual review.

4.4 Settlement and Reconciliation

External networks settle in batches (e.g., nightly ACH). The Settlement Engine groups successful transactions, generates a file, and tracks settlement status. Reconciliation compares the external report with internal ledger entries, flagging mismatches for investigation.

5. Trade‑offs and Design Choices

Explain why you would start with the simpler option and evolve to the more complex one as traffic grows.

6. Sample API Sketch

// Create a payment request
func CreatePayment(ctx context.Context, req CreatePaymentRequest) (CreatePaymentResponse, error)

type CreatePaymentRequest struct {
    RequestID      string   // client‑generated idempotency key
    PayerAccountID string
    PayeeAccountID string
    Amount         int64    // in smallest currency unit
    Currency       string
    MethodID       string   // tokenized payment method
    Description    string
}

type CreatePaymentResponse struct {
    TransactionID string
    Status        string // pending, succeeded, failed
    CreatedAt     time.Time
}

The response is quick because the transaction is pending until fraud and settlement steps complete.

7. Follow‑up Questions Interviewers May Ask

1. How would you handle partial refunds? – Explain creating a new Refund record linked to the original transaction and adjusting ledger entries accordingly.
2. What if the payment method token expires mid‑flow? – Show a retry path that re‑collects the token from the client before proceeding.
3. How do you ensure PCI‑DSS compliance? – Discuss tokenization, limiting card data to the payment gateway, and encrypting data at rest.
4. How would you scale the fraud service? – Move it to a separate microservice, shard by merchant, and use a message queue for async scoring.
5. What consistency model would you choose for the ledger? – Use append‑only immutable logs with strong consistency for audit, while allowing eventual consistency for read‑through caches.

8. Where Call Assistant Can Help

Practicing your answer aloud with Call Assistant lets you keep the flow natural and ensures you stay on topic when the interview pivots to follow‑up questions. It can also surface relevant resume points (e.g., “built a payment pipeline that reduced settlement latency”) to ground your story.

How to practice this

1. Mock the interview: Record yourself answering the walkthrough, then listen back to spot rambling or missing steps.
2. Sketch the diagram without notes: Recreate the architecture from memory to reinforce the component relationships.
3. Iterate on edge cases: Pick three follow‑up questions and write concise answers, then rehearse them until they feel natural.

---

FAQ

• Q: Do I need to design every microservice in detail? A: No. Focus on the high‑level responsibilities and how they interact. Dive deeper only for the parts the interviewer probes.

• Q: How much emphasis should I place on security? A: Mention tokenization, encryption, and compliance early. You don’t need to detail every cipher, but showing awareness of PCI‑DSS signals maturity.

• Q: What if the interviewer asks for a concrete throughput number? A: Respond with a range (“typically a few hundred transactions per second for a mid‑size merchant, scaling to thousands with sharding”) and explain how you’d benchmark and scale.

• Q: Should I include a database schema diagram? A: A simple table list is enough. Over‑engineering the schema can waste time unless the interview explicitly asks for it.