Payment System Design Basics

User on an e-commerce website is about to check out (the purchase page is given by the purchase service provider):

1. e-commerce website’s Backend Payment System (BPS) will call the API of the chosen 3^rd PSP (3PSP) and register a payment session with unique check out ID.
2. 3PSP will give a token in return to the BPS.
3. BPS saves this data in their database.
4. BPS also redirects the user to purchase page with the same token.

When user clicks on “Buy Now”:

1. e-commerce website will share a POST request with purchase info and token with their BPS.
2. BPS will save this data in their database along with the purchase status (started, failed, successful).
3. BPS will send purchase info, token, Redirect URL (successful status can be shown on dashboard or new page) with the 3PSP. Also give the 2PSP a webhook endpoint (polling the issuer bank API for checking the status of payment. It can take time occasionally); then send the status back to BPS after couple of hours which the BPS will update in their database. A logic can be built which shows that the updated status on a webpage or mid office.
4. 3PSP sends the successful response with BPS.
5. BPS saves this data in their database.
6. BPS redirects the user to a pre decided web page.

Database will have other items apart for following mandatory ones:

1. Check out ID
2. PSP token
3. Amount
4. Currency (ideally in string because different languages can read integer differently)
5. Status

Microservice communication for reducing double charge/ spend:

1. Sync:
   1. A send to B and waits. If B needs to send it further to C, then A waits till both B and C complete action. While it is easy to set up, but if one point fails then all fails. There will also be timeouts.
2. Async:
   1. Better at failure handling, retries, decoupled. But difficult to set up and debug.

Network problems(front end and back end. Or back end and PSP) or e-commerce page not updated can still cause double spend. Every purchase will have unique checkout_id and corresponding token from PSP. If user clicks “Buy Now” twice, the PSP will see the token being reused and understand that this is a retry. But of the PSP had responded with success for the first time for the token, then it will throw away the request.