azuwlaa/android
1
0
Fork 0
forked from thijooree/android
Code Pull Requests Activity

update docs

Browse Source
This commit is contained in:
shihaam
2026-06-13 21:30:12 +05:00
parent 281864347e
commit a8cd22cbe1
51 changed files with 1830 additions and 469 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/thijooree/12-bml-qr-pay.md
+2 -76
View File
@@ -1,82 +1,8 @@
# BML QR Pay
Handles BML gateway QR payments — scanning a merchant QR code and completing the 3-step TOTP-authenticated payment flow.
> **This flow no longer lives in a dedicated fragment.** `BmlQrPayFragment.kt` still exists as a source file but is unreachable — no callers, no nav graph entry, no intent action routes here. The actual BML gateway QR flow runs inside `TransferFragment` via `TransferFragment.newInstanceFromBmlQr(qrUrl, fromAccountNumber)`. See [Transfer Flows — BML QR Merchant Payment Flow](20-transfer-flows.md).
---
## Fragment — `BmlQrPayFragment`
Opened via:
- Scanning a BML plain URL QR in `PayMvQrFragment`
- Scanning a combined Fahipay/PayMV QR that embeds a BML gateway URL
- The `OPEN_PAY_WITH_CARD` intent action
---
## Step 1 — Resolve QR
The fragment receives a BML gateway URL (e.g., `https://pay.bml.com.mv/app/<base64>`).
It calls the BML `payrequest` lookup API (see [QR Payment](../bmlapi/13-qr-payment.md)) to resolve the URL to merchant details:
- Merchant name (narrative1)
- Merchant address (narrative2, narrative3)
- Amount (`"0.00"` for static QRS, or preset amount for QRR)
- Currency
The resolved details are displayed on screen for the user to review before paying.
---
## Source Account Selection
A dropdown lists all BML accounts. The selected account's internal UUID (`internalId`) is used as `debitAccount` in the payment request.
---
## Amount Entry
- If the QR is a **static QRS** (amount `"0.00"`), the amount field is editable and required
- If the QR is a **dynamic QRR**, the amount is pre-filled and read-only
---
## Step 2 — TOTP Payment
The payment uses the standard 3-step BML TOTP flow:
### 2a — Initiate
POST to `/walletpayments/pay` with `action: "approve"`, `debitAccount`, `requestId` (the `trxn_hash`), `amount`, `currency`. Expected response: `code: 99` (OTP required).
> This step may be skipped if the gateway already indicates OTP is required.
### 2b — Request OTP Channel
Same POST with `channel: "token"` added. Expected response: `code: 22` (OTP generated and sent to the authenticator).
### 2c — Confirm with TOTP
The fragment presents an OTP input dialog. The user opens the [OTP Screen](12-otp-screen.md) or reads the TOTP from their authenticator app, then enters the 6-digit code.
Same POST with `channel: "token"` and `otp: "<code>"`. On success: `code: 0` with merchant and amount in `payload`.
---
## Success
On successful payment a confirmation card is shown:
- Merchant name
- Amount paid
- Currency
A **Done** button dismisses the fragment.
---
## Error Handling
Failed payments (`success: false`) display the `message` field from the API response. The user may retry with a fresh TOTP code.
The on-the-wire payment protocol is unchanged — see [BML QR Payment API](../bmlapi/13-qr-payment.md) for the 3-step TOTP flow (`approve` → `channel: token` → `otp`).
---