HomePenfoldConfirmoCableMaraStarcount
Confirmo
Confirmo
ConfirmoCrypto payments · Checkout · One flow for web and phone

Added $135M
on the surface.

A $750M-a-year payment service converting only 9%, running on a backend that couldn’t be touched. I redesigned the checkout on top of it and tripled success to 27%. Then I designed Confirmo’s first brand-new product in almost a decade.

$135Ma year in converted payments
3xsuccess, 9% to 27%
43%success in key markets
RolePrincipal Product Designer, the first and only designer
TimelineSep 2025 to Jul 2026
UsersBuyers at the checkout, merchants behind it

AI launch

A brand new product.

Subscriptions launched as Confirmo’s first new product in almost a decade, in partnership with Circle and Solana. Designed in under a month, it was built on a foundation of insights that made its flagship successful, and was a testing ground for new AI processes.

Prompted: from wireframe to high fidelity in days.

AI revolutionized the way I designed this product. Getting from the PRD to a first wireframe is the most important part of my work, and it takes a lot of back and forth. AI makes light work of it, and that speed freed tremendous bandwidth.

  • PRD: nothing missed, and nothing fundamental changed unnoticed.
  • Wireframe: a confident accounting of all our goals and objectives covered, freeing me to focus on tuning the human experience.
  • Stress tests: early testing, finding the edge cases on multiple wireframe options, and scoring them to inform my decisions.
  • Hi-fidelity: a styling that fit the product, locked in a few iterations.
  • Design system: a prompt away. I no longer had to choose between building it early and boxing the design in, or building it late and redoing the work.
  • Prototype: a lot more time fine-tuning the transitions and touch target affordances, a fundamental part of the experience.

Proto

Full flow: prompted.

1 / 8

Tap the screen, or the arrow, to move through the flow. The dashed steps are branches.

Shipped

The flagship, much improved.

Confirmo had never had a designer, and it showed. Built to an engineering spec and named after the technical outcome, Invoices trailed the industry average at 9% conversion.

The real problem was underneath: the flow was running backwards, and the backend was off limits due to crippling legacy code.

Before: 9% completed payments.
After: 43% in key markets, 27% globally.

Before
After

I couldn’t change anything, so I had to optimize everything.

Unable to change the foundations, I had to create on the surface. Dozens of small improvements added up, improving the flow as a whole. It was the same, but much better, and the results proved it: 43% in key markets, 27% globally.

v0.0

Initial audit and workshops.

The live product when I arrived lost 9 of every 10 payments. First, I mapped exactly what worked and what leaked.

  • Week 1: audited full product flows (20+ screens), and analytics.
  • Week 2: workshops with Sales, Support, and more.
  • Found: almost 80 individual problems with current flow.
  • Most requested: The Payments Back Button.
token
network
payment
Easy fix?Users are able to go back to first screen, but not back to second.

v1.0

The yellow wireframe.

Let’s start with the yellow elephant: this is a painted wireframe, never meant to ship. I used it to pitch 59 changes to the Product team, each tied to an issue from the audit, with metrics and support tickets where I had them.

Most were approved. The ones that touched the backend were not.


v1
v1
(v4 for reference)
RejectedI proposed handling this case in the flow. Users closing the window in frustration was very common.

End states. Partially approved

  • Processing: the screen gave no useful info and could idle without failing, leaving users stuck. I proposed a Cancel. It could not be built.
  • Payment success: what little success the flow had, it didn’t show it, leaving users frustrated even when everything worked. The backend allowed it, so I added a Success state at the end.

v0
v1
(v4 for reference)

Try again? Rejected

An expired payment had no way to retry, so I designed one. It was rejected. Like most edge cases, it hit a backend limit that was not up for negotiation.


v0
v1
(v4 for reference)
Payment detailsSeeing this prevented users from changing selection. Which in turn made Back impossible.

The Back Button. Rejected

The most requested fix was a back button on the payment screen. It could not be built.

Three quarters of a billion dollars a year ran through Confirmo’s Invoices. Rebuilding that backend mid-flight was a risk nobody would take, so it stayed off-limits.

Selecting the token and network triggered 6 events:

  • token/network selection
  • exchange rate locked
  • Invoice created
  • address linked to Invoice
  • user pushed to Payment screen
  • address exposed to user

