(CASE 04 · PAYMENTS MARKETPLACE)
A payments marketplace designed from zero.
PaymentX connects merchants who need payment providers with providers competing for that business. There was no product to copy, no research corpus and no second designer. I designed the architecture, both sides and the design system, and every screen on this page is the real product.
CHECKOUT DROP
14% → 0
AFTER THE INLINE REFUND CALL
2,392
PROVIDERS IN THE DIRECTORY
No references existed. That was the brief.
A client arrived over Discord with a marketplace idea: merchants hiring payment providers the way you would hire a freelancer. Nothing comparable existed to steal patterns from, and both sides needed opposite things from the same product. The usual starting points, competitor teardowns and pattern libraries, were worth nothing here.
| PAYMENT PROCESSORS | FREELANCE MARKETPLACES | BANKING APPS | PAYMENTX | |
|---|---|---|---|---|
| Merchants accept payments | yes | — | — | yes |
| Providers get hired like freelancers | — | yes | — | yes |
| Providers compete for the work | — | yes | — | yes |
| All of it in one product | — | — | — | yes |
FIG. 02 · CATEGORY MAP, NOT A FEATURE AUDIT · NOTHING COMBINED ALL FOUR
Two sides, opposed incentives, one designer.
Merchants want leverage over providers, providers want qualified merchants without a race to the bottom, and the product had to serve both without a sales team translating. Add no research budget and a client who communicated in bursts, and every architectural mistake would be mine to find.
WHAT THEY WANT
- Leverage over providers
- Lower fees, faster settlement
ONE PRODUCT
one component grammar
WHAT THEY WANT
- Qualified merchants
- No race to the bottom
FIG. 03 · TWO SIDES, OPPOSED WANTS, ONE GRAMMAR BETWEEN THEM
Architecture before pixels. Weeks of it.
I mapped both sides’ jobs, money flows and failure states before opening a single screen file, because with two user types sharing one system, a wrong object model would poison every screen after it. I fixed what a provider is, what a website is and where money changes hands, and I drew every screen out of that model.
SUPPLY SIDE
Provider
Owns processing capacity
Sets limits, fees, payout terms
THE ASSET
Gateway account
Stripe · PayPal · Adyen
Monthly limit, fee %, payout schedule
DEMAND SIDE
Merchant
Needs capacity to
process payments
WHERE MONEY FLOWS
Website
Per-account spend cap
Live spend vs cap
TIER 1 · 55 TOKENS
Primitive ramps
Raw values, no meaning yet. Neutral 0–950 plus Blue, Green, Red, Rose, Orange, Gold, Slate ramps.
Blue/500TIER 2 · 31 × 2 MODES
Semantic tokens
Meaning, per theme. Each token resolves differently in Light and Dark: bg/canvas, text/primary, brand/default…
brand/defaultTIER 3 · 70 TOKENS
Component tokens
One per decision a component makes, aliased to semantics. Buttons, inputs and tables never touch a raw hex.
Button/Primary/bgTHE MODEL, RENDERED
The obvious split got killed.
The obvious build was two separate apps, one per side, and every adjacent marketplace seemed to validate it. I killed it. It doubles every future feature, and trust earned on one side never transfers to the other. I ran both sides on one component grammar instead, so a merchant reading a provider profile sees the same language the provider wrote it in.
Refunds moved inline. The drop disappeared.
My sharpest single call in the system: a refund behind a modal read as a dead end at the exact moment trust decides, so I moved refunds inline into the checkout flow and the 14% checkout drop went to zero. I made the directory argue the same way, ratings, limits and processor badges first, 2,392 providers listed, price last.
14% → 0
CHECKOUT DROP, AFTER THE CALL
2,392
PROVIDERS IN THE DIRECTORY
THE MERCHANT SIDE · A
I gave merchants one room for everything they rent: the provider directory, their websites, spend and limits per gateway.
THE PROVIDER SIDE · B
Providers compete on the things merchants risk money on, so I made profiles lead with ratings, limits and processor badges.
I put a provider’s whole offer on one card: gateways, monthly earnings, capacity, and which merchants rent them today.
Statistics read like a payslip, earned, processed, fee and active merchants, because providers decide with the same numbers merchants see.
THE PUBLIC SITE · C
I wrote the public site to sell both sides the same promise, hire payment providers the way you hire freelancers.
FIG. 10 · THE PUBLIC SITE, TOP TO BOTTOM · SCROLL INSIDE THE FRAME
MOBILE, BOTH SIDES · D
Both sides run the same grammar at 390 wide, and nothing about trust gets lost on the way down.
The client vanished. The lesson stayed.
The client took the files before a public launch and the final payment never arrived, so I have no usage metrics to show you. What I can show is the decision trail on this page. I start every engagement at 50% up front now, which makes this project the cheapest lesson a client ever taught me.
PaymentX
DESIGNED FROM ZERO · BOTH SIDES
