OpenAI·Software Engineer·Onsite - System Design / Architecture
May 2026
System design round at OpenAI for a software engineer role, focused entirely on designing a payment backend. The question was dense and had a lot of surface area, from idempotency to ledger design to reconciliation. Felt like I was constantly being pulled deeper before I finished the previous layer.
- Design the backend for a payment system that handles customer charges through external payment processors, covering everything from when a user clicks Pay to a confirmed, recorded transaction.
- A PSP call times out and you never receive a webhook. Walk through exactly how your system converges to the correct state and how long that takes. What does the customer see in the meantime?
- How do you guarantee exactly-once effect on the customer's card given that both your retries and the PSP's webhooks can deliver the same event more than once?
- How would you extend this design to route payments across multiple PSPs, for example failing over when one is down or routing by cost, without breaking idempotency or your internal ledger?
- How do you handle a chargeback or dispute that arrives weeks after the original payment, and how does that get reflected in your ledger?
- How would you support recurring subscription billing and retry logic for failed renewals on top of this payment core?
“This is the core question and it's massive.” 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