Plin: Peru's digital wallet

What Plin has to be

Cash and card are still default for a lot of everyday spending in Peru, but P2P through a wallet had already trained people to expect free, instant transfers with nothing but a phone number. Plin is that promise across banks: affiliate your number to a soles account once, then send or charge with a contact, a number, or a QR. It lives inside each bank's app, not as a separate download, which means the design has to feel like a Scotiabank feature and like the same Plin people already know from friends on other banks.

Decision

Phone first, account detail never

The whole point of Plin is that you never type a CCI or account number for a friend. Destinations are a number you already have, a contact that resolved to an affiliated user, or a QR you scan. That sounds simple until error states show up: numbers that aren't affiliated, people with several banks (pick which Plin destination), Yape and other networks in the interoperability map, and daily / per-operation limits that have to be clear before someone commits, not after a decline. The UI treats those as first-class states, not edge cases.

Decision

Trust is the confirmation screen

Sending money to a phone number has one fear that dwarfs the rest: wrong person. The confirm step is where trust is won or lost: who receives, which bank, how much, and that it's free and immediate. We kept that screen calm and readable, with the recipient identity as the primary signal, limits and fees (or the absence of them) in plain language, and a hard stop before the debit. QR pay and QR charge had to rhyme with that same confirmation grammar so scanning a merchant didn't invent a second mental model.

How it's built

Inside the bank app, not a brochure

Plin isn't a marketing page you hand off once. I designed and refined the in-app flows against real constraints: affiliation, send, receive, show-my-QR, scan-to-pay, and the states when interoperability routes to another network. Work sat with channels and product so what left Figma matched what the app could ship: copy in Peruvian Spanish, accessibility on small screens, and the same quiet patterns we used elsewhere in Scotiabank's digital channels so Plin didn't look bolted on.

How it's built

Recargar transporte, designed end to end

One of the heavier Plin surfaces is topping up a Metropolitano card from the Scotiabank app: explain the activation wait before anyone commits money, capture the card number, pick a preset amount, confirm which account pays, and land on a receipt that is shareable. The prototypes below rebuild that walkthrough in code. The Work index only scatters the three primary beats (how it works, amount, constancia).

Decision

Ship the pattern the app already had

The first version had a launch date it had to make, so I did not design a new flow for it. Paying a service from the app was already a pattern people knew and the app already had built: an entry point, a form, a constancia. Recargar transporte took that shape and changed what it asks for. Reusing it bought two things at once, nothing new for a customer to learn and nothing new for the team to build, and it made the trade explicit: the MVP would be correct and unremarkable, and the interesting parts would have to be earned later with evidence rather than argued for up front.

Decision

Half of this flow happens off the phone

The constraint that shapes everything here is not ours: money leaves the account instantly, but the balance only reaches the card when you hold it against a validation module at a station, a few minutes later, and only within a limited window. So the design says it out loud before anyone commits money, in the onboarding, on the form, and on the receipt. The alternative is worse than a clunky screen. It is a person who paid, tapped their card, saw nothing, and now believes the bank took their money.

Then I tested it with six people

Six Plin customers who ride the Metropolitano, four tasks: find the entry point, work out how to top up a card, make sense of the message when a previous top up is still pending activation, and find the help centre. Three of the four went fine. People found the entry point without hunting for it, the step by step read clearly, and they understood on their own that this is a hybrid of app and station rather than something that failed halfway.

What the four tasks actually turned up

Finding it once is not the same as knowing where it lives: people also expected it where they pay their other services and inside their transactional account, so one correct entry point is not enough. The validation module has no settled name, and participants fell back on describing a person in a blue vest at the station, which means the app, the station and external comms are each teaching a different word for the same object. Everyone expected their card number to be remembered after the first top up, and typing it again read as the system forgetting them. Only participants who already used another wallet went looking for help at the top of the dashboard. And the real one: you have to activate the previous top up before you can make another, which participants read as paying for the wait twice, and as the reason a digital payment stops feeling digital.

Decision

What I recommended next

Cut the onboarding down to what the job needs, which is topping up, and move the rest to where it is asked for. Offer a way to top up again without having to activate first, because that single rule is what costs the feature its point. Settle on one name for the validation module and use it everywhere, in the app and outside it, then rewrite the activation copy against that name. Let people save the card so the second top up is shorter than the first. Past those four, the ones worth aiming at: more than one door into the feature, one consistent way to reach help wherever you are in the app, and a top up that finishes on the phone.

Honest outcome

Plin shipped in the Scotiabank app and is live for customers today, including the broader interoperability people now expect with Yape and other entities. Recargar transporte shipped as an MVP, and the research above is what the next version is being argued from. Adoption and volume numbers belong to the bank, so I'm not publishing them here, and neither are the parts of the brief that are the bank's business rather than mine. What I can defend is the design stance: phone or QR instead of bank details, confirmation as the trust surface, one mental model whether you're paying a friend or a merchant, and a feature whose weakest point I went and measured instead of defending.