Product Management interview question [Technical]: Build the payment API for a charity event.

picture credits — unsplash[dot]com

Just want to clarify that there is a charity event where people come and donate some money to help the cause and we want to design an API Gateway for the donation transactions. Right? Correct.

I have a few more clarifying questions on this -

1. Are we considering only digital payments or will this also involve physical money being transferred like in an ATM? Only digital money transfer for now.
2. Do we need to support multiple banks or just a single bank/vendor? Multiple.
3. Do we need to support a single currency or all the currencies?All the currencies.
4. Do we need to support multiple payment methods namely Credit card, Debit card, Netbanking, Online wallets (Paytm, Airtel Payment banks, GPay, PhonePe…), UPI? Just debit card for now.
5. Since this is a charity event, and many people donate regularly to important causes, do we want to make this like a recurring payment service or a one-time payment? One time for now.
6. Do we have a bank where all this donation will be sent or is there an online wallet or something? Bank for now.
7. Do we want the users to log into the system or they can just share their name, title etc and pay the donation? Also, many people prefer anonymous donations, do we want to support that as well? No logging in needed. People can donate money anonymously.
8. Do we need to generate the donation receipts as well for the donors? Yes!

Thank you for clarifying that. Now, I’ll take a few minutes to think upon the entire system and the relevant APIs that need to be created. This exercise will require me to work on the entire system of how Payment gateways work and then I’ll talk about the APIs that will be needed for each of these services. So this is how the system will look like -

1. The application will make a POST call to the user’s bank. This will look something like -

request ⇒ {
 amount (decimal),
 currency (varchar(10)),
 session_id (varchar),
 encpt(cc_number) (varchar),
 encpt(cvv) (varchar),
 encpt(expiry_number) (varchar)
}

2. Here the encpt is the encrypt function to send the data securely to the servers. Along with this we also send an identifiers of sorts in form of session_id which is exchanged in every API call to make sure that the transaction ends if the session is changed.

3. The users’ bank will validate the details on the card and send a success as a response along with the same session_id where the transaction is going on.

response => {
 validated: True (boolean),
 session_id (varchar)
}

4. The application sends a POST request with the OTP received by the user along with the session_id back to the server.

request => {
 encpt(otp) (varchar), 
 session_id (varchar) 
}

5. The user’s bank makes an API call to the Foreign currency exchange server with the details of the currency and the amount to convert everything to a universal currency for parity. (let this be USD here). The POST request contains details on the amount, the existing currency and the desired currency (here USD) —

request => {
 amount_in_xyz_currency (decimal),
 xyz_currency (varchar(10)),
 USD (varchar(10))
}

6. The Foreign currency exchange server responds with the amount in USD back to the user’s bank server.

response => {
 amount_in_usd (decimal)
}

7. Now the user’s bank servers makes a POST call to the receiver bank’s server (here the charity organizer’s bank) with all the relevant details of the transaction — sender’s bank details, receiver banks details, amount, currency etc.

request => {
 encpt(users_bank_account_details) (json),
 amount (decimal),
 USD (varchar(10)),
 encpt(receivers_bank_account_details) (json)
}

8. The receiver bank will respond with a success message which will complete this transaction.

response => {
 success: True (boolean)
}

9. Finally the user’s bank server will also send a response to the application that the transaction has been completed.

response => {
 success: True (boolean)
}

The system will work something like this -

Then we also have to think about other nuances of APIs like -

1. Rate limits, to reduce the abuse. About 1000 API calls per minute should be good enough upper cap in this case considering this is a live event and at least 100 people will be making payments at any given time.
2. A way to settle disputes: Say the amount has been deducted from the user’s account but hasn’t been credited to the charity event organizer’s account.
3. Saving payment details post bank working hours.
4. Compliance and security standards. Adhering to all the compliances and security standards.