EP 1 | How to design a payment system 💰?

Hi, Aniket here 👋🏻 and welcome to my System Design Newsletter 😊!

I am a software engineer and am among the first 5 hires at Barq (fintech super app for MENA region, close to 2M users now!) where I have built payment systems from scratch. Previously, I have built distributed systems at Tetrate and Nutanix. You can find me on Linkedin as Aniket Singh.

I feel a bit nervous as I embark on this writing journey 😬. Over the past 5 years, I’ve had the privilege of building software systems at both mid-sized companies and startups, and now I’m excited to share the things I’ve learned along the way.

Fintech has always been close to my heart, so it feels natural to kick off this newsletter with a topic that’s relevant—Payment Systems. I hope that through sharing my knowledge, I can bring value to you all 🙏🏻. So, let’s begin!

---

What is a payment system? According to Wikipedia, “a payment system is any system used to settle financial transactions through the transfer of monetary value. This includes the institutions, instruments, people, rules, procedures, standards, and technologies that make its exchange possible” [1].

Payment systems have become more important than ever nowadays and knowing the intricacies of designing an efficient payment system can surely give an edge. Let’s dive into technicals:

At a high level, the payment flow is broken down into two steps to reflect how money flows:

• Pay-in flow

• Pay-out flow

Take amazon, as an example. After a buyer places an order, the money flows into Amazon’s bank account, which is the pay-in flow. Although the money is in Amazon's bank account, Amazon does not own all of the money. The seller owns a substantial part of it and Amazon only works as the money custodian for a fee.

Later, when the products are delivered and money is released, the balance after fees then flows from Amazon’s bank account to the seller's bank account. This is the pay-out flow.

The simplified pay-in and pay-out flows are shown in Figure 1.

Figure 1: Simplified pay-in and pay-out flow

Pay-in flow

The high-level design diagram for the pay-in flow is shown in Figure 2. Let’s take a look at each component of the system.

Figure 1

Detailed Pay-in flow:

1. Payment service

   1. Frontend hits payment service when customer wants to initiate checkout for items in their cart.

   2. The first thing it does is a risk check, assessing for compliance with regulations such as AML/CFT, money laundering or financing of terrorism. Risk checks are usually done through a 3rd party provider because it is complicated and highly specialised.

2. Initiate and store transaction

   1. Generate a nonce and send it to initiate payment with the PSP.

   2. The PSP sends a payment_uuid in response which needs to be stored in payments table with “status = INITIATED”. It’s also important to store each payment update in a payment_history table to track user drop-offs and debugging issues.

3. The client displays a PSP-hosted payment page (Figure 4). There are 2 ways to do this:

   1. Redirect URI: Initiate in previous step returns a redirect URI which can be shown on a web view on mobile devices.

   2. PSP’s SDK integration: PSPs such as Stripe provide a JavaScript library that helps in building the payment UI, collect sensitive payment information, and call the PSP directly to complete the payment.
      

Figure 3: Detailed PSP payment flow

Figure 4: PSP hosted page

4. Customer selects a payment method (credit card in our example) and sends a payment event to payment service.

5. A customer order might contain items from multiple merchants. Thus, a payment event contains multiple payment orders. Each payment order has be sent to a Payment Executor which executes them one by one.

6. Payment Executor

   1. Tokenise the card details with PSP and store card_token in the DB (if customer consents). Use the payment_uuid and card_token to complete the payment with the PSP. Communication between PSP and card networks also happens through tokenised details.

   2. Payment status is updated in the DB to something like IN_PROGRESS (in most cases, the final webhook in step 8 marks the payment as SUCCESS or FAILED).

7. Accounting

   1. Ledger service is responsible for lodging accounting entries for the payment. Double entry accounting which uses journals is a reliable way to implement this (separate post on this later).

   2. Wallet: If wallet (eg: Amazon pay) is selected as payment method, then wallet service is called which is responsible for deducting wallet balance and marking entries in ledger service (Figure 5).

      

      Figure 5: Wallet

8. After conducting risk checks and processing the payment at their end, PSPs send a payment status (SUCCESS/FAILED) either through webhook or require apps to poll the status. In case of failure, additional steps to refund the money are required.

9. Reconciliation: PSPs send settlement file (generally through SFTP) at the end of the day to reconcile all the payments. Reconciliation service matches all payments in settlement file with the ledger entries to validate all payments.

This sums up the design of pay-in system. Pay out part and more on payment systems in upcoming posts 🥳🥳!!

---