BSI · QRIS Domestik Payment Flow
One scanner, two payment shapes. I mapped BSI Mobile's QRIS Domestik flow across Open Amount and Closed Amount transactions: scan, confirm, PIN, and every failure state in between, as one connected system instead of two separate features.
QRIS Domestik is BSI Mobile's scan-to-pay feature: the same code format used across banks and e-wallets, read through BSI's own camera and confirmed with BSI's own PIN. The flow splits into Closed Amount, where the nominal is already fixed, and Open Amount, where the customer enters it. This case study covers both paths end to end, from opening the camera to the confirmation email that closes the loop.
A QRIS code doesn't tell the user upfront whether the merchant fixed the amount or left it open. Closed Amount (a coffee shop with a set price) and Open Amount (a donation box, a street vendor) need different next steps right after the scan, but the entry point, the camera screen, looks identical either way.
Every branch off the main path (expired QR, insufficient balance, a transaction that fails mid-process, a code the scanner can't read) needed its own screen and its own way back, because there's no forgiving retry on a payment flow the way there is on, say, a form.
Open Amount and Closed Amount diverge as early as the confirmation step: one needs a numeric input for the nominal, the other only needs a confirm. Mapping both as parallel tracks from the scan screen, rather than one flow with a conditional branch buried in the middle, kept each path readable on its own.
QR tidak dikenali, kode kadaluarsa, saldo tidak mencukupi, transaksi gagal di sisi sistem, PIN salah: each of these needed to be a real screen with a real way forward, not a generic error toast. Error and info cards use a consistent color code (yellow for a recoverable notice, red for a hard failure) so the user can read severity before reading the text.
Tip only appears where it makes sense for the transaction type, and skipping it doesn't reset progress or send the user back a screen. Optional steps that don't feel optional are one of the more common ways a payment flow loses people right before the confirmation step.
Success and failure after PIN confirmation split into their own branches: one leading to a receipt with share/download actions and an email confirmation, the other back to a clear retry point. Neither branch leaves the user looking at a spinner with no sense of what happens next.
Both transaction types run through the same shape (Dashboard, Camera, Konfirmasi QR, Konfirmasi PIN) but branch at nearly every step. Closed Amount skips straight to confirming a fixed nominal; Open Amount adds a numeric input first. Both carry the same failure states, and success on either ends at a receipt with share and download actions, followed by an email confirmation.
Rather than building Open and Closed Amount as separate features, they share the same confirmation card, PIN screen, and receipt layout; only the input step differs. That kept the two paths consistent, and meant a fix to one benefited both.
Yellow notice cards for recoverable states and red cards for hard failures (insufficient balance, a failed transaction) let the user read urgency before reading the copy, a pattern reused across the error states rather than invented per screen.
Every path (Open or Closed Amount, with or without tip) converges on the same PIN confirmation step before a transaction can process. One checkpoint meant fewer places for a user to get stuck, and fewer surfaces to keep in sync.
A successful transaction doesn't end at the in-app receipt. It's followed by an email confirmation with the same details. For a payment flow, that second, durable record matters as much as the on-screen one.
Reflection
A payment flow is mostly the paths that don't succeed. The scan-and-confirm part is maybe a third of this map. Designing the other half with the same care is what determines whether people trust the feature the second time they use it.
