Everyone's wallet
Cash still matters in Peru, but its share fell sharply as e-payments took over daily commerce, led by Yape and other e-wallets.
Work brief · 96107 min read
Fighting fraudulent payments
My app verifies that a Yape payment on a customer's screen is real.
Fintech
Fraud Prevention
Front-end
App Security
Mobile
Roles — Product designer · Front-end developer · Tester
Duration — Under a week · July 2026
Scope — Research → UX design → development → security → testing
A queue at a market stall: a customer shows a screenshot saying the payment went through, and the merchant has seconds to accept. Every field on the confirmation can be faked except the operation number, and the app checks it, here against mock records rather than a live bank, before the goods leave. A secure keypad with randomized digits, double-click prevention and private-data protection guard the interface. Researched, designed and built in under a week, in a stack I had never used.
TABLE OF CONTENTS
Act 00 · Context
The app Peru pays with.
Success and new fraud.
Yape began as a way to send money to a phone number. Today much of Peru pays with it daily.
It stopped being a transfer app long ago: credit, bill payments, a marketplace and remittances. A super app.
Its success created a new fraud: if everyone trusts the confirmation screen, fake the screen.
The counter economy
A market stall or bodega: the customer shows a confirmation, the queue waits, and the merchant has seconds to decide.
The stakes
The most exposed are small merchants and independent workers, for whom one fake payment can erase a day's earnings.
Act 01 · Problem
Easy to fake.
A screenshot is not a payment.
What you see
A payment confirmation, on a phone, held up at your counter —
What it is
an image, where every field is text that can be forged.
The fake reproduces exactly what you are looking at. That is why staring harder fails.
Peru's wallet boom outran its trust infrastructure, and the fake receipt is the hole it left.
A security code shipped to close it. The public guidance still does not mention the code.
I benchmarked three innovation-center banks in markets like Peru: Nubank, Nequi and Attijariwafa. All three treat verifiable payment trust as core product, so the gap is real. Merchant finance tools were a crowded space and onboarding drifts into regulated identity; payment trust won because it is urgent and solvable in front-end alone.
Act 02 · Scope
The trust gap.
Not the whole app.
With the exact design system I could build or redesign the whole app, but that isn't the purpose. This case solves one real fraud problem with front-end alone, with every framework, security and code decision understood and backed by me.
The gap I mapped
I read the front-end requirements Peru's largest bank hires for, mapped them against my skills and aimed this project at the gap.
The jump to apps
I left the vanilla web this site is built on and entered frameworks and app development, to test first-hand what I can build.
One problem, done fully
Reshaping a successful super app takes years. I chose to learn what solving one banking problem with front-end really takes.
Act 03 · Solution
Paid means paid.
How it helps high-traffic shops.
-
Illustration
At the counter
Know it is paid before handing the order
Trust & Verify confirms if the transfer occurred by checking the bank operation rather than a screenshot, protecting your store merchandise.
Open the running application -
Illustration
Fake screenshots
See what does not match and say why
The app highlights the exact discrepancy against the customer's payment receipt, allowing you to explain calmly why the purchase cannot proceed.
Open the running application -
Illustration
With a busy queue
Type securely in front of everyone
A randomized numeric keypad makes your keystrokes hard to follow, and customer names and phone numbers stay masked at every checkout.
Open the running application
01 / 03
Act 04 · Architecture
Working mechanism.
Integrated technical stack.
React — one source of truth for every screen
React draws every screen from the app's data, never the reverse, so what the merchant sees always matches what the app knows. In a trust tool, that guarantee is the product.
The one failure a verification tool can't survive is a stale screen showing "verified" for a cancelled check. In React the interface is a function of state, so a verdict can't tear under rapid updates. Vanilla would mean hand-wiring every listener, and this build's one real defect was a missed listener. Angular would work, but adds a large framework to a single-job build.
TypeScript — code that checks itself
TypeScript is JavaScript with a strict proofreader: it catches whole classes of errors before the code runs. In a tool that tells a merchant to trust a payment, that net isn't optional.
Every receipt field, verdict state, and API response has a declared shape, so a malformed record cannot silently flow into a verdict. The compiler runs as a CI gate on every push — the same discipline production banking code expects: typed contracts, automated checks, continuous integration.
Security — the film set
The security layer works like a film set: the heavy bank infrastructure is openly staged scenery, while every lock the merchant touches is real, working and tested.
The scenery shows the sector's security vocabulary (TLS 1.2, RSA-2048 key pairs, mutual certificate authentication, adaptive risk scoring) on fabricated material, badged SIMULATED throughout. The lock is what the merchant touches: an in-app keypad no third-party keyboard can read, shuffling digits, an execution lock, a blocking overlay and privacy masking.
Six scenarios — rigorous tests
Before trusting the build, I wrote a six-scenario test protocol from the case research: does it tell a fake from a real payment, and does it avoid misfiring under pressure?
1: a forged amount on a real operation number is caught and named. 2: an unreadable security code never counts as a mismatch. 3: a double-tap or mid-flight cancel never fires the check twice. 4: the action stays inert until its preconditions hold. 5: the busy overlay truly blocks the page. 6: privacy masking never leaks a full name or number.
Only the operation number comes from the bank; the rest can be faked.
For more, access the repository.
Act 05 · Schedule
Built in one week.
From research to development.
This Gantt chart lays out the build as five phases, reconstructed from its plan and completion record. Each row is one phase, read from left to right on an axis of planned hours, not calendar dates: the bar's length is the hours planned, and the dashed lines show what had to finish first. Open a phase to see its tasks, each with its story points and hours.
Dependencies: 01 Project setup leads to 02 Verification flow. 02 Verification flow leads to 03 Session and data flow. 03 Session and data flow leads to 04 Interface security. 04 Interface security leads to 05 Test and delivery. The singleton session task in 03 Session and data flow leads to the execution-lock fix in 05 Test and delivery.
Story Points (SP). A relative measure of a task's effort against the others, not a unit of time. This build was not run as a formal sprint.
- 01Project setup8 h planned
- 02Verification flow16 h planned
- 03Session and data flow15 h planned
- 04Interface security13 h planned
- 05Test and delivery14 h planned · Live 15 Jul 2026
Act 06 · Impact
Technical rigor.
Figures and implications.
The figures
- 45/4545/45all passingAssertions passingAcross six fraud scenarios. None waived.
- 55TypecheckTestsBuildDriftPathsCI gates per pushTypecheck, tests, build, drift and paths.
- <7<7one weekDays, research to deployed appFirst app build, first use of this stack.
What it means
The fastest artifact in this portfolio is also its most technical. That inversion is the finding.
What transfers. Any stack a client's problem requires is now within reach, with every decision owned and every claim checkable.
Method. Figures counted from the repository and the recorded test run (Node 24.18.0, Vitest 3.2.7, TypeScript 5.9.3, 15 Jul 2026), verifiable at the linked source. Staged security demonstrations are described, and badged, in The Architecture above.
Front-end only. No backend services, by constraint; 3 API endpoints consumed, with real request handling against mock fixtures.
In the client. Security controls run in the browser, among them a secure keypad, shuffled digits, an execution lock, a blocking overlay and privacy masking.
Act 07 · Reflection
Key takeaways.
Lessons learned.
The ceilingTerritory I thought was closed
I thought app development belonged to career developers. This build broke that ceiling: I now work the technical side while owning every strategic call, starting with the stack.
The methodDirected, not typed
My fastest portfolio artifact yet, without typing a line of code and without vibe-coding shortcuts. Every framework, security and code decision was directed, reviewed and understood by me.
The toolsKnowing what each tool is for
Gemini compiled fifteen app screenshots into one master flow file. Claude Code ran deployment prompts I wrote as reusable skills, each run directed, reviewed and mine.
The choiceOne problem, not a redesign
Banking is too wide to enter everywhere at once. A short study aimed at one real fraud mechanism, seen purely through front-end eyes, not as UX, redesign or innovation theatre.
Disclosure notes
An independent case study. Not affiliated with, endorsed by, or connected to Yape or BCP. Built against fabricated fixtures. No real payment, account, or ledger is involved.
Next steps
Keep exploring
Read the case closest to yours.
-
Illustration
AIRPORT
Paying a fee Lima's airport had never charged.
TUUA Transfer: the web payment flow I designed for international transfer passengers at Jorge Chávez. Handed over in 2025.
Access Brief -
Illustration
SPORTS
Boosting media teams at the FIFA World Cup 2026.
AccreditaPass: a Blazor and .NET app that tracks the whole journey of journalists across 3 countries and 16 stadiums. Built in five weeks.
Access Brief -
Illustration
SOFTWARE
How I built this website with no coding degree.
DesignOps System: from a single page to a bilingual multi-page site in Vanilla HTML, CSS and JavaScript code. Built in five months.
Access Brief
01 / 03