Maker/Checker approval flow

The Maker/Checker approval flow applies to BIDV, which requires a high-security process and multi-level order approval. In this flow, a disbursement order can be saved as a draft (INIT) or submitted for approval directly (REQUEST_APPROVAL), and must then pass SmartOTP authentication on a device.

Flow characteristics

• Save as draft (INIT): The transaction is saved in the system and not yet sent to the bank. An order in this status can be deleted with the Delete a disbursement order API, or submitted for approval later with the Submit a saved disbursement order for approval API.
• Submit for approval (REQUEST_APPROVAL): The transaction is sent to the bank's system immediately to get the authentication data (QR code/SmartOTP). An order in this status cannot be deleted and must be confirmed with the Confirm payment order API.
• Requires two-factor security authentication via SmartOTP.

Flow diagram (Sequence Diagram)

The diagram below shows how payment orders are processed in the Maker/Checker model:

Maker/Checker approval flow

← Swipe to see more →

APIs in the flow

To fully integrate the Maker/Checker flow, you use the following APIs:

1. Get the authorization URL:
   • Gets the BIDV account login link. This step is required (for both Maker and Checker) before you can call the subsequent APIs.
2. Create a disbursement order:
   • Saves a draft (action="INIT") or submits for approval immediately (action="REQUEST_APPROVAL").
3. Delete a payment order:
   • Only works for transactions in draft status (INIT).
4. Submit a saved disbursement order for approval:
   • Moves a draft order (INIT) to pending approval (REQUEST_APPROVAL).
5. Confirm submission of a payment order:
   • The final step to complete the transaction. You must pass the SmartOTP from the BIDV disbursement app in the otp parameter to approve the order.
6. Approve a disbursement order:
   • Used by the Checker role to start approving a payment order. The API returns qrData for the Checker to scan with the BIDV disbursement app to get the OTP.
7. Confirm approval of a disbursement order:
   • Used by the Checker to confirm the approval; you must pass the OTP obtained in the previous step to complete the approval.
8. Reject a payment order:
   • Used when the Checker wants to reject a disbursement order. The order is cancelled immediately and does not require OTP authentication.
9. Transaction inquiry:
   • Used by the Maker/Checker to check and track the status of disbursement orders (pending approval, approved, posted, rejected...) or to get the child transactions in a batch by valid or invalid status.

---

Specifics of the Maker/Checker flow

💡 Processing by operation type (actionType)

• For Salary payment (SALARY) and Bill payment (BILL_PAYMENT): Disbursement orders are always processed as a Batch and share a single ID. Creating and submitting for approval (by the Maker) or approving and rejecting (by the Checker) apply to the entire batch of transactions.
• For Domestic transfer (INTERNAL_TRANSFER): Disbursement orders can be processed as a single order or a batch. In a batch, each record works fully independently with its own ID. As a result, the system supports flexible partial processing: the Maker can choose to submit or delete only some specific transactions; likewise, the Checker can approve or reject part of the list of transactions the Maker submitted instead of processing the whole batch.

💡 Posting time by transfer method

• NAPAS 24/7 fast transfer: As soon as the Checker successfully approves the order, BIDV posts the transaction immediately.
• Internal BIDV transfer and Regular interbank transfer: After the Checker approves, the transaction moves to pending (Pending) and BIDV needs some time to post it. You should proactively call the Transaction inquiry API to update the final status.