Payment System
What
- What kind of payment system are we building? (Payment backend for an e-commerce application like Amazon)
- What payment options are supported? (Credit cards, PayPal, bank cards; for the interview, focus on credit cards)
- What transactions are supported? (Customer payments and monthly payouts to sellers)
- What are the functional requirements?
- Handle payment processing via third-party processors
- Support 1 million transactions per day
- Support reconciliation to fix inconsistencies
How
- How do we handle credit card payment processing? (Via third-party payment processors like Stripe, Braintree, Square)
- How is sensitive credit card data stored? (Not stored directly in our system, handled by third-party processors)
- How do we handle reconciliation? (Perform reconciliation to fix inconsistencies due to service failures)
Who
- Who uses the payment system? (Customers and sellers on the e-commerce platform)
When
- When are payouts made? (Monthly payouts to sellers)
Why
- Why do we not store credit card data? (Due to high security and compliance requirements)
Where
- Where is the application used? (Globally, but assume only one currency for the interview)
E-commerce Payment Flow Overview
In an e-commerce system like Amazon, the payment process involves two main flows: the pay-in flow (when a buyer places an order and the money moves into Amazon’s bank account) and the pay-out flow (when the money, minus fees, moves from Amazon’s bank account to the seller’s bank account). Here’s an in-depth look at these flows:
Pay-in Flow
Key Components
-
Payment Service:
- Accepts payment events from users.
- Performs risk checks for compliance with AML/CFT regulations and checks for criminal activities such as money laundering or terrorism financing.
- Only processes payments that pass the risk check.
- Often uses third-party providers for risk checks.
-
Payment Executor:
- Executes a single payment order via a Payment Service Provider (PSP).
- Stores the payment order in the database.
-
Payment Service Provider (PSP):
- Moves money from the buyer’s account (e.g., credit card) to Amazon’s account.
-
Card Schemes:
- Organizations that process credit card transactions (e.g., Visa, MasterCard).
-
Ledger:
- Keeps a financial record of the payment transactions.
- Important for post-payment analysis, revenue calculations, and forecasting.
-
Wallet:
- Keeps the account balance of the merchant.
- Records total payments made by a user.
Pay-in Flow Process
- User Action: A user clicks the “place order” button, generating a payment event.
- Database Storage: The payment event is stored in the payment service database.
- Multiple Payment Orders: If the event contains multiple payment orders (e.g., products from multiple sellers), the payment service calls the payment executor for each order.
- Payment Processing: The payment executor stores each payment order and calls an external PSP to process the payment.
- Update Wallet: After successful payment processing, the payment service updates the seller’s wallet balance.
- Store Updated Balance: The updated balance is stored in the wallet database.
- Ledger Update: The payment service updates the ledger with the new transaction information.
Pay-out Flow
Key Components
- Third-Party Pay-out Provider: Handles moving money from Amazon’s bank account to the seller’s bank account.
- Payment Service: Similar role as in pay-in flow, managing the initiation and coordination of the pay-out process.
- Ledger: Updates with records of the pay-out transactions.
- Wallet: Updates to reflect the deduction in balance after the pay-out.
Pay-out Flow Process
- Initiate Pay-out: The payment service initiates a pay-out event.
- Process Pay-out: The pay-out provider processes the transfer of funds from Amazon’s account to the seller’s account.
- Update Wallet: The wallet service updates the seller’s balance to reflect the pay-out.
- Ledger Update: The ledger service records the pay-out transaction.
PSP Integration
In a payment system, integrating with a Payment Service Provider (PSP) simplifies the process of connecting to banks and card schemes like Visa and MasterCard. Direct connections to these entities are rare and usually reserved for very large companies due to the complexity and cost involved. For most companies, the PSP handles these connections, and the integration can be done in one of two ways:
-
API Integration:
- Used if the company can safely store sensitive payment information.
- The company develops the payment web pages and handles the collection and storage of payment information.
- The PSP connects to the banks or card schemes.
-
Hosted Payment Page:
- Used to avoid storing sensitive payment information due to regulatory and security concerns.
- The PSP provides a hosted payment page to collect and store card details securely.
- This is the more common approach.
For simplicity, the payment executor, ledger, and wallet components are omitted from the diagrams. The payment service orchestrates the entire payment process. Here’s how the flow typically works:
Payment Flow with PSP Integration
-
User Initiates Checkout:
- The user clicks the “checkout” button on the client browser.
- The client calls the payment service with the payment order information.
-
Payment Registration:
- The payment service receives the payment order information.
- It sends a payment registration request to the PSP, including details such as the amount, currency, expiration date, and redirect URL.
- The request includes a UUID (nonce) to ensure exactly-once registration, typically the payment order ID.
-
PSP Returns Token:
- The PSP returns a token, a UUID that uniquely identifies the payment registration.
- This token allows tracking the payment registration and execution status.
-
Store Token:
- The payment service stores the token in the database before calling the PSP-hosted payment page.
-
Display PSP-Hosted Payment Page:
- The client displays the PSP-hosted payment page using the PSP’s SDK or JavaScript library.
- The token and redirect URL are used by the PSP to display payment details and handle the process securely.
-
User Enters Payment Details:
- The user fills in payment details (e.g., credit card number, holder’s name) on the PSP’s page.
- The PSP processes the payment upon submission.
-
PSP Processes Payment:
- The PSP processes the payment and returns the payment status.
-
Redirect to Confirmation Page:
- The PSP redirects the user to the specified redirect URL, often an e-commerce page displaying the checkout status.
- The redirect URL may include the payment status as a query parameter.
-
Webhook Notification:
- Asynchronously, the PSP calls the payment service’s webhook with the payment status.
- The payment service updates the payment order status in the database based on this notification.