System requirements
Functional:
- User should be able to make digital/online payment securely.
- End user should have client application with following capabilities
- Account management: Add a bank account and authorise app for transaction using application.
- Fund transfer:
- Transfer fund from app to bank account.
- Receive funds from standard bank transaction as per banking regulation in a country where app is operated.
- Payment processing: Transfer funds to different formats like format accepted in US to format accepted in Europe for bank transfer from US to Europe.
- Fraud detection: Implement a mechanism to detect and avoid possible fraud.
- Buyer and seller protection: Protect buyer and seller with best possible cyber security protection.
- Multi currency support: Application should support international transaction across different countries.
Non-Functional:
- Application should be highly secure. Entire transaction workflow should be very secure.
- Highly scalable.
- Highly available.
- Highly performant all the API's should have lowest possible latency.
- Strongly consistent system.
- 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
- 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
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
- TLS termination
- API load balancing
- API authorization.
- 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
- 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