[Case 04]
Fixing the payments
checkout cliff
I replaced a legacy external payment link with a native Card and Pix checkout, built as one embedded component for web, portal, and app. It shipped in one sprint and gave the team its first real view of the payment funnel.
[Industry]
Fintech
[My Role]
Product Designer
[Scope]
Web + App
[Timeline]
1 sprint
Context
Stone was scaling self-onboarding for card machines across web, portal, and app. Payment was the main leak: people reached the pay screen and dropped, and the team had no data to explain why.
Problem
The pay step ran on a legacy external link from Pagar.me, built for other contexts and owned by another team. Four things came out of that:
It broke context and trust at the moment of pay: external page, different branding.
It asked again for data the customer had already filled in.
Any change depended on another team, so iteration was slow.
It had weak tracking, so the drop-off was a black box.
The target was straightforward: bring the pay step in-house as one embedded component that works across all three channels, and instrument it from day one.
Discovery
I triangulated three inputs to set the guardrails:
Benchmark (Ton + market): confirmed focused method choice and strong inline recovery as the pattern to follow.
Usability route (N=11): payment was the main hesitation point, with a visible trust drop at the external handoff.
Flow audit: mapped every field already filled upstream, which is what let me cut the repeats.
What I shipped
A one-page native checkout, built as a generic embedded component for web, portal, and app, delivered in one sprint:
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.
Error handling
Each error surfaces at the moment we can detect it, and says only what's safe to say.
Designing around a
missing capability
Pix normally confirms instantly, but the embedded flow couldn't detect it. Payment status sat with another vertical, with no trigger at the end of the journey. So a customer could pay and land on a dead screen, on their first contact with Stone.
I solved it with a manual signal:
"I made the payment" sets the expectation and shows where to track the status.
"I will pay later" returns the customer to payment without redoing the journey.
The same screen served two audiences:
App customer (already banking): routed to Profile > My Plan to track or finish the Pix.
Website customer (not a client yet): no app to return to, so the screen guides them by email.
The trade-off. Splitting the two Pix paths into tabs would have cut the screen length, but it was heavier to build. Shipping in one sprint mattered more. That's the first thing I'd change if I ran it again.
APP • Already a Stone customer
Web • Not a customer yet
Results
The old flow had no instrumentation, so there's no clean before-and-after here. What I have is a first baseline.
From the usability route, 9 of 11 people dropped at the payment step (qualitative signal from N=11, not a funnel metric). That's what justified rebuilding it.
The new checkout was wired to Amplitude, so the funnel became visible for the first time:
5,819 users reached the payment screen
1,759 engaged with a method or tapped pay, about 30%
The remaining 70% left without interacting with the payment form
The result that mattered was structural: the payment step became a first-party, measurable surface the team could own and keep improving. Before this, the biggest leak in self-onboarding was invisible.
Learnings & next steps
When a system capability is missing, the interface has to carry the reassurance. We couldn't confirm the Pix, so the screen had to tell the customer what to expect and hand them a way to act on it themselves.
Two things I'd do next:
Fix the Pix "pay later" loop. On the website the customer left without the code and had to generate it again. I'd persist the code or link straight back to it. Same MVP limitation underneath: with no customer identification, we couldn't email it.
Put the funnel to work. Now that the step is measurable: time per step, errors by field, and method by channel, then fix the largest drop first.