Overview

The business center will be in charge of the business operations such as transfer, query transactions, balance, history, which is the middleman between user and account center. It will receive request from user, and validate token from user center, and perform action to ensure seperation of concerns from accounting and business logic.

how business center interacts with user center

  1. When user tries to view balance, make transfers, business needs to know if user is valid by checking request operatorId with the JWT hash userId. Once valid, get the account Id to query the account center
  2. transfer from one to another account, the money deduction should be done in account center. But the business logic such as to whom,

Main Interfaces

Term Description
transfer User enters their name, phone number, password, confirm password
transferConfirm When there is a transfer over limit, verifyOTP is required
queryTransactionDetails User enters their phone number and password.
queryTransactionHistory User enters the OTP sent to their phone number to confirm payments over the threshold.
queryBalance after user enters the otp values, we verify it with the OTP stored in cache
topUp allows user to connect to their bank account or car and deposit some amount to their e-wallet account

Interfaces

Transfer [transferInit]

To take note :

  1. if there are two users performing transfer operation on the same person’s record, there will be concurrent updates. — not atomic. does not have idempotency

    1. To solve, add a for update in the query, + transaction template

  2. Or if he press the transfer button two times, and passes the validation check, it deducts the money from his account twice. — race condition.

    1. to solve, add idempotency table insert, when the user clicks on transfer.

    2. it should be inserted when user clicks on transfer and is prompted to enter the password

    3. So, we frontend needs to generate a unique idempotency key when the user enters the password page, then this key is passed into the request and creates a new idempotent record, so two retries will still pass the same idempotent key, so once the first is created, the second is discarded.

    4. Only the very last confirmation do you need to have the same idempotency key passed in the request.

    5. We need to have an idemptency key table to ensure the transaction can be retried at a later time in case of a failure.

      Screenshot 2026-02-03 at 10.04.44 PM.png

  3. The main goal is to develop system where when user presses transfer confirm, it will display the enter pin pop up, that should not create a new transaction, rather to issue a jwt token with expiry and verify it later after user entered their password

  4. So in transferInit, just issue a JwtToken .

transferInit