Building Payment Module for Web3 from scratch
Intro
This covers only a fraction of my time at Wert. Despite mistakes along the way, building the product from scratch paid off. After launch, we received strong partner feedback, achieved solid business results, and secured investor funding.
Objectives
Business objectives
- Develop an iFrame Payment Module for online wallets, exchanges, DeFi projects, and other services accepting crypto payments. Goals:
- Simplify payments for partners' end users
- Onboard people with no crypto experience
- Increase transaction volume and revenue
- Retain users across the ecosystem
- Build a Partner Account for tracking earnings, managing integration, and processing withdrawals
- Explore ways to improve the purchase flow across the crypto market and lay the groundwork for a broader ecosystem
Objectives
Design team
I embedded a small design team into the dev workflow, running on 2-week sprints:
- Design Sprints Ahead: Design stayed two sprints ahead of development. By the time coding started, decisions were locked and questions resolved
- Backlog Refinement: Joint sessions with designers, product owners, and devs before each sprint to make sure upcoming work was well-scoped
- Design Reviews: Regular critiques within every sprint cycle
- Support-Driven UX: I rotated UX designers into support periodically, creating a direct feedback loop from real user issues back into the product
- Kanban Board: Gave design its own visual workflow, separate from dev but tied to the same project context
- Stand-ups: Design team attended daily standups with devs
Objectives
Design objectives
The design team's primary job was to make the product tangible early, helping the business see its potential and catch problems before they became expensive.
I created design concepts as part of research. They weren't polished deliverables. They were tools for thinking: surfacing complexity, testing stakeholder reactions, and raising the right questions before committing to detailed prototyping.
What they revealed:
- The product should be white-label, fully customisable by each partner
- We should never compete with our own partners by selling crypto directly
- User profiles would show transactions from multiple partners, creating potential conflicts
- KYC integration was our biggest constraint, connected via iframe with limited control
Research
Market context
Our 2020 research confirmed patterns that held true for years. The industry only began caring about churn, retention, and UX after the market downturn. Before that, growth covered everything.
- Low Conversion: Projects lost users at onboarding. Newcomers bought crypto on Binance or Coinbase and never came back
- High Barriers: Targeting only existing crypto owners capped the addressable market
- Missed Revenue: Partners lost commissions to third-party gateways
Research
Competitive audit
With a UX designer, we analysed MoonPay, Simplex, Wyre, and fiat providers like Stripe. We built an extensive library of design patterns, UI references, and recorded purchase flows that stayed useful for years as we tracked market shifts.
What we found:
- Most competitors pulled users away to their own widget page
- They sold directly to users, competing with the partners they served
- None offered partners dashboards or analytics
- Most hid fees. Users only discovered the real cost mid-flow
- Purchase flows were unpredictable, with surprise KYC steps and unclear progress
- UX/UI quality was consistently poor
Research
Partner research
I interviewed five potential partners. The framing: "We're researching how {project type} handles Web 2.0 user onboarding."
The point of these interviews is to understand how the market actually works, not to pitch. You don't share ideas; you ask about their real experience.
What stood out:
- Most crypto startups shipped features over fixing UX. High bounce rates didn't matter while margins were good
- Some projects had no dedicated frontend team at all, which meant the quality bar for partner-side integration would be low
- NFT marketplaces leaned heavily on FOMO-driven marketing, often obscuring fees and commissions in the process
- Most partners would never touch the Payment Module after integration. Whatever shipped first was likely permanent
- UX would matter eventually, but at peak market, nobody was optimising for it yet
Research
User research
I tested with a small, diverse group, mostly people with no crypto background. Users were asked to buy crypto on a live marketplace with our Payment Module integrated. The sample was small, but the patterns were clear:
- "Add Crypto Wallet" remained a major obstacle. Users didn't understand why they needed one
- Placing "Buy with Card" next to "Buy with Crypto" dramatically improved completion rates
- Crypto-native users relied on habits and often missed new features entirely
- KYC was familiar but frustrating. The cheaper the item, the less patience users had for verification
Research
Identifying challenges
The deeper we looked at competitors and partners, the more complexity emerged, even from tools that appeared simple on the surface. Each challenge could have been its own project.
- User Engagement: Keep users on the partner's platform. Any redirect or disruption risked losing them
- Navigation Recovery: Bring users back to their purchase if they left mid-flow or were waiting for verification
- KYC Communication: Find the right moment and method to introduce KYC, including whether partners could set expectations before the flow
- Account Access: Let users reach their accounts when the module is only accessible through partners
- Integration Quality: Handle the reality of partner-side issues: duplicate CTAs, broken modals, no mobile support
- Fee Transparency: Decide how visible fees should be in a market driven by urgency and FOMO
- Iframe Flexibility: Support nested iframes for 3DS, KYC providers, and security challenges
- Step Count: Strike the right balance between thoroughness and speed in the purchase flow
- Flow Adaptability: Give partners the ability to respond to order statuses and adjust behaviour
Defining UX
UX approach
Before prototyping, I set design specifications grounded in the business requirements we'd agreed on.
- One Task Per Step. Crypto transactions carry real financial risk. Mistakes are expensive. The flow should:
- Reduce Cognitive Load: One task per screen, minimal information to parse
- Surface Errors Clearly: Make problems easy to spot and fix
- Stay Mobile-First: Simple screens translate better to small viewports
- Support Iteration: Isolated steps are easier to test and rearrange
- Pronounced Inputs. The module could end up in a narrow modal or a cramped corner of a page. Every control had to be unmissable
- Use Every Pixel. Side panels, bottom sheets, cards, tooltips, tabs. Show everything the user needs without forcing them to scroll inside the module
- Design for the Worst Case. Assume the partner's integration will be broken, the viewport will be wrong, and the iframe will be nested three levels deep
- Improve KYC from Within. Embedding third-party KYC imposed hard UX constraints. Test with real scenarios, not ideal ones
- Nothing Hidden. Don't hide actions behind conditions. If something is temporarily disabled, show it with a hint explaining why
Improving Metrics
Retention strategies
With the frontend team, we mapped every UX detail into a block diagram: post-KYC redirects, email flows, module reload states, edge cases. Then we turned it into high-fidelity prototypes with the UX/UI designer.
Working closely with devs was non-negotiable. Each crypto asset ran through a different payment processor, each with its own execution logic, error handling, and alerting. If the module couldn't respond correctly to every event, we'd lose users and revenue.
Good UX here meant covering nearly every corner case. Supported countries with unsupported states, card issues from obscure banks, different limits per asset based on regulation, users running the module on two partner sites simultaneously. Reviewing all integration docs and asking the right questions expanded our backlog significantly.
Improving Metrics
Boosting revenue
I had a few assumptions to validate before launch.
1st test: Crypto Payment Module
Assumption: Privacy-conscious users would reject phone number login, causing high abandonment.
Risk: More fraud, lower conversion.
Result: Users who objected to the phone number mostly dropped off during KYC anyway and paid with existing crypto instead. A small percentage, but subsequent data showed phone-based login cut fraud significantly.
2nd test: Smart Contract Payment Module
Assumption: Collecting card details before KYC increases commitment. Users who've already entered payment info are more likely to finish the flow.
Risk: Asking for card details too early could feel suspicious and hurt conversion.
Result: 80% of test participants were comfortable with the flow, largely because the communication was transparent throughout.
A/B Test: Post-launch, we ran two purchase flows for two NFT drops with an early partner: one with card entry before KYC, one reversed. The card-first flow delivered a 30%+ conversion rate increase.
Improving Metrics
Boosting sales
I saw an opportunity to support sales directly. I started making quick Figma prototypes showing the Payment Module integrated into each partner's actual product: their colours, their layout, their context.
The principles behind it:
- Respect the partner's product. Their UX and visual decisions are intentional; acknowledge them
- Explain the reasoning behind each design choice
- Always present at least two options: fast integration or the best possible outcome with customisation
The sales team needed to internalise this approach so they could carry it into every partner conversation. The impact was immediate. It became a permanent part of the workflow.
Improving Metrics
Optimising flow
For quick validation, I use standardised methods: SUS, SEQ, ASQ, QUIS. I structure test groups to offset cognitive biases, each starting with a different flow variant. Effective for settling internal debates with 10–15 participants.
The business wanted to merge two steps (bank details and personal info) into a single screen. I built two prototypes, ran a modified SUS test, and compared.
The test confirmed what we suspected: users preferred the flow with more steps. The separation gave them clarity and confidence.
Design
Visuals
Information was the hero. The design prioritised clarity, generous sizing, and practical layouts. Shrinking components even slightly would undermine the whole concept. The module had to look credible next to any partner's product, on any market.
Typography was central to that. We chose Aeonik: wider proportions than a typical Grotesk, lighter structure than a Geometric Sans. It gave us a clean balance between display presence and text readability.
Design
Transparency
I kept Purchase Details accessible at every step (except during KYC). User interviews confirmed it built trust from the very first interaction.
But we questioned whether fee details might slow NFT buyers down. Interviews with eight collectors made it clear: card-using buyers care about getting the item, not about fee breakdowns.
Key findings:
- Keep the NFT visible throughout the flow, following e-commerce logic and lifts conversion
- De-emphasising purchase details improves NFT conversion
- Built-in wallet creation for users without one would reduce friction
- Lighter KYC for NFT buyers (coordinated with compliance) could directly increase revenue
Design
Contributions
At a startup, you end up owning things outside your job description. If you care about the product, that's an opportunity.
We needed a booth for Metaverse Summit Paris 2022, but the project had no branding to speak of. I designed the booth from scratch, deliberately bright and clean to stand out from the dark cyberbank aesthetic everyone else was using.
I factored in the booth's footprint, sightlines from the main walkways, the venue lighting, and what the audience was likely to respond to.
Design
Design system & documentation
I wrote documentation for the team: design principles, decision frameworks, product schematics. The goal was to give designers enough structure to move fast without pulling me into every decision.
I set up the system architecture and let the team build on top of it.
Design
Partner account
The partner account was a significant workstream, built on additional interviews and partner questionnaires, and developed together with the frontend lead. The goal: make partner onboarding simple, module configuration intuitive, and analytics visible.
Details covered by NDA.
