Alex Xu V2 - 11 Payment System



A system used to settle financial transactions.

Seem simple but one mistake can cause big revenue loss and reputation damage.

Step 1 - Understand Problem and Establish Design Scope

Need to narrow the requirements. Don’t know if interviewer means a digital wallet or something like Stripe / PayPal

Candidate Questions

(Can users contribute to multiple charities with a single payment???)

What kind of payment system are we building?

What payment options are supported? Credit cards? PayPal? Bank cards?

Do we handle credit card processing ourselves?

Do we store credit card data in our system?

Is the application global? Do we need to support different currencies and international payments?

How many transactions per day?

Do we need to support the pay-out flow, which an e-commerece site like Amazon uses to pay sellers every month?

I think I’ve gathered all requirements, is there anything else I should pay attention to?

Functional Requirements

Pay-in flow -> Payment system receives money form customers on behalf of sellers

Pay-out flow -> Payment System sends money to sellers around the world.

Non-Functional Requirements

Reliability and Fault Tolerance

Reconciliation process between internal services

Back of Envelope Estimations

1M transactions a day -> 1 10 ^ 6 / 10^5 -> 10 QPS

Focus of this system design isn’t high throughput, it’s handling the payment transactions

Step 2 - Propose High-Level Design and Get Buy in

![[Pasted image 20240218092608.png]]

In-Flow ![[Pasted image 20240218092643.png]]

Payment Service

Payment Executer


Card Schemes



APIs for payment service

POST /v1/payments

GET /v1/payments/{:id}

Data model for payment service

Most likely going to do SQL at 10 QPS

We want

Xu recommends SQL

Payment Event table

![[Pasted image 20240218093837.png]]

Payment Order Table

![[Pasted image 20240218093903.png]]

Checkout creates a payment event that can contains several payment orders to process

After sending to PSP, we dont’ directly transfer money to seller. We hold it in the e-commerce website’s bank account for “pay-in” and distribute it when pay-out condition is satisfied

Use the payment_order_status to track where we’re at

SUCCESS means we start the wallet process And then the ledger process and update it’s field (if database gives an ACK, I guess)

Double-Entry Ledger System

![[Pasted image 20240218094539.png]]

Sum of transactions must be $0

Proves end-to-end traceability

Hosted Payment Page

Pay out flow

Step 3 - Design Deep Dive

Focus on making the system more robust, faster, and secure

PSP Integration

Visa and Mastercard only allow integration directly for massive companies that can afford the investment on their part (It’s a lot of specific work)

Other companies have to do

![[Pasted image 20240218095442.png]]


Periodically compares states among related services to verify they are in agreement.

The last line of defense of payment system.

Every night the PSP or banks send settlement file to their clients.

Finance team usually performes manual adjustments if discrepancy occurs

Three types of mismatches

Handling Payment Process Delays

PSP can take forever to get back or wants a high investigation Credit Card requires extra protection and details from the card holder

PSP would return pending status to the client and our client would display that to the user PSP tracks pending payment on our behalf and notifies payment service via webhook that it’s pending

Communication among internal services

Synchronous HTTP doesn’t work well as scale increases. Long request and repsonse cycle increaes latency


![[Pasted image 20240218100352.png]]

Handling Failed Payments

Track the payment state

![[Pasted image 20240218100509.png]]

Exactly-Once Delivery

need to make sure a retry doesn’t end up succeeding

Dont’ allow user to click pay button quikcly twice

Use a cache to make sure the request is fresh / new

Skipping the last 2 pages of this Chapter to come back later

![[Pasted image 20240218100851.png]]