Indonesia: QRIS, BI-FAST and wallets operate at different payment layers

Payment menus often place QRIS, BI-FAST, GoPay and bank transfer side by side. These are not four equivalent wallets. QRIS standardizes QR payments, BI-FAST is payment infrastructure, and a wallet app may provide the interface and funding source. Without that distinction, processing counts one customer journey as several independent methods and promises identical rules across different contracts.

The merchant’s map begins with questions: who issued the QR, which app scanned it, who acquired the payment, and which message confirms it on the recipient side? The next question is when proceeds become available in the required bank account. A photograph of a QR stand answers neither.

What QRIS standardizes, and what remains provider-specific

Bank Indonesia describes merchant-presented and customer-presented models. For static merchant QR, the customer generally enters the amount; for dynamic QR, the merchant sets it beforehand. Merchants join through an authorized PJP, with verification and merchant ID issuance. The checked page sets an IDR 10 million transaction ceiling and allows issuer aggregate limits. These boundaries do not guarantee approval of every purchase.

Dynamic QR reduces ambiguity in payment instructions. But “dynamic” alone promises neither a unique bank entry per order, automatic refunds nor round-the-clock exports. Ask the provider to demonstrate which creation identifiers return in confirmation, reporting and support inquiries. Missing links between those three locations create an exception-handling requirement.

Record the selected checkout method separately from the funding source actually used. Payment through a wallet app does not necessarily mean the merchant needs a wallet in that same app. Conversely, a familiar consumer brand does not establish access to every QR, balance type or cross-border scenario for that account. Test the specific route and its participants.

A documented example: QR created, money still outstanding

Midtrans’s QRIS creation response includes order_id, transaction_id, merchant_id, gross_amount, currency and transaction_status. pending means payment is outstanding; documented subsequent examples include settlement and expire. issuer and acquirer distinguish participants, while transaction_type identifies on-us or off-us. This is Midtrans’s vocabulary, not a universal PJP API. QRIS specification.

A recommended ledger design separates instruction creation, confirmed customer payment and settlement to the enterprise. Retain the original transaction_status alongside the internal state so support can explain discrepancies. A repeated notification should find an existing event rather than create revenue again. Browser redirects serve the customer interface; they should not be the sole basis for a financial entry.

Midtrans offers a separate current-status query. Its POS guide describes failed attempts inside Gojek that are not reported to the merchant as final failures: the transaction remains pending so the buyer can retry before expiry. The same guide does not promise online POS refunds by default and requires consultation. Read limitations like these before selling a “fully automated checkout.”

Why the word settlement can mislead

In a gateway’s documentation, settlement may identify successful customer payment within its transaction model. Finance still needs a separate answer: does that mean funds are withdrawable and have reached the enterprise bank account? A status label cannot replace settlement terms. Name internal fields by their business meaning while retaining provider status unchanged.

Consider an illustrative example: one hundred purchases totalling IDR 5 million are confirmed during the day. One bank transfer arrives the next day after agreed deductions. That transfer discharges the provider’s obligation to the merchant; it does not create one hundred new payments. Reconciliation must connect the batch, its constituent payments, gross value, fees, refunds and net amount. A difference should not automatically become “wallet rounding.”

BI-FAST is separate infrastructure with its own capabilities

Bank Indonesia’s FAQ describes account or proxy addressing, such as phone number or email, with each proxy linked to one account. It specifies an IDR 250 million per-transaction maximum, subject to lower participant limits. Beyond individual credit transfers, it lists progressively implemented bulk credit transfers, requests for payment and direct debits. A system-level feature does not prove availability at your servicing bank.

Merchants therefore need a separate capability map covering acceptance, disbursement, batches, payment requests and refunds. Outgoing transfers alone do not solve acceptance, and a QRIS transaction should not automatically be described as using BI-FAST. Instructions, reports and support procedures must follow the contracted arrangement rather than an appealing generic architecture slide.

Test limits and refunds across the complete cycle

Before launch, verify the authorized amount range, QR lifetime, expiry behavior and status-query mechanism. A refund requires a confirmed original payment, an allowable amount and the approved channel. If the API does not support refunds for that product, that is not permission to send money to an arbitrary number supplied in chat. Document the official procedure, timing, owner and completion evidence.

Load testing should measure more than approval rates. Count payments without final answers, the time needed to restore an order link and proceeds still owed to the merchant. These metrics reveal servicing cost more clearly than average latency for the attractive success case.

Gaming traffic: a national QR does not remove restrictions

Indonesian authorities officially describe blocking bank accounts associated with online gambling and disrupting its financial flows. Access to QRIS or BI-FAST cannot therefore be presented as approved domestic gambling acquiring. Processing must concern lawful, accepted activity; disguising the merchant as another business does not repair the transaction’s legal status.

The operational conclusion is to compare enforceable participant responsibilities rather than logos. Who owns the merchant ID, sends confirmation, owes the proceeds after payment and completes a refund? When those questions have contractual and technical answers, price and convenience can be evaluated. Without them, a low fee remains an incomplete proposition.