OpenAI·Software Engineer·Onsite - System Design / Architecture
Apr 2026
System design round at OpenAI for a software engineer role, focused entirely on building a payment processing service with exactly-once charging guarantees. Pretty brutal in scope, they wanted end-to-end architecture plus deep dives on idempotency and failure recovery all in one session.
- Design a payment processing service that sits between a checkout flow and an external payment provider, ensuring cards are never double-charged even under retries, timeouts, and duplicate webhooks.
- What clarifying questions would you ask before diving into this design, specifically around what 'exactly once' means and who is allowed to retry?
- Walk through the API design and data model for a single charge, including the full lifecycle from checkout request to recorded result.
- How do you design the idempotency mechanism end-to-end: key generation, storage, enforcement under concurrent duplicate requests, and propagation to the PSP call?
- The PSP call times out and you don't know if the card was charged. How do you resolve the unknown outcome without risking a double charge?
- How do you handle duplicate and out-of-order webhooks from the PSP, and how do downstream systems like the ledger and fulfillment service receive the final payment result exactly once?
- How would you extend this design to support auth-then-capture, voids, and partial refunds while keeping idempotency intact?
- The PSP goes down for 10 minutes. How do you degrade gracefully and what are the correctness implications of queuing vs failing closed vs failing over to a second PSP?
- How do you detect and prevent double charges caused by a buggy client that generates a fresh idempotency key on every retry?
“This is the core prompt and it's a lot.” The rest of the author's notes on Software Engineer interview at OpenAI, Onsite - System Design / Architecture round, covers how they worked through the question, what the panel pushed back on, and what they would do differently.
View Post