System requirements

Functional:

1. User should be able to make digital/online payment securely.
2. End user should have client application with following capabilities
3. Account management: Add a bank account and authorise app for transaction using application.
4. Fund transfer:
5. Transfer fund from app to bank account.
6. Receive funds from standard bank transaction as per banking regulation in a country where app is operated.
7. Payment processing: Transfer funds to different formats like format accepted in US to format accepted in Europe for bank transfer from US to Europe.
8. Fraud detection: Implement a mechanism to detect and avoid possible fraud.
9. Buyer and seller protection: Protect buyer and seller with best possible cyber security protection.
10. Multi currency support: Application should support international transaction across different countries.

Non-Functional:

1. Application should be highly secure. Entire transaction workflow should be very secure.
2. Highly scalable.
3. Highly available.
4. Highly performant all the API's should have lowest possible latency.
5. Strongly consistent system.
6. Highly resilient.

Capacity estimation

1. No of users: 100 million users.

User data : 10k/User

2 . 10000 Transaction/second.

Transactions are writes

3.Transaction retention period is 7 years.

4.SLA 99.99%

API design

REST API details

1. API for making payment

HTTPS enabled

HTTP method : POST

HTTP header:

"content_type":"application-payment/json"

"accept_type":"application-payment/json"

"access_token":""

"user_details":""

URL path: v1/pay

payload:

{

source_bank_ic:string,

target_bank_ic:string,

source_acc_no:int64,

target_acc_no:int64,

amount: float32,

source_currency_type:"",

target_currency_type:""

}

Response:

{

status:"success/failure",

txn_id:""

}

2.API for adding account

HTTPS enabled

HTTP method : POST

HTTP header:

"content_type":"application-account/json"

"accept_type":"application-account/json"

"access_token":""

"user_details":""

URL path: v1/account/add

payload:

{

source_bank_ic:string,

acc_no:int64,

acc_name:"",

additional_details:{}

}

Response:

{

status:"success/failure"

}

3.API for deleting account

HTTPS enabled

HTTP method : DELETE

HTTP header:

"content_type":"application-account/json"

"accept_type":"application-account/json"

"access_token":""

"user_details":""

URL path: v1/account/delete/{:id}

payload:

{

acc_no:int64

}

Response:

{

status:"success/failure"

}

4.API for history transaction

HTTPS enabled

HTTP method : GET

HTTP header:

"content_type":"application-account/json"

"accept_type":"application-account/json"

"access_token":""

"user_details":""

URL path: v1/transaction

payload:

{

acc_no:int64,

start_date:data,

end_date:date,

page_no:0

}

Response:

{

"txn":[

{txnNo:int32, amount:float32}

],

"next":{

acc_no:int64,

start_date:data,

end_date:date,

page_no:X

}

}

Database design

1 Real time payment need a transactional database so only live payments are stored in RBDMS. With entities as mentioned in ER diagram

real time transaction of calling debiting source bank, crediting to target bank and updating DB will be done in a transaction boundary. Each of the events will be pushed to kafka and stored in events table in Cassandra for analytics purpose.

2 Once transaction is processed data will be moved to history Database. Or database holding cold records.

For storing history records Cassandra DB will be used. Following are the partition key and clustering keys

Partition key: User_id

clustering keys: transaction_id, transaction_date

Expected query: select * from .history_txn where user_id=<> and transaction_date > start and transaction_date < end

High-level design

Client: Web and application client. Implemented considering client side vulnerability, OWASP API security. Communicate with Server side over HTTPS. API calls to server is authorized using PKCE authorization grant flow. Multifactor authentication done using OIDC and TOPT.

Load balancer: Does following

1. TLS termination
2. API load balancing
3. API authorization.
4. RATE limiting.

Payment service: Stateless service responsible for real time payment handling. Executes the payment in a transaction boundary. Transaction are handled in RDBMS.Each activity event will be published to kafka later used for analytics and fraud detection purpose.

Payment history: implement API's specific to history operation. Like transaction history.

Bank specific adaptor: Establish TLS connection with 3rd party banks and transforms message into format which bank/clearing house understand. Each activity event will be published to kafka later used for analytics and fraud detection purpose.

Request flows

Sequence diagram used.

Detailed component design

Payment service: Will initiate a transaction and execute entire payment in the transaction boundary. Payment service interact with bank adaptors which are specific to banks/country and any events will be posted to kafka which will be later utilized by analytics and fraud detection purpose.

Fraud detection will detect anamoly in payment, Unusual payment patterns, Blacklisted target banks/accounts and give a feedback to stop the transaction.

MYSQL/ACID transaction DB: MYSQL will have read replicas in case of failure of primary any of the read replicas can pick up as primary.

Fraud detector: Will analyse the payment events and user transaction history. And implement machine learning model to come up with anomoly detection, black listing suspected accounts/regions.

Trade offs/Tech choices

1. For payment processing RDBMS is used but single primary replica acts as a bottle neck but provides transactional capabilities.

Failure scenarios/bottlenecks

For payment processing RDBMS is used but single primary replica acts as a bottle neck but provides transactional capabilities.

Future improvements

If RDBMS used for payment service wont scale we can use SAGA pattern for transaction handling and use Scalable database with eventual consistency instead of MYSQL