Over half of payments in Japan are still made in cash. PayPay wanted the app to be the only thing you need, at the ATM too. I redesigned the ATM flow so people can withdraw and deposit cash with just their phone, across the phone and the ATM, each with very different rules.
I started at the ATM, testing the cardless flow myself. I noted where I hesitated, where instructions didn’t land, and where switching between phone and ATM felt disorienting. Then I worked with our CS team to group support tickets into failure types, and went through the funnel with a data analyst. The problems weren’t random. They clustered around three moments:
All three problems came from the same place: the app made people do work it should have done for them. So I set three rules before designing anything.
Before designing, I looked at how other apps handled cardless ATMs. Most used the same basic flow: scan a QR code, get a number, type it in. But almost none told people when to switch from the phone to the ATM. So we didn’t need a new flow. We needed better guidance at the handoff.
Setup came first, since 40% of users failed there. I broke it into clear steps with visible progress, so people always know where they are and what to do next.
The next screen, where you choose withdraw or deposit, sets up every step after it. I tested three versions with 8 people. At an ATM, often with people waiting behind them, users need to tell the options apart without reading. Icons on a vertical list did that best, and matched the rest of the app. The illustration only added noise.
Then the handoff, the moment we set out to fix. The app now tells people when to turn to the ATM, which closes the gap where 13% used to give up, and the last screen shows where to check the details. Pick a step to see each screen.
PayPay Balance and PayPay Bank sit in separate blocks.
Icons and fee tags show what people can do at a glance.
A line tells people what to scan.
If something goes wrong, a second button opens the guide.
The number to type on the ATM is the biggest thing on the screen. Everything else steps back.
From here, people follow the ATM: enter the number and PIN, pick withdraw or deposit, set the amount, then take or insert cash.
A title and an illustration tell people to turn to the ATM.
A button opens the transaction details, so people can check it worked.
The other half of the handoff is the ATM itself. Its screen came with strict rules from the vendor and from regulations: a few colors, fixed font sizes and fixed layout zones. There was no design system to lean on and no mobile patterns to borrow.
So hierarchy did the work. Someone glancing at the ATM mid-transaction should see their balance, the fee and the limit, and nothing else. I also gave fraud warnings a fixed spot on the screen, since scammers were tricking people into sharing their ATM QR code.
In beta with 10 to 20% of users, people did something we didn’t plan for: they started at the ATM and opened the app’s general scan button, so the app didn’t know which service they wanted.
Instead of asking them to change the habit, I worked with engineers to route them by default: no linked PayPay Bank account means e-money top-up, with no extra steps. I also added a short tutorial so people find the new flow first.
Each number maps back to where people got stuck. A simpler setup, where 40% used to fail, brought more people into the service. Clear guidance at the handoff and a clear last screen meant more transactions finished. And with less to figure out, a visit to the ATM got faster than using a card.
Ask “what if people don’t follow the flow?” before launch, not after. Two screens mean two contexts, each with its own mood and time pressure. And strict limits helped: every element on the ATM screen had to earn its place.
Next, I want the app to show the amount and status once the ATM confirms the transaction, so every withdrawal has a clear end, and to add haptic feedback when people enter the number.
