Katkat
Back

Design a Payment Processing Service (Merchant to Payment Provider)

OpenAISoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests the ability to design a reliable, fault-tolerant distributed system for handling financial transactions, focusing on idempotency, atomicity, and consistent state transitions.

Problem Statement

Design a payment processing service that acts as an intermediary between merchants and an external Payment Service Provider (PSP). The service must handle incoming charge requests from merchants, interact with the PSP API, and maintain an accurate ledger of transaction states (e.g., PENDING, AUTHORIZED, CAPTURED, FAILED).

Functional Requirements

  1. Process Payments: Accept requests to authorize and capture funds for a given amount and currency.
  2. Idempotency: Ensure that retrying the same request due to network instability does not result in duplicate charges.
  3. State Integrity: Prevent inconsistent states if the service crashes after calling the PSP but before updating the local database.

Non-Functional Requirements

  1. Consistency: Financial data must be strongly consistent.
  2. Availability: The system should handle transient network failures gracefully.
  3. Throughput: Assume 1,000 transactions per second (TPS).

Deliverables

  • Describe the API endpoints for merchants to initiate a payment.
  • Design the database schema to track transaction states and idempotency keys.
  • Outline the workflow to handle retries when the external PSP is unresponsive or returns a timeout.
  • Explain how you would perform reconciliation if the local database state and the PSP's actual state diverge.

Hints

Hint 1

Use a unique idempotency key provided by the merchant to check for existing requests in the database before processing.

Hint 2

Implement an outbox pattern or a state machine to ensure that the internal database update and the external API call are reconciled.

Hint 3

Consider using an asynchronous worker pattern to poll the PSP for status updates if the initial request returns a 'pending' or 'timeout' response.

Follow-up questions

  • How would you modify the design to support partial refunds or multi-stage capture processes?
  • If the PSP goes down for an extended period, how do you handle queued requests without overwhelming the PSP when it recovers?
  • How would you ensure data integrity during a database migration or a system-wide failover?