[Case 02]
Fixing the payments
checkout cliff
I replaced a legacy external payment link with a native Card and Pix checkout. For the first time the team could measure the payment funnel, and about 30% of users reached real payment intent.
[Industry]
Fintech
[My Role]
Product Designer
[Scope]
Web + App
Context
Stone was scaling self-onboarding for card machines across web, portal, and the app. Payment was the step that turned a sign-up into revenue, and it was also the main leak. People reached the pay screen and dropped, and the team had almost no visibility to fix it.
Problem
The pay step ran on a legacy external link from Pagar.me, built for other contexts and owned by another team. That created four issues:
It broke context and trust at the moment of pay (external page, different branding).
It asked again for data the customer had already filled.
Any change depended on another team, so iteration was slow.
It had weak tracking, so the drop-off was a black box.
Goal
My goal for the pay step was clear:
cut friction and raise payment intent;
give the team real tracking and faster iteration;
ship one embed that works across the three channels.
Discovery
I triangulated three inputs to confirm the friction and set guardrails for the new checkout:
Benchmark (Ton + market): focused methods (Card | Pix), Pix with QR + Copy, value clarity before pay, strong inline recovery.
Usability route (N=11): payment was where people hesitated most. Repeated fields, doubt about plan and price, slow loads, and a trust drop at the external handoff.
Flow audit: external ownership and low instrumentation made iteration slow and blind.
What I shipped
A one-page native checkout, built as a generic embedded component for web, portal, and app:
Card and Pix only, to keep the choice simple.
Totals and installments visible before pay.
A single CPF/CNPJ field that accepts both.
Inline errors with no modals and no lost data.
A funnel wired for Amplitude from day one.
Pix constraint (MVP)
Pix usually confirms in real time, but in the MVP the embedded flow could not detect the payment reliably. The team that owned payment status sat in another vertical, with no trigger at the end of the journey. So a customer could pay and land on a dead screen, with no confirmation and no next step. This was the customer's entry into Stone, so a dead end here was costly.
I solved it with a manual signal. The Pix end screen offered two buttons:
"I made the payment" sets the expectation and teaches where to track the status.
"I will pay later" brings the customer back to payment without redoing the whole journey.
The same screen had to serve two audiences. An app customer (already banking) is sent to track the plan inside the app. A website customer (not a client yet) is told to wait for the email, then create the account and download the app.
Results + Learnings
The old checkout had no metrics, so I estimated it from the usability route: 9 of 11 people dropped at payment, near 82%. The new checkout was instrumented in Amplitude, so I could measure the funnel for the first time:
5,819 users reached the payment screen.
1,759 engaged with a method or tapped pay, about 30% real intent.
Measured abandonment was about 70%.
The biggest result was structural. An invisible, externally-owned payment step became a first-party, measurable surface that the team could own and keep improving.
Learning: at the payment step, clarity and recoverability beat extra features. When real-time confirmation is missing, explicit expectations and user-controlled states protect the customer's trust.