PaymentX is a two-sided B2B payments marketplace I designed end to end as the sole product designer: the research and IA, both apps (merchant and provider) in light, dark and mobile, and the design system underneath.

There was no obvious product to copy, so the work ran the whole length of the problem, from framing who it was for to architecting the system to shipping the tokens. This case study follows that arc.

PaymentX sits between two groups that mainstream processors do not serve well: businesses that need payment capacity, and providers who have their own gateway accounts with spare capacity to share. (Concretely, that often means high-risk merchants who hit limits with Stripe, PayPal or Adyen.)

A merchant browses providers, filters by gateway, limit, volume and rating, rents capacity, and allocates that provider's accounts across their own websites with hard spend caps and a live ledger. A provider lists capacity, targets specific merchants, sets terms, and watches it earn. Both sides share one source of truth for every transaction.

Stripped of the domain, it is exactly what serious B2B SaaS looks like: a vendor marketplace, an allocation tool and a billing dashboard sharing one spine. That is the lens I designed it through.

I was the sole product designer and owned the whole thing: the research and IA, the user flows for both sides, every screen across light, dark and mobile, the design system, and developer-ready specs. There was no PM handing me requirements and no existing UI to extend.

Being honest about the ending: it was a real client engagement that ended before launch, so I was never fully paid and there is no verified usage data. That shapes how I frame the research below. The personas and metrics are assumptions to validate, not findings, and I have labelled them that way rather than dressing them up as research I did not run.

A real client brief, but no users to test with yet. So I did the upfront thinking out loud: who it is for, what they feel, how they move, and how we would know it worked, framed honestly as assumptions to validate.

I started by writing the problem and the product answer in plain language, then turning them into four design goals the whole product had to serve. The constraints note is deliberate: it states up front that this was a real but unlaunched project, so there is no usage data.

Two personas, because it is a two-sided market: Alex the merchant, who needs capacity and fears losing it, and Paula the provider, who has spare capacity and guards her account standing. Each one is framed as an assumption derived from the brief, not field research.

I mapped both sides as emotion-led journeys, because the real design target here is a feeling: turning distrust into a sense of control. Every opportunity in the bottom row maps to a mechanism I went on to design.

Three flows carry the product. I drew the decision points and the loops explicitly, because the failure paths (a declined offer, an unverified DNS record, a cancelled rental) are where products usually fall apart. They were designed, not patched in later.

I closed the framing with the measurement plan: a North Star and the metrics that would tell us each design goal was landing. The instrumentation note keeps it honest. With no live data, these are targets to validate, not results.

Before any screen, the real problem was deciding what the product even was: which objects exist, how they connect, and which journeys run between them.

The core insight was that PaymentX is really four objects in a chain: a merchant rents capacity from a provider, that capacity is a set of gateway accounts, and those accounts get allocated to the merchant's websites. Almost every screen is a different view onto that one relationship.

Two decisions shaped the rest. I put allocation and limits on the website object rather than on the rental, because the website is the unit a merchant actually reasons about, and it kept the busiest, money-moving screen legible. And I modelled provider capacity as discrete gateway accounts rather than one pooled number, because per-account control and live spend tracking are the things both sides need to see.

The merchant's first job is to find the right provider, so the directory has to scan fast and the filter rail has to map to how merchants actually decide.

Each card leads with the decision signals: rating, supported gateways, max daily limit and payment delay. Trust is built into the scan with badges and verified stats, rather than buried in detail pages. Open a provider and the detail page has everything needed to commit.

Merchants are about to route real money through a stranger, so I treated trust as a property of the object model: the same provider surfaces evidence at every level, from a badge to a performance history to merchant reviews.

A rental is the live contract between a merchant and a provider. It moves through pending, accepted and declined, with both sides able to act, so the interesting work is the state machine, not the layout.

Once a rental is live, the merchant spreads those accounts across their websites, sets per-account caps, and watches the money move. This is the densest part of the product, and the part that most needed to stay calm.

Onboarding means touching DNS, which is exactly where non-technical users freeze. I broke it into three steps and made the technical one feel safe.

A marketplace is only as good as its supply side. The provider app mirrors the merchant's logic from the other direction: list capacity, target merchants, set terms, allocate, and watch it earn.

The most interesting provider decision was targeting. There is no open directory of merchants for a provider to browse, which would be a privacy problem. Instead the merchant shares a public key privately, and the provider pastes it into an offer to resolve and verify exactly who they are sending to. The mechanic protects merchants while keeping outreach intentional.

A product is only as finished as its edge states. I designed the confirmations, warnings, empty states and notifications as part of the work, on one consistent overlay system.

None of the above stays consistent by hand. Under the screens is a real design system: layered tokens, a component library, and a light, dark and mobile build driven by the same foundations.

The library is layered the way a real system should be: primitive colour ramps feed semantic light and dark tokens, which feed a component-token tier. That is what makes the same Button behave correctly in both themes without a second set of overrides.

Both apps were designed responsive, with their own bottom-nav chrome rather than a squeezed desktop layout.

The screens are the visible part, but the value was in the model underneath, and in designing both sides of it so the marketplace actually balances. Getting the objects and relationships right early is what made everything downstream coherent, and it is the skill I most want to be hired for. The same systems thinking travels to any dense B2B product.

The biggest lesson was commercial, not visual. The client disappeared before I was fully paid, and that taught me more about scoping, payment terms and vetting a client than any single design decision did. I will also be straight about the product itself. It helped high-risk merchants route around the limits mainstream processors impose. I am glad I took on the design problem, which was genuinely hard, and I have since moved away from that kind of work. The craft I would still put my name on.