Design a scalable payment processor

Q: Design a scalable payment processor

This question evaluates skills in large-scale distributed system design, secure payment processing, transactional consistency (idempotency and exactly-once semantics), regulatory compliance (PCI/PSD2/GDPR), data modeling for ledgers and audit logs, integration with external networks, and operational concerns like scalability, resilience, and observability. It is commonly asked because interviewers need to assess architectural trade-offs, fault-tolerance and orchestration for multi-step money flows, reconciliation and settlement logic; the category is System Design and the level of abstraction spans both high-level conceptual architecture and detailed practical application.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Q: What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at OpenAI.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at OpenAI during technical interviews.

Question

System Design: Online Payment Processing Platform

Scenario

Design a multi-tenant online payment processing platform that lets merchants accept card and digital wallet payments globally. Assume a mix of e-commerce (card-not-present) use cases and support for regional regulations (e.g., PSD2/SCA in the EU). Merchants integrate via REST APIs and webhooks.

Functional Requirements

Payments API
- Authorize, capture (partial/multiple), refund (partial/multiple), void/cancel.
- Idempotency keys and exactly-once charge semantics from the merchant’s perspective.
- Tokenization for cards and wallet payment methods; avoid storing PAN in merchant systems.
- Webhooks for state changes (authorized, captured, refunded, chargeback, payout).
End-to-end processing
- Flow across gateway, acquirer, card networks, and issuers.
- 3DS/SCA support (frictionless and challenge flows), risk scoring, velocity controls, optional ML risk.
- PCI scope boundaries and tokenization strategy.
Data and accounting
- Data model for transactions, ledger entries, settlements, chargebacks, payouts, and immutable audit logs.
- Consistency model, deduplication, retries, and orchestration (outbox/SAGA) for multi-step workflows.
Money movement and operations
- Settlement/clearing with acquirers, currency conversion, fees, and scheduled payouts.
- Reconciliation against acquirer/network files and dispute handling.

Non-Functional Requirements

Scalability: thousands of TPS at peak; p99 latency < 200 ms for authorize (excluding 3DS challenges).
Resilience: backpressure, queueing, retries with idempotency.
Availability: multi-region active-active. State your RPO/RTO objectives and data replication approach.
Observability: metrics, tracing, log correlation. Secure access control, PII/GDPR handling, key management.
Testing: strategy for unit/integration/load; simulators/mocks for external partners; handling timeouts/partial failures.

Deliverables

Provide a detailed design covering:

API design and exactly-once semantics.
End-to-end processing flows, tokenization, and PCI boundaries.
Risk/fraud controls and 3DS/SCA.
Data model and storage approach, including ledgers and audit logs.
Consistency, deduplication, orchestration (outbox/SAGA).
Settlement, reconciliation, currency conversion, fees, payouts.
Scalability, backpressure, HA/DR.
Observability, security, privacy, and key management.
Testing and failure-handling strategies.

Design a scalable payment processor

Quick Overview

System Design: Online Payment Processing Platform

Scenario

Functional Requirements

Non-Functional Requirements

Deliverables

Solution

Comments (0)