Accepting stablecoins without holding anyone’s money

A clear commercial idea, with no infrastructure under it

A founder-led payments business with a specific proposition: merchants take dollar-denominated stablecoin payments at the counter, settling straight into a wallet they control. A national franchise had agreed to pilot.

What did not exist was the platform. No gateway, no settlement engine, no dashboard, and no answer yet on which ledger, which stablecoins, or how any of it reaches a till running someone else’s software.

Four decisions that had to be right first

1. Custody, or not

   Holding merchant funds, even briefly, changes what the company is and what it must answer for.

2. Which rails, which assets

   Ledger and asset choice set settlement speed, cost per transaction and what a merchant is paid in.

3. The till, not the browser

   A payment missing from the point-of-sale and the end-of-day report cannot be reconciled.

4. A pilot with a date on it

   Merchants were agreed before the platform existed, so the build had to be production standard.

The brief was a payment product. The first question was whose money the system touches, because that answer decides the architecture and everything built on it.

Architecture signed off before a payment engine was written

Six months to a production pilot, in three two-month phases with a gate at the end of each. Custody and the ledger decision were settled first, so nothing built later had to be unpicked.

1. Discovery and foundation

   2 months

   Workflows mapped, asset strategy assessed, architecture signed off, merchant onboarding and wallet connection live.

2. Payments and settlement

   2 months

   Session lifecycle, QR request and payment page, ledger confirmation, settlement rules, reconciliation and reporting.

3. Retail fit and pilot launch

   2 months

   Point-of-sale compatibility, security and load testing, merchant acceptance testing, then production rollout.

What is being built

The split matters here. What a merchant touches is deliberately small, and the work that makes it non-custodial sits behind it where they never have to think about it.

In delivery, against gates the client can hold us to

Two-week sprints, a demonstration every month, and the board open to the client throughout. Each phase closes on a stated outcome rather than a percentage.

1. In delivery

   Architecture signed off, merchants onboarding

   Reached
2. Gate two

   A payment taken, settled and reconciled

   Not yet reached
3. Gate three

   Pilot merchants live in production

   Not yet reached

Hard question first

Custody was settled before a line of the payment engine existed. Everything else inherits it.

Security in the team

Our own application security engineer runs composition analysis, dynamic testing and API audits.

Named constraints

Till and terminal access depends on vendors. Where it is refused, the client gets a route, not silence.

Their repository

Code sits in the client’s own repository from day one, with specifications and knowledge transfer.