Case study ↓
Rethinking payment solutions with Stablecoins approach
Webapp
Reap is a technology company providing financial tools for modern businesses. Payments ran through Stripe and accepted fiat only, which locked out a fast-growing segment: web3-native companies with real spending needs but no easy way to use their crypto.
This project introduced stablecoin payments across Reap's core money flows, deposit, repayment, and payouts, turning crypto from a blocker into the wedge that opened Reap to a global client base beyond APAC.
Roles
Lead UX/UI design
Product research
Tools
Client:
Reap
"Web3 companies move at crypto speed. Their payments didn't."
Web3 clients held millions in stablecoins but paying with them was painfully slow. My challenge was making stablecoin payments as fast as the companies using them.
Define ↓
The big idea
With the rise of web3, we want to smoothen the process for them to pay their credit card bills or making direct payment through Reap Pay.
The payment system was previously limited to accepting fiat currency through Stripe. With the transition to a Web3 client, the project aims to implement crypto payouts to streamline and enhance their day-to-day operations. This new approach will provide greater flexibility and efficiency in handling transactions.
1.
Web3 clients needed to off-ramp crypto and cover large fiat business expenses without friction
2.
Every core payment touchpoint (deposits, repayment, Reap Pay) needed to accept crypto as a first-class input, not a workaround
User background & user stories
Who are our potential clients?
Digital-enabled businesses across the globe
Who are looking for a cheaper, faster, and centralized way to streamline and simplify their fiat expense processes in one place.
Next, Dive Deep to our users and what they need.
While all three shared the same core pain, we designed first for the crypto-native company holding stablecoins with limited fiat. They had the most frequent repayment need and the clearest path to value, and solving their flow would serve the other two by default.
What do we have right now?
Reap's core product was already mature: Reap Card, a corporate credit card that let business owners allocate cash, issue subsidiary cards to their team, and spin up virtual, physical, or one-time cards on demand.
Like any credit card, spending is settled through statement repayment. At the time, Reap offered exactly two ways to repay: autopay via EDDA, pulling directly from the client's bank account, or a manual bank transfer. Both fiat. Both assuming a funded bank account sitting behind the business.
Electronic Direct Debit Authorisation (eDDA)
A pull mechanism. Clients authorise Reap once, and each statement is debited automatically from their bank account. Zero effort, but zero flexibility: no fiat in the account on debit day means a failed repayment.
Direct Bank Transfer
A push mechanism. The client manually transfers the statement amount from their bank. Full control, but dependent on someone acting on time, and for crypto-native clients it sat at the end of a days-long off-ramp chain.
Both rails run entirely on fiat banking networks. However a client held their money, repayment could only happen through a funded bank account.
For businesses whose treasury lived in stablecoins, the rails weren't just inconvenient. They were built on an assumption that no longer matched how our clients operated.
What are the problems we are trying to resolve here?
To off-ramp crypto and repay their huge fiat business expenditure with no hassle
With adding Crypto capabilities, we would want to have a user be able to make an input payment using Crypto Repayment (crypto-format money)
Research ↓
Reviewing the product: where could crypto enter?
Right now (per the live page) it lists the three touchpoints: add money & withdraw, card repayment, Reap Pay. The upgrade is showing that you audited all three and chose where to start. Paste-ready framing:
Card Deposit
Funding the Reap account. Crypto here would mean holding client crypto balances, with the custody and regulatory weight that carries.
2. Repayment
Settling the monthly statement. The single most frequent, most painful moment for our target personas, and the one both existing rails (EDDA, bank transfer) served worst.
Reap Pay
Outbound payouts to suppliers. Valuable, but dependent on the receiving side accepting crypto.
So, there are 3 touch points that potentially our users can pay with cryptocurrency… 💭
Rather than bolt crypto onto a single flow, the goal was to make stablecoins a first-class currency across all three. A client should be able to deposit USDT, repay their statement with it, and pay a supplier from it, without the experience feeling like three different products stitched together.
That raised the real design challenge: three flows, three contexts, one mental model. Whatever patterns I designed for crypto (amounts, quotes, confirmation states, waiting states) had to work identically everywhere money moved.
Ask ↓
Biggest challenge: Understanding technical limitations
The product team chose Triple A, a licensed crypto payment gateway, as our provider. That decision set hard boundaries on everything I could design. And because stablecoins had to work across all three touchpoints, every API limitation didn't hit once. It hit three times, in three different contexts.
Rather than design first and discover dead ends later, I worked with our head engineer almost daily, mapping what the API actually allowed before drawing a single screen.
API doc understanding
In order to work out the payment solutions, the product team giving out an API solution which is through Triple A. In the big part of time in this project - I spend almost every day with head engineer together, try to maximise the flexibility that I can have on front-end.
Sketching out the technical flow
At the meantime, making sure I am not missing any small part of the API that will cause of bad user experiences (e.g. long loading time)
What the API dictated:
Quotes expire. Exchange rates locked for only a limited window per transaction. A finance manager who gets pulled into a meeting mid-payment comes back to a dead quote.
Exact amounts only. The client had to send precisely the quoted crypto amount. Underpay or overpay, and settlement couldn't complete automatically.
Thin status signals. The API exposed limited payment states, but on-chain confirmation can take minutes. Every waiting, pending, and failure moment the user feels had to be designed from a small set of signals.
Fixed tokens and networks. We accepted only what Triple A supported, and crypto sent on the wrong network is effectively lost. The UI had to make the right choice the only easy choice
Ideas ↓
Brainstorm sessions 🌪️🌪️🌪️
Facilitate a productive brainstorming session with colleagues on the idea of implementing a crypto payment solution, it is essential to provide them with relevant information and clear objectives
Where should the money live?
I ran a cross-functional session with product and engineering to answer the question underneath all three touchpoints: when a client pays in stablecoins, what actually happens to the funds?
Two models emerged:
Option A: pass-through conversion.
Every payment converts individually through the gateway at the moment of transaction. Simple to reason about, nothing to hold, but every single payment inherits the full weight of crypto rails: a quote window, conversion fees, on-chain confirmation delays. ⚠️
A client repaying a statement would wait on blockchain confirmation before their card was even cleared.
Option B: a treasury.
Reap holds funds in a managed treasury. Client payments land there, and conversion happens on our side, decoupled from the client's moment of payment.
I pushed for a different model: a treasury.
It moved the crypto complexity from the client's experience into our operations, exactly where it belonged. Clients get a payment that feels instant and final; the waiting, conversion, and volatility management happen behind the curtain. ⚠️
It also meant one conversion pipeline serving all three touchpoints, instead of three flows each negotiating with the blockchain in real time.
The trade we accepted
Holding funds meant taking on treasury operations and a heavier compliance surface. We took that on deliberately, because the alternative pushed that weight onto every client instead.
With the model agreed, I moved into designing the flows, knowing every screen had to survive expired quotes, on-chain waits, and finance teams who think in fiat.
Outcome ↓
From model to screens
With the treasury agreed, I designed the flows across all three touchpoints, one pattern system applied everywhere money moves. The rule I held throughout: crypto complexity is our job, not the client's.
Sub-block: Designing for the messy parts
Crypto payments fail in ways fiat never does, and most of the design work lived in those moments:
No wallet? Not the client's problem. If a client had no wallet address for a chosen network, we created one silently in the backend. No setup step, no wallet education, no interruption. The flow simply continues.
Irreversibility, handled in the interface. On-chain, a wrong transfer is gone forever. Every deposit screen carries a hard guardrail: only USDT/USDC to this address, with a fresh wallet address generated per payment so funds are never sent to a stale destination.
Failure is a designed state, not a dead end. Wallet generation can fail, deposit information can fail to load. Each failure has its own screen with a clear recovery path back to the dashboard, never a spinner that hangs o
Even zero is designed. A multi-currency treasury has awkward edges: wallets with no funds, currencies a client never uses. We defined explicit display logic for every empty state, so the dashboard reads clean whether a client holds two currencies or none.
Card deposit
Increasing a credit limit works identically whether the client deposits fiat or crypto. Same modal, same steps, one extra choice. Crypto as an equal rail, not a special feature.
Repayment: adding cryptocurrency as an option
The repayment flow reuses the same deposit pattern. A finance manager who has funded the account once already knows how to settle a statement, which was the entire point of one pattern system.
Instant crypto:
repayment straight from any external wallet.
No treasury balance? Clients settle directly: choose the amount, and the flow translates it before anything moves, HKD 24,589 due becomes USDC/USDT 3,136.77 to send, at a stated rate with the 2% transaction fee declared upfront. Then the familiar deposit grammar takes over: network, generated address, QR, and the same guardrail that protects every on-chain moment in the product. The transfer settles the statement without fiat ever entering the picture.
From treasury:
repayment without the blockchain.
Clients who keep funds in their Reap wallet settle their statement in three choices: outstanding balance, minimum payment, or a custom amount, with their available deposit (USDT 4,589) shown upfront so there's never a guess about affordability. Because the funds already sit inside Reap, nothing touches the chain: no network selection, no address, no confirmation wait. Pick an amount, confirm, done. For a finance manager, this is repayment reduced to its minimum: the crypto part already happened at deposit.
Reap Pay payouts through stablecoins
Outbound payments draw on the same treasury and the same send-funds pattern. Select a network, get a dedicated wallet, transfer. By the third touchpoint, nothing needs explaining.
Treasury dashboard
The treasury is the layer that makes all three flows possible: dedicated wallets per function, multi-currency balances, and one place where a finance team sees exactly where their money lives.
Funding the treasury:
Three steps, zero crypto expertise required
Clients top up their treasury by sending stablecoins from their own wallet, into the General wallet for flexible use, or directly into a dedicated Reap Card or Reap Pay wallet when funds have a purpose. The flow asks for exactly one decision, which network, and handles the rest: a dedicated wallet address is generated fresh for the payment, presented as a QR for mobile wallets and a copyable address for desktop ones. The guardrail does the protecting: only USDC to this address, refreshed per payment, because on-chain there is no undo. Send from your wallet, return to the dashboard. That's the entire flow.
One treasury, money where you need it.
Once funds are in, clients redistribute them freely between wallets: from Card deposit into Reap Pay to fund a supplier payout in another currency, into Reap Card for day-to-day business expenses, or into General to stay flexible. The flow is deliberately banal: pick a source, pick a destination, enter an amount, confirm. No networks, no addresses, no gas fees, no waiting, because moving between your own treasury wallets is an internal transfer, not an on-chain transaction. Crypto got the money in; from there, it behaves like money.
🌟 Impacts of the solution
46%
Transaction rate increase in 1 month
21%
Web2 customers start to use stablecoins for first time
$2 billions
Stablecoin payments funded in 1 year
Enabling users to utilize stablecoins as a funding source for their corporate cards and various payment methods marked a significant shift in the company’s business strategy. Originally, the product’s primary audience consisted of APAC businesses that had been the focus since the early stages. However, the introduction of crypto solutions has opened the door to a broader global market, creating new opportunities and expanding the company’s reach.
⚡️ Learnings from this project
Constraints are a brief, not a blocker.
The Triple A API dictated what was possible. Mapping it exhaustively with engineering before designing meant every screen I drew could actually ship.
The best crypto UX hides the crypto
Every decision that mattered, the treasury, silent wallet creation, designed failure states, moved complexity away from the client. The measure of success was clients forgetting blockchain was involved at all.
See other case studies ↓