Once the payment details were on screen, an Invoice had to exist to match them. Changing the selection after that could break the payment. I needed another way.

v2.0

The breadcrumbs.

I shipped this version to select markets as a live test, loaded with as many changes as it could carry. At 9% conversion, moving the needle mattered more than knowing what moved it. It moved: conversion almost doubled, to 16%.


Crumbled signal.

I tried breadcrumbs in place of a warning label. A label telling users they could not go back would shout at everyone, including those who never needed to.

The breadcrumbs showed progress and the steps to go. They failed: users got a new target to rage click, and crumb 2 was the favourite.

v3.0

Full rollout.

The test results were good, but our CEO wanted more of the brand in it. I disagreed, and compromised: the brand came back, the new mechanics stayed. It turned out well, because it separated the mechanics from the look.


tap: push
tap: push
stuck
tap: push
tap: hold
not stuck, go when you feel like it

Stop pushing.

I couldn’t give users a back button, so I gave them a forward button. The old flow moved on the moment a network was tapped, and trapped people there. Now the user decides when to move. It costs one more tap, and traps fewer.

v4.0

Craft, matured.

The full rollout held the test results: around 15% success, with spikes close to 20%. Sales could now reach more established clients, and those clients asked for one thing: branded and white-label options.

This iteration reversed the last one: aesthetics over mechanics. It also let me mature the design system, the first Confirmo ever had. It covers the full checkout, 20+ screens, and stayed small by reusing first and creating new only when needed.


AsleepAdds guidance.
WakingPreviews converted price.
LiveFull summary.
Drawer controlShow/hide full breakdown.

Matured.

One button now did three jobs. It guided the first steps. It absorbed the navigation push. And it kept the price in sight through the whole flow, with more detail as it became available, because users had been sending wrong amounts and wrong tokens.

The back button turned out to be impossible. But I still tried to fix it.Users still got stuck once they moved forward. But choosing when to move took away the helplessness and, more importantly, the fear of engaging with the product. That step stayed our biggest drop-off in the data. Support tickets about it fell sharply.

Branded.

I made branding self-serve: a client gives one primary colour and an optional accent, and colour maths derives the rest. It was the last thing I built before Confirmo went all in on AI, which would have made it much easier.


1-2 punchBottom timer starts muted grey, turning red at 2:59. The top warning is pushed at 1:29.
The yellow pillA relaxed cadence, calmly indicating the user’s progress.
Desktop affordanceThe background compensates for a larger distance to the user’s sight, making it easier to track when copying details to a phone.
Permanent, toned.Another warning vying for attention. A permanent warning should be seen, without shouting. Otherwise it’ll train the user to ignore it.

Paying attention.

I held colour back, because colour is what guides the eye.

The exception is the timers. Two of them, shouting from both ends of the screen, still feels like overkill. But in crypto a lost payment costs adoption, and nothing else stopped a user from paying an expired Invoice. I traded restraint for assurance.

v5.0

Common ground.

I had worked out a one-click payment version of Checkout, for when the backend resources were made available. The trick that makes it possible was to start with the wallet, rather than leaving it to the end. An insight that gave the Subscriptions work a great head start.

Connect and tap pay. That’s all.

01 Select Wallet
02 Pay. Done.

By handshaking the wallet first, the majority of payment failures are eliminated. We pre-select and serve only tokens the user holds, in the right network, and trigger the payment from inside the wallet. Guaranteeing no mismatched payments, no insufficient funds, and no payments simply not received. A much better user experience, wrapped with a bow on it.

  1. 01Pick token.
  2. 02Pick network.
  3. 03Connect wallet, or paste.
  4. 04Tap pay.

Shipped · 4 user steps

  1. 01Connect wallet.
  2. Reads balances.
  3. Preselects most used pair.
  4. Creates Invoice on confirm.
  5. Matches the payment.
  6. 02Tap pay.

Wallet first · 2 user steps

Wallet-first wouldn’t have needed a back button.

Checkout did its job. Better conversion won Confirmo bigger clients, and those clients integrate by API. Confirmo went API-only, and the checkout, and design with it, were no longer needed. Subscriptions launched on the same foundations: wallet first, and everything Checkout proved.

It couldn’t be done.
That’s no reason
not to fix it.