Centiiv Escrow

Led by Folasewa

Designing Dispute Resolution System in Cross Border Payments When Transactions Go Wrong

Designing Dispute Resolution System in Cross Border Payments When Transactions Go Wrong

Centiiv is a platform that enables businesses to send and receive cross border payments using stablecoins such as USDC and USDT, alongside local fiat currencies like Naira.
The platform serves 4 key groups:
  • Merchants selling products and services
  • Customers making payments
  • Aggregators facilitating transactions between parties
  • Liquidity Providers handling currency conversion & settlement

Company

Company

Centiiv

Industry

Industry

Fintech | Payment | Web 3

Date

Date

2023-2025

MY ROLE

MY ROLE

My Role (as the Product Designer)
My Role (as the Product Designer)

I led the end to end design of the dispute resolution experience.

My responsibilities included:

  • Designing dispute creation and evidence submission flows

  • Collaborating with product managers and engineers on implementation requirements

  • Creating high fidelity designs and interaction patterns for the final experience

Outcomes
Outcomes
50k+
50k+

transaction volume

transaction volume

10% faster
10% faster

dev integration via design system

dev integration via design system

3 rail
3 rail

fiat, card, and stablecoin unified under one checkout surface

fiat, card, and stablecoin unified under one checkout surface

0 → 1
0 → 1

product built from scratch — no existing design system or patterns

product built from scratch — no existing design system or patterns

THE PROBLEM

THE PROBLEM

Cross Border Payments Need a Trusted Way to Resolve Disputes
Cross Border Payments Need a Trusted Way to Resolve Disputes

Centiiv connects merchants, aggregators, liquidity providers, and customers across borders using stablecoin and fiat payments. When transactions go wrong, there was no way to resolve them.


WHAT TYPICALLY HAPPENS

• Customer claims they never received the product or service

• Merchant insists delivery was completed as agreed

• Both parties are located in different countries with no clear path forward

• Funds freeze in escrow while support teams investigate through emails & chats

Centiiv connects merchants, aggregators, liquidity providers, and customers across borders using stablecoin and fiat payments. When transactions go wrong, there was no way to resolve them.


WHAT TYPICALLY HAPPENS

• Customer claims they never received the product or service

• Merchant insists delivery was completed as agreed

• Both parties are located in different countries with no clear path forward

• Funds freeze in escrow while support teams investigate through emails & chats

THE DATA

THE DATA

Cross Border Payments Need a Trusted Way to Resolve Disputes
Cross Border Payments Need a Trusted Way to Resolve Disputes

PwC found that consumers increasingly seek frictionless experiences and that concerns around security, privacy and trust remain major sources of friction in digital transactions.

PwC found that consumers increasingly seek frictionless experiences and that concerns around security, privacy and trust remain major sources of friction in digital transactions.

PwC - Sources of friction in digital transactions
Friction
0%
13%
26%
39%
52%
Security concerns
Unclear processes
Lack of transparency
Delayed resolution
Poor communication

Trust is not only a UX metric but It also directly affect retention & future transaction volume.

Trust is not only a UX metric but It also directly affect retention & future transaction volume.

THE INSIGHT

THE INSIGHT

Insights from the Data
Insights from the Data

• PwC's consumer research shows that trust and transparency strongly influence purchasing decisions, while friction and uncertainty reduce confidence in digital experiences.

  • In Centiiv's escrow model, disputes represented the highest risk moment for both buyers and sellers.

  • Designing a transparent resolution process became critical to maintaining trust and encouraging future transactions.

What was needed:

• Clear process for both sides to submit evidence & context

• Transparent communication channel visible to parties & admin

• Structured review & decision making

• Funds kept secure in escrow throughout the entire dispute process

What was needed:

• Clear process for both sides to submit evidence & context

• Transparent communication channel visible to parties & admin

• Structured review & decision making

• Funds kept secure in escrow throughout the entire dispute process

THE FLOW

Escrow flow (4 critical states)
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

• Collect only email at step 1 to reduce drop-off before payment. Escrow T&C surfaced here, not buried in footer.

• All 3 steps on one screen reduces abandonment from method confusion.

Card payment + order summary

Escrow fee shown transparently in order summary. Prevents post-payment confusion and builds trust in the fee model.

3 payment methods, 1 Payment gateway

• Show wallet address + exact USDC amount with expiry, crypto users need precision

• Shows expiring virtual account per transaction which eliminates misrouted payments

INTERACTION DESIGN

How It Works

Payment gateway (Customer's view)

• Entry point for customers is the payment link created by merchants

• Decision: structured form (reason category + description + evidence upload) instead of open chat forces specificity, speeds resolution.

• Decision: separate proposal flow from chat to enable a merchant and customer negotiate amounts without losing dispute history.

• Counter-proposal pattern modeled on legal ADR (Alternative Dispute Resolution).

Dispute transaction flow (Merchant's view)

• Required structured customer claims with evidence to reduce ambiguity and improve resolution speed.

• Centralized merchant customer communication within a dedicated dispute workspace for transparency and traceability.

• Separated settlement negotiations(Proposal) from dispute discussions(Chat) to preserve context while enabling flexible resolutions.

• Reserved admin intervention for unresolved cases, encouraging self resolution before escalation.

Create settlement proposal

WHAT DIDN'T WORK

Key Trade-offs Made
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
How I used AI in this project
Edge case mapping

I used Claude and lovable to stress-test the dispute states & caught a missing state (expired escrow, no merchant action) before dev handoff.

Microcopy

I generated 3 variants of the escrow expiry warning. Chose the one that tested clearest with non-crypto users in a quick 3-person session.

01
Research
I led the translation of the business goal to product requirement
Research
02
Iterations & Design
03
Testing
04
Design handoff
01
Research
I led the translation of the business goal to product requirement
Research
02
Iterations & Design
03
Testing
04
Design handoff
Outcomes
Outcomes

50k+

transaction volume

10% faster

dev integration via design system

3 rails

fiat, card, and stablecoin unified under one checkout surface

0 → 1

product built from scratch, no existing design system or patterns

REFELECTIONS & LEARNINGS

What I'd do differently

I would push earlier for quantitative data on dispute resolution time. I designed the 24hr Service Level Agreement (SLA) based on competitor research, but without baseline data from Centiiv's own merchant behavior, we were guessing. I would also add a progress indicator between payment submission and escrow confirmation; users in testing were unsure whether funds were "held" or "sent."

I would push earlier for quantitative data on dispute resolution time. I designed the 24hr Service Level Agreement (SLA) based on competitor research, but without baseline data from Centiiv's own merchant behavior, we were guessing. I would also add a progress indicator between payment submission and escrow confirmation; users in testing were unsure whether funds were "held" or "sent."

Create a free website with Framer, the website builder loved by startups, designers and agencies.