Payment Processing System – System Design Interview Preparation

Practice designing a payment processing system. Cover transaction processing, idempotency, reconciliation, and fraud detection.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Payment System design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Payment System is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Idempotency and exactly-once semantics over unreliable networks. Every other part of the design is in service of never double-charging and never losing a payment.

Scale to establish before drawing anything

10,000 transactions a second at peak, each touching several external systems with their own failure modes.
Every state transition must be durable before it is acknowledged - this system cannot trade durability for latency.
Reconciliation runs continuously, not nightly, because an unresolved payment is money in limbo.

Core components

Payment orchestrator – Owns the payment state machine and is the only writer to it.
Idempotency store – Client-supplied key to result. A retried request returns the original outcome rather than charging again.
Ledger – Append-only double-entry records. Balances are derived, never updated in place.
Gateway adapters – One per provider, isolating their differing failure semantics behind one interface.
Reconciliation service – Compares your ledger against provider settlement files and raises mismatches.
Webhook handler – Receives asynchronous provider callbacks, which may arrive out of order or twice.

Trade-offs to defend

Idempotency keys everywhere – The client generates a key per intent, not per request. This is the single most important detail in the answer and the one most often missed.
Saga with compensation – Distributed transactions across a bank and a gateway do not exist. Compensating actions and a state machine do.
Append-only ledger – Updating a balance in place makes an error unrecoverable and an audit impossible. Deriving balances costs compute and is worth it.

Follow-up questions to expect

A gateway call times out. You do not know whether the charge happened. What do you do next, and what does the customer see?
A webhook arrives twice, out of order, 20 minutes apart. Walk through your handler.
Reconciliation finds a charge the provider has and you do not. What is the process?