System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

• Make payments through different modes like Bank transfer, Credit/Debit card, digital wallet
• List payments made by a user and for each mode
• Receive notifications of the payment made and received
• Link/Delink bank accounts, Credit/Debit cards and digital wallet accounts to send money through the payment system

Non-Functional:

List non-functional requirements for the system...

• Secure and tokenize sensitive information as per international standards like PCI compliance
• Audit support. Any transaction must have an audit trail to find its origin and journey
• Replayability: It should be possible to trace operations of a transaction and verify correctness

Capacity estimation

Estimate the scale of the system you are going to design...

1000 Transactions Per Second (TPS)

Account information of linked accounts for each user will be stored. Considering a large-scale deployment of the payment system has a total of 100 million users, total data to be stored is:

• Account number or id (100 bytes)
• Card information (100 bytes)

= 1 TB approximately

API design

Define what APIs are expected from the system...

• Make payment through mode M1

POST https:///payment?mode=M1

Redirection 30x to payment processing page directly.

• List payments made by a user

GET https:///payments?user=x

Returns array of JSON

{

order name:

date:

status:

amount:

mode:

}

Similar api for filtering based on mode of payment

• Add a payment processing method

POST https:///business?id=x

Returns 20x for success or 40x/50x for failures

• Link/Delink an account

POST https:///account?action=link/delink

{

account number/id:

account type:

}

• Send notifications to users about payment status, account link/delink status etc.

Sent over websockets, https, or using notification service

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Use database with transactional guarantees. Leverage caching for high performance. Historical data can be moved to tape backup.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Account Link/Delink: Service for linking/delinking a bank, credit card or digital wallet account. It integrates with 3rd party APIs and SDKs to achieve this.

Payment Engine: Responsible for payment-related functions. It interfaces with 3rd party PSP and Digital Wallet providers to send payment requests, get response and error handling.

Notification Service: Used by both Link/Delink service and Payment Engine to send real-time and delayed notifications to the user.

Ledger: Keeps a log of all transactions for audit and traceability. Double-ledger system is followed.

Wallet: Transactionally credits and debits amounts in the merchant's account.

Reconciliation System: Runs a nightly job to consolidate and validate all transactions processed by 3rd party PSP and Digital Wallet and validate it with those in the Ledger. Flags any mismatch and/or error.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Payment Engine

==============

1. User requests to make payment through a given mode.
2. Request sent to 3rd party PSP or Digital Wallet. They respond with a unique identifier (nonce) to uniquely identify the request.
3. User is redirected to payment page hosted by PSP or Digital Wallet.
4. User fills up payment, card-related information
5. When payment is submitted, it is processed by the PSP or Digital Wallet.
6. Status (Success/Failure etc) is returned via a web-hook
7. Status displayed to the user.

Account Link/Delink

=================

1. User makes a request to link/delink and account
2. Depending on mode(card, bank, digital wallet), the required information is collected from user
3. 3rd party API or SDK is invoked to submit request to PSP or Digital Wallet.
4. PSP or Digital Wallet perform validation. Can take 2 business days.
5. Status info returned to Link/delink service
6. Notification sent to user.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Payment Engine

==============

1. User requests to make payment through a given mode.
2. Request sent to 3rd party PSP or Digital Wallet. They respond with a unique identifier (nonce) to uniquely identify the request.
3. User is redirected to payment page hosted by PSP or Digital Wallet.
4. User fills up payment, card-related information
5. When payment is submitted, it is processed by the PSP or Digital Wallet.
6. Status (Success/Failure etc) is returned via a web-hook
7. Status displayed to the user.

Account Link/Delink

=================

1. User makes a request to link/delink and account
2. Depending on mode(card, bank, digital wallet), the required information is collected from user
3. 3rd party API or SDK is invoked to submit request to PSP or Digital Wallet.
4. PSP or Digital Wallet perform validation. Can take 2 business days.
5. Status info returned to Link/delink service
6. Notification sent to user.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

• Tokenize account information for linked accounts

• Payment information is entered at a site hosted by PSP or Digital Wallet to keep the system simple.
• To avoid double-payment, the screen can be 1)greyed or 2)a nonce used to detect double payment. The current design uses nonce as it is implemented in the backend and not susceptible to client-side changes.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Double Payment:

User clicks 'Submit' twice. In such a case, she must not be double-charged. To avoid double-payment, the screen can be 1)greyed or 2)a nonce used to detect double payment. The current design uses nonce as it is implemented in the backend and not susceptible to client-side changes.

PSP and/or Digital Wallet Unresponsive or slow:

Implement timeout mechanism so that the payment times out after a certain amount of time. Add retries within timeout period to recover from transient errors.

Response Time Slow during peak times:

Add caching(Redis, NGINX), LB, horizontal scaling(service is stateless).

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

PSP and/or Digital Wallet Unresponsive or slow:

Implement timeout mechanism so that the payment times out after a certain amount of time. Add retries within timeout period to recover from transient errors.

Response Time Slow during peak times:

Add caching(Redis, NGINX), LB, horizontal scaling(service is stateless).