Designing crypto payments for the real world
WalletConnect Pay lets people pay directly with crypto — no card in between. The buyer pays in crypto; the merchant is settled in crypto or fiat. As the product designer, I shaped the whole payment experience, across every surface it touches.
Today, spending your crypto is a detour — or a risk
Say you hold crypto in your own wallet and want to pay with it. Today you can't just pay — you first have to send those funds to another app that issues a crypto card, then pay through the traditional card networks. At the point of payment your crypto is converted, and the card issuer takes a fee — so it isn't really a crypto payment; it's a card payment wearing a crypto skin.
And paying onchain directly isn't much better: it usually means copying a wallet address, copying the exact amount, and hoping you didn't fumble a single character — because if you do, the money is simply gone. It's slow, error-prone, and genuinely stressful for something that should feel routine.
Crypto-to-crypto, on rails that already exist
It's built on the WalletConnect Network, which already connects 700+ wallets and over 500 million users to onchain apps — so a huge slice of the ecosystem is compatible from day one.
The real design challenge was the number of paths. A wallet might have WalletConnect Pay built in, or only support the broader Network; and a buyer might tap to pay, scan the QR from their wallet, or scan it with their phone camera.
Take the two extremes. Natively, the payment happens inside the wallet they trust — tap, confirm, done in seconds. Without it, the QR routes them to the web to connect first, then pay. The trade-off: a universal web path that works everywhere but slower, or native integrations that are instant but need partner work. I did both, making native the reward for integrating — side by side, the speed gap sold itself.
Either way, the payoff is the same: no card, no issuer fee, no address to copy — just a few taps from the wallet you already hold.
Keeping every surface in sync
Payments touch everyone at once, so the work ran across three teams — wallet, payment terminal and merchant — and 12+ developers. Keeping every surface coherent, and easy for them to integrate and ship fast, was on me.
The catch: the same payment had to feel right on very different surfaces — a buyer paying from their own wallet, the merchant's point-of-sale terminal at the counter, and a partner embedding the flow into their product. So I designed both buyer paths — native, inside the wallet they already trust, and a web fallback for wallets without built-in support — and built demo apps that let partners feel, side by side, how much faster the native path is.
See the full flow in Figma — every possible path of an in-store payment, from start to finish.
What real users actually told me
To design for a behaviour this new, guessing wasn't an option. So I didn't test a mock-up — I built a real, working product and ran 10+ moderated usability tests on the live buyer experience.
Try the prototype — a mock-up of Nike.com paying with WalletConnect Pay.
Click the logo top-left to jump to any step.
I also interviewed 30+ crypto users across five continents, to understand how they actually pay, what they make of crypto cards, and where the friction — and the fear — really live.
The sharpest friction had nothing to do with paying. Some jurisdictions legally require personal details — name, date of birth — and for privacy-minded crypto users that was close to a dealbreaker, especially if it might be asked more than once. So much of the work went there: explaining plainly why it's needed and how it's handled — collected once, up front, never passed to the merchant — and making sure it never appears where a jurisdiction or merchant doesn't require it.
“As soon as I see this, I close it right away. It would throw me off.” 🇱🇹
“Fast and super convenient.” 🇻🇳
“Paying with crypto is very tough — but with WalletConnect it's like very easy, just two to three steps.” 🇺🇸
“Personally I don't mind. But if you're going to ask me again, I'll probably never use your app.” 🇮🇳
I don't stop at the handoff
On this project I contributed to the code — opening PRs to fix the details that drift between design and implementation, and sometimes reworking a behaviour directly instead of filing a ticket.
In practice, that meant adding toast notifications that hadn't shipped to production, pushing the UI to pixel-perfect polish, and layering in the micro-interactions that make a flow feel delightful rather than merely functional.
See some iterations in Figma — the explorations behind the final UI.
Proving the whole loop in the real world
The first real-world test was about proving the entire loop holds outside a demo. We ran it live for a week in a Lisbon coffee shop, wrapped in a “100% cashback” campaign so real strangers — not crypto-native testers — actually paid with crypto at the counter.
- Create a payment — a merchant can set up and issue a charge.
- Complete a payment — a buyer can pay and confirm it in seconds.
- Close the loop — every transaction reports back cleanly on the merchant, B2B side.
It held end to end. Two in three payments completed — first time, at the counter, on a payment method most people had never used, and on wallets and tokens we didn't control. Just as valuable were the ones that didn't complete: the reasons went straight into the next round of design.
It worked well enough that we took WalletConnect Pay from pilot to production.