Centiiv Escrow
Led by Folasewa
Designing Trust into Cross-border Payment Escrow
Centiiv bridges fiat and stablecoin payments for global merchants and liquidity providers. I designed the escrow checkout flow —
the product's core trust mechanism — from zero to launch.
Role
Product Designer | UX Designer
Owned: IA strategy, UI Design, Design system, Engineering handoff
Company
Centiiv
Industry
Fintech | Payment
Outcomes
20M+
transaction volume
10% faster
dev integration via design system
3 rail
fiat, card, and stablecoin unified under one checkout surface
0 → 1
product built from scratch — no existing design system or patterns
THE PROBLEM
Global payments break without a neutral holding layer
In cross-border B2B payments, money moves between merchants, aggregators, and customers across different currencies and time zones. Without escrow, either party holds the risk during transfer — merchants fear non-delivery, customers fear non-receipt.
Existing solutions forced users to trust the platform blindly or rely on email follow-ups. Centiiv's escrow USP — hold funds until both sides confirm — needed a UI that made that trust tangible and frictionless across fiat, card, and stablecoin rails.
THE SOLUTION
Escrow flow (4 critical states)
Customer info + terms
Email capture + escrow T&C before payment. Sets legal context early.
Pay — 3 rails
Card, bank transfer (expiring virtual account), or stablecoin. One surface.
3.
Dispute filed
Funds lock. Merchant submits evidence. Structured, not chat-based.
4.
Propose settlement
Either party proposes terms. Other party accepts, rejects, or counters
KEY DESIGN SCREENS
Design Decisions Made
Personal info + escrow entry
Decision : collect only email at step 1. Reduces drop-off before payment. Escrow T&C surfaced here, not buried in footer.
Decision : all 3 rails on one screen — reduces abandonment from method confusion.
Card payment + order summary
Decision: escrow fee (0.6%) shown transparently in order summary. Prevents post-payment confusion and builds trust in the fee model.
Stablecoin rail
Decision: show wallet address + exact USDC amount with expiry — crypto users need precision
Bank transfer (escrow account)
Decision: expiring virtual account per transaction — eliminates misrouted payments
Merchant verification
Decision: binary CTA — verify OR dispute. No ambiguity. Tied to 24hr SLA.
Dispute transaction page
Decision: structured form (reason category + description + evidence upload) instead of open chat. Forces specificity, speeds resolution. Escrow lock notice shown prominently.
Create settlement proposal
Decision: separate proposal flow from chat. Merchant and customer can negotiate amounts without losing dispute history. Counter-proposal pattern modeled on legal ADR.
WHAT DIDN'T WORK
Key Trade-offs Made
I dropped
Persistent merchant bank account. Simpler to build but caused payment attribution failures in testing — unacceptable at this transaction volume.
I chose
Single expiring virtual bank account per transaction. Prevents mis-routing; adds backend complexity but removes a major support category.
I dropped
Inline dispute form on the same screen. Tested it — merchants skimmed past it. Separating confirm modal improved completion rate in usability sessions.
I chose
Structured dispute form with evidence upload. Non-negotiable for legal validity. Users initially wanted chat-only — usability tests showed chat led to ambiguous outcomes.
AI INTEGRATION
How I used AI in this project
Edge case mapping
Used Claude to stress-test the dispute state machine — caught a missing state (expired escrow, no merchant action) before dev handoff.
Microcopy
Generated 5 variants of the escrow expiry warning. Chose the one that tested clearest with non-crypto users in a quick 5-person session.
REFELECTIONS & LEARNINGS