ProblemTransactions and payments
Payment gateway
NewLet online shops take card payments that are never charged twice, and pay them what they are owed.
The brief
Card payments for online merchants · suggested for Senior
Design a payment gateway
Design a payment gateway: online shops call your API to take card payments from their shoppers, hold money now and take it when they ship, refund, save shoppers’ cards, and get paid into their bank account.
Online shops of every size use your service to accept card payments. A shopper types their card details on the shop’s checkout page, and the shop asks you to charge them. Some shops take the money at once; others, like shops that ship later, hold the amount at checkout and take it when the order ships. Shops refund payments in full or in part, and can save a shopper’s card for their next purchase. You don’t approve cards yourself: you send each payment, through one of several acquiring banks you have contracts with, over the card network to the shopper’s bank, which decides. Many banks ask the shopper to confirm a payment with a one-time code or their banking app. Shops must learn the outcome of every payment, even when the shopper closes the browser, and are paid what they are owed into their bank account two working days after the money is taken, minus your fees. Card numbers are the most sensitive data you hold, and the card industry’s security standard (PCI DSS) applies to every system that stores, processes or sends them. Design the service, from the shopper typing a card number to the shop being paid.
Functional requirements
- CoreShops take card payments from their own checkout page through your API.
- CoreA shop can take the money at once, or hold it at checkout and take it later, while the hold lasts.
- CoreShops can cancel a held payment, and refund a payment in full or in part.
- CoreShoppers can save a card with a shop and pay with it next time.
- CoreWhen the shopper’s bank asks them to confirm a payment, they can do it with a code or their banking app.
- CoreShops learn the outcome of every payment, and are paid what they are owed into their bank account.
Non-functional requirements
- ConsistencyA shopper is never charged twice for one payment, however often the shop’s server retries.
- ConsistencyA payment is never written off as failed while the shopper may have been charged: any early answer keeps being checked, and money taken without a payment always goes back.
- LatencyThe shopper gets an answer within a few seconds of paying, apart from their bank’s own confirmation step.
- SecurityCard numbers are protected to the card industry’s security standard (PCI DSS); a leak would be catastrophic.
- QualityShops learn the final outcome of every payment, even if the shopper closes the browser.
- ConsistencyShops are paid exactly what they are owed: the money taken, minus fees and refunds.
- AvailabilityTaking payments stays available (99.99%), even while an acquiring bank or a whole region is down.
Scale
- ScaleAbout 1 million shops, from tiny ones to large marketplaces.
- ScaleAbout 100 million card payments a day; on big sale days, peaks of about 10 times the average.
- ScaleMost banks answer in a second or two; some answer late, and some never do.
- ScaleSeveral acquiring banks in each region.
Nice to mention (below the line)
- Below the lineDisputes and chargebacks.
- Below the lineIn-person (card-present) payments.
- Below the lineDashboards and reports for shops.
Out of scope
- Out of scopeBank transfers, UPI, netbanking and wallets.
- Out of scopeHow the risk service scores a payment.
- Out of scopeConverting currencies.
- Out of scopeSigning up and checking shops (onboarding).
The variant
One fully specified brief, with the level it suits best. You can practise it at any level.
- Card payments for online merchantsSuggested for Senior
Online shops take card payments through your API: charge or hold now and take later, refunds, saved cards, the shopper’s bank check, and getting paid.
9 steps · 5 must-pass · about 50 min at Senior
What each level is graded on
Card payments for online merchants, step by step. A result at a level needs its must-pass steps answered, and only the steps you answer count. Going up a level adds steps or holds them to a stricter bar.
| Step | Entry level | Mid-level | Your levelSenior | Staff |
|---|---|---|---|---|
| The numbers that shape the design (optional) | Graded | Graded | Graded | Graded |
| Payments, attempts and refunds | Graded | Graded | Graded | Graded |
| The API merchants call | Graded | Graded | Graded | Graded |
| From the checkout to the shopper’s bank | Must-pass | Must-pass | Must-pass | Must-pass |
| The merchant’s request times out | Must-passcan block | Must-passcan block | Must-passcan block | Must-passcan block |
| The bank goes quiet | Must-pass | Must-pass | Must-pass | Must-pass |
| Hold today, take the money when it ships | — | Must-pass | Must-pass | Must-pass |
| The shopper’s bank asks for a code | — | Must-pass | Must-pass | Must-pass |
| Money reaches the merchant | — | — | Graded | Graded |
| An acquirer slows down, then a region goes down | — | — | — | Must-pass |
| At this level | 6 steps 3 must-pass about 31 min | 8 steps 5 must-pass about 44 min | 9 steps 5 must-pass about 50 min | 10 steps 6 must-pass about 58 min |
Entry level6 steps · 3 must-pass · about 31 min
- The numbers that shape the design (optional)Graded
- Payments, attempts and refundsGraded
- The API merchants callGraded
- From the checkout to the shopper’s bankMust-pass
- The merchant’s request times outMust-passcan block
- The bank goes quietMust-pass
Mid-level8 steps · 5 must-pass · about 44 min
- The numbers that shape the design (optional)Graded
- Payments, attempts and refundsGraded
- The API merchants callGraded
- From the checkout to the shopper’s bankMust-pass
- The merchant’s request times outMust-passcan block
- The bank goes quietMust-pass
- Hold today, take the money when it shipsMust-pass
- The shopper’s bank asks for a codeMust-pass
SeniorYour level9 steps · 5 must-pass · about 50 min
- The numbers that shape the design (optional)Graded
- Payments, attempts and refundsGraded
- The API merchants callGraded
- From the checkout to the shopper’s bankMust-pass
- The merchant’s request times outMust-passcan block
- The bank goes quietMust-pass
- Hold today, take the money when it shipsMust-pass
- The shopper’s bank asks for a codeMust-pass
- Money reaches the merchantGraded
Staff10 steps · 6 must-pass · about 58 min
- The numbers that shape the design (optional)Graded
- Payments, attempts and refundsGraded
- The API merchants callGraded
- From the checkout to the shopper’s bankMust-pass
- The merchant’s request times outMust-passcan block
- The bank goes quietMust-pass
- Hold today, take the money when it shipsMust-pass
- The shopper’s bank asks for a codeMust-pass
- Money reaches the merchantGraded
- An acquirer slows down, then a region goes downMust-pass
- Must-pass
- a result at that level needs this step answered.
- Can block
- a miss there is a Blocking issue at that level.
Going up a level
- Mid-level
- “From the checkout to the shopper’s bank” is graded more strictly.Adds “Hold today, take the money when it ships”, must-pass.Adds “The shopper’s bank asks for a code”, must-pass.
- Senior
- “Hold today, take the money when it ships” is graded more strictly.“The shopper’s bank asks for a code” is graded more strictly.Adds “Money reaches the merchant”.
- Staff
- Adds “An acquirer slows down, then a region goes down”, must-pass.
Skills this problem practises
Your coach tracks readiness per skill across every problem you practise. Each links to the lesson that teaches it.
- Capacity estimation
- API design
- Idempotency and retries
- Data modelling
- High-level architecture
- Queues and async messaging
- Replication and durability
- Failure modes and recovery
- Observability and operations
- Latency budgets
- Security and privacy
Worked solution
Try it first: practise a variant, then read the walkthrough and compare it with your own design. Reading it first makes the practice much less useful.
Learn: Design a Stripe-style payment gatewayYour history
Sign in to see your sessions on this problem.