Support us on Product Hunt
We're on Product Hunt! Show your love, give us a boost, and help more designers discover better ways to grow.
Upvote on Product Hunt
Livin’ by Mandiri — Unified QRIS Flow
Redesign QRIS to prevent fraud and confusion between “Pay” and “Transfer.”
Background

Livin’ by Mandiri currently provides two separate QRIS features:

  • QRIS Pay → for merchant transactions (customer pays store).

  • QRIS Transfer → for peer-to-peer transfers (send to friends/family).

Both involve scanning a QR and moving money from the scanner to the QR owner. However, users often misunderstand the difference and assume scanning can also be used to receive funds.

Fraudsters exploit this confusion by asking victims to scan their QR codes under the pretense of refunds, bonuses, or money transfers. In reality, the victim ends up sending money to the fraudster.

Context
  • The separation of QRIS Pay vs QRIS Transfer adds redundancy and confusion.

  • Users don’t think in terms of “pay vs transfer” — they just want to scan and send.

  • Fraud arises because the app doesn’t clearly emphasize that scanning = sending money.

Business Objective

Unify QRIS flows in Livin’ by Mandiri to:

  1. Reduce QRIS-related fraud cases.

  2. Improve clarity of money flow (always sending, never receiving).

  3. Maintain the speed and trust users expect in merchant and peer-to-peer transactions.

Target User
  • Everyday Livin’ by Mandiri users scanning QR codes for personal transfers or shopping payments.

  • Users with mixed levels of financial literacy.

  • Both urban professionals using QRIS daily and casual users less familiar with QR conventions.

Core Problem

How might we redesign Livin’s QRIS experience into a single, unified flow that makes the direction of money flow explicit, removes redundant features, and prevents users from falling for ‘scan-to-receive’ scams?

Challenge

Design a unified QRIS scan flow that:

  • Eliminates the split between QRIS Pay and QRIS Transfer.

  • Detects and highlights whether the recipient is a merchant or an individual.

  • Reinforces with clear visual cues: You are sending money to [Recipient Name].

  • Keeps the flow smooth (≤3 taps for merchant checkout).

Constraints
  • Must fit into Livin’s brand identity (bright yellow, bold typography, simple icons).

  • Confirmation step must always show recipient type (Merchant vs Individual), name, and amount.

  • Must support static printed QR codes (offline merchants) and dynamic codes.

  • Should educate users subtly that scanning can never be used to receive money.


Grab the PDF version
Save a copy to review offline, print it out for focus time, or share it with friends — this PDF is made for flexible learning.
Join our official community
Get feedback, connect with designers, and grow together — all in a free, friendly space built for your UX journey.
Join the community
Partner with uixperiment
Looking to create a challenge for hiring or learning? Let's team up — we work with companies and campuses to shape meaningful UX experiences.
Start a collaboration