Planned top up
Follow account or payment details
The user deliberately opens a bank, Virtual Account, or OTC route and completes the steps required by that channel.
Useful when the transaction is planned.Context
Top up became awkward when the person funding it was already standing next to you
AstraPay already supported Virtual Account, bank transfer, and OTC top ups. Those methods worked when people planned the transaction and had time to open another channel.
The gap was a more immediate situation. Someone needed AstraPay balance and another person nearby was ready to fund it. Looking up or sharing account details made that moment slower than it needed to be.
I turned that brief into the interaction model, worked through the transaction states with engineering, and carried the feature into a flow that could sit inside the existing Top Up area.
The useful question was not how to add another payment method. It was how to remove account-detail exchange from a top up between two people who were already together.
Problem framing
The existing top-up methods solved a different moment
I separated a planned cash-in from a nearby person-to-person cash-in before deciding on the interaction.
Nearby top up
Show something the payer can scan
The person funding the balance is already present. A generated QR removes the need to exchange an account identifier.
The interaction is built around proximity.Try the flowFrom concept to delivery
The interaction stayed small while the payment model became more explicit
The early concept focused on removing number entry. Engineering alignment then mapped what had to happen after the QR was shown.
Start with a QR instead of an account number
The concept adapted a familiar QRIS presentation pattern to cash-in. The AstraPay user presents the QR and the funding person scans it.
Interaction design
I reused a payment behavior people already knew
Merchant-presented QRIS already had a familiar rhythm. One side shows a QR, the other side scans and pays. QRIS Top Up reused that behavior while changing where the money ended up.
The user flow could therefore stay inside the existing Top Up area. Choose QRIS, set the amount, show the QR, wait for payment, then show the resolved state.
The interaction did not need a new navigation model. Most of the design work moved into what happened while the payment was waiting or when the result was not immediately clear.
Interactive prototype
Try the QRIS Top Up flow
Follow the main top-up path, then inspect the expiry and recovery states that sit outside the happy path.
TRY THE FLOW01 / 07
Choose QRISTop Up entryStart from the existing Top Up area and select QRIS as the cash-in method.
Transaction state model
The QR was simple. Resolving the payment state was not.
This state model shows when the interface can wait, confirm success, close an expired bill, or recheck an unresolved transaction.
bill
Create one billThe amount is tied to a single top-up transaction.
UI
Display QRThe funding person scans the generated QR.
pending
Wait for paymentThe UI stays pending while the bill is unresolved.
decision
What state returns?Bill status or callback updates the same transaction.
resolved
Paid and balance updatedSuccess appears only after payment resolves.
recovery
Status still unclearDo not ask the user to pay again yet.
closed
Bill expiredThe old QR is no longer reused.
status check
Recheck the same billRecovery checks the existing transaction first.
new transaction
Create a new QR if neededA fresh transaction starts after the old bill is closed.
Flow connections
- bill to qr
- qr to waiting
- waiting to state
- state to paid, paid
- state to unresolved, not resolved
- state to expired, expired
- unresolved to recheck
- recheck to state
- expired to newbill
The diagram stays at product-state level. It shows the transaction behavior needed by the experience without exposing implementation detail that is not necessary for the case.
Design specification
Four rules kept the payment state understandable and safe
These rules were used to translate backend transaction behavior into user-facing states.
Outcome
The new channel became a meaningful part of AstraPay cash-in
The strongest post-launch evidence is the channel contribution recorded in 2026.
Post-implementation
QRIS Top Up represented 9.3% of cash-in
The chart shows the documented channel share rather than an invented transaction funnel.
QRIS Top UpOther cash-in
2026 cash-in mix
TAKEAWAY
A feature designed for a specific nearby top-up moment grew into one of AstraPay's largest cash-in channels.
View data
| Label | QRIS Top Up | Other cash-in |
|---|---|---|
| 2026 cash-in mix | 9.3% | 90.7% |
The 9.3% QRIS Top Up share is measured. The 90.7% remainder is derived from that figure. This chart describes channel composition and does not claim incremental lift caused by the feature.
Reflection
The screen flow stayed short because the system states did more of the work
The useful design move was not adding more steps. It was applying an interaction people already understood to a different cash-in moment.
The part that needed more care was transaction truth. Waiting, success, expiry, and recovery had to remain understandable to users while staying aligned with the payment state underneath.