Payments / Intermediate / 7 min
Design a payment gateway
Authorise, capture, expire and refund. Watch holds run out before shipping and webhooks retry while the merchant is down.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A payment gateway sits between a merchant and the banks: it authorises a card (a hold), captures it (the money moves), and handles refunds.
- Why it matters
- Splitting authorise and capture lets shops charge only when they ship, and every step must be reported to the merchant reliably.
- The trade-off
- Late capture risks the hold expiring; webhooks can arrive late or twice, so merchants must be idempotent and also reconcile by API.
- Say it in an interview
- "A payment state machine (created, authorised, captured, refunded, expired) in a durable store, idempotency keys on every call, and signed webhooks retried with backoff."
Check yourself
What is the difference between authorising and capturing a card payment?
Answer: Authorise holds the money; capture actually moves it. Shops authorise at checkout and capture when they ship, so the customer is only charged for what is sent.
What happens if a hold is never captured?
Answer: It expires and the money is released back to the customer. Authorisations expire (often after about 7 days); after that the merchant must authorise again.
The merchant’s webhook endpoint is down. What should the gateway do?
Answer: Retry with growing gaps, and let the merchant also fetch the status by API. Webhooks are at-least-once with backoff; merchants should handle duplicates and reconcile by polling the API.