Katkat
Back

Design a Payment Processing System with Exactly-Once Charging

OpenAISoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests the ability to design a fault-tolerant payment system that handles distributed transactions, ensures idempotency, and reconciles state with external gateways.

Problem Statement

Design a payment processing service that charges a customer's credit card once and only once for a given order, despite potential network partitions, client retries, or server crashes.

Assume you are integrating with a third-party payment gateway (e.g., Stripe/Braintree) that provides an API for charging cards. Your service must expose an process_payment(order_id, amount, payment_token) endpoint to the internal order service.

Functional Requirements

  • Ensure exactly-once execution per order_id.
  • Handle retries from the client safely.
  • Track payment status (Pending, Succeeded, Failed).

Non-functional Requirements

  • High consistency: The internal state must accurately reflect the gateway's status.
  • Fault tolerance: The system must survive partial failures during the request-response cycle.

Evaluation Criteria

  • How do you handle cases where the gateway charges the card, but the network fails before you receive the acknowledgment?
  • What mechanisms ensure idempotency across distributed services?
  • How do you reconcile discrepancies between your database and the payment provider's records?

Hints

Hint 1

Use a database to store the state of the transaction and a unique idempotency key derived from the order ID before initiating any external calls.

Hint 2

Implement a state machine for each transaction that transitions only under specific conditions to avoid duplicate processing.

Hint 3

Consider an asynchronous reconciliation job that periodically polls the payment gateway for the status of 'pending' transactions to resolve timeouts.

Follow-up questions

  • How would you handle a scenario where the database commit for the 'Succeeded' state fails after the external call completes?
  • What specific database isolation levels or locking strategies would you use to prevent race conditions when multiple instances process the same request?
  • How would you design the system to handle 'webhooks' from the payment gateway to update your internal state asynchronously?