Design a Payment Gateway

Design a generic payment gateway that authorizes payments, handles retries and asynchronous processor updates, and preserves an auditable transaction state.

Design a generic payment gateway that authorizes payments, handles retries and asynchronous processor updates, and preserves an auditable transaction state. Use this guide to structure the discussion, test the design under pressure, and practise explaining trade-offs clearly.

Problem and Scope

Design a payment gateway system similar to Stripe or PayPal that allows businesses to process online payments securely and reliably.

Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.

Requirements to Clarify

A strong answer should establish scope before choosing components.

Functional requirements:

Process credit/debit card payments from customers
Support the auth-capture workflow for payment processing
Allow businesses to issue refunds for transactions
Provide payment status tracking and reporting
Support multiple payment methods (credit cards, bank transfers, etc.)
Implement security measures to protect sensitive payment information
Provide APIs for businesses to integrate the payment gateway into their applications

Non-functional requirements:

High reliability (99.99%+ uptime) as financial transactions are critical
Low latency for payment processing (response within seconds)
Strong security to protect payment data (PCI DSS compliance)
Scalability to handle peak transaction volumes
Transaction idempotency to prevent double-charging
Data consistency across distributed systems
Auditability for all financial transactions

Scale and Capacity

Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:

Support for millions of businesses
Billions of transactions per day (~10,000+ transactions per second)
Transaction amounts ranging from less than $1 to millions of dollars
Global system with users across different regions and currencies
Support for peak volumes during shopping events (up to 10x normal volume)

Architecture Discussion

Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:

Payment processing API
Auth-capture workflow implementation
Payment data storage system
Security and encryption systems
Fraud detection mechanisms
Reporting and analytics systems
Integration with external payment networks
Monitoring and alerting systems
Implementing idempotent transaction processing to prevent double charges
Designing a reliable system with appropriate retry mechanisms
Securing sensitive payment information according to industry standards
Managing distributed transactions across different services
Handling partial failures in the payment processing workflow
Scaling the system to handle peak loads
Ensuring compliance with financial regulations across different regions

Follow-up Questions

Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:

Could you explain your approach to ensuring transaction idempotency?
- Focus: Assess the candidate's answer to "Could you explain your approach to ensuring transaction idempotency" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
How would your system handle a failure during the payment capture process?
- Focus: Assess the candidate's answer to "How would your system handle a failure during the payment capture process" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
What data storage solutions would you choose for different components of your system?
- Focus: Assess the candidate's answer to "What data storage solutions would you choose for different components of your system" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
How would you design the system to be compliant with PCI DSS requirements?
- Focus: Assess the candidate's answer to "How would you design the system to be compliant with PCI DSS requirements" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
What's your strategy for handling retry logic in case of failures?
- Focus: Assess the candidate's answer to "What's your strategy for handling retry logic in case of failures" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
How would you implement the auth-capture workflow in your design?
- Focus: Assess the candidate's answer to "How would you implement the auth-capture workflow in your design" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.

Evaluation Rubric

MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.

Requirements and scope (15%): Clarifies and prioritizes the required behavior for Process credit/debit card payments from customers; Support the auth-capture workflow for payment processing; Allow businesses to issue refunds for transactions. Establishes the constraints that materially affect Design a Payment Gateway, including High reliability (99.99%+ uptime) as financial transactions are critical; Low latency for payment processing (response within seconds). Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Payment processing API; Auth-capture workflow implementation; Payment data storage system; Security and encryption systems. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
Data and scaling (25%): Uses workload assumptions such as Support for millions of businesses; Billions of transactions per day (~10,000+ transactions per second) to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Payment data storage system. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Security and encryption systems; Fraud detection mechanisms; Monitoring and alerting systems. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Handling partial failures in the payment processing workflow; Scaling the system to handle peak loads; Ensuring compliance with financial regulations across different regions. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.