A payment gateway should not hold your money

Tue, 28 Jul 2026 00:00:00 GMT

Most payment gateways that accept digital assets work the way a card processor works. The payer pays the gateway. The gateway holds the funds, applies an exchange rate, deducts a fee, and credits a balance. Some time later the merchant requests a payout.

Every one of those steps is a choice, and most of them exist because of an assumption inherited from card rails: that somebody in the middle has to hold the money while the transaction clears.

On-chain, that assumption does not hold.

What the middle step actually costs

Holding merchant funds, even briefly, changes what a company is.

It brings licensing. It brings safeguarding requirements and segregated accounts. It brings counterparty risk, because the merchant’s balance is now an obligation rather than an asset they hold. It brings settlement delay, because a payout cycle has to exist. And it creates a pool worth attacking, which changes the entire security model.

It also creates smaller product problems that are easy to miss. Fast settlement and refunds pull against each other: money already swept out of a pool is harder to reverse, so several gateways restrict or disable refunds on their fastest settlement option. That is not a bug in their implementation. It is a consequence of the shape.

The shape without the middle step

A payer signs one authorization that sets a spending cap and binds the exact terms of what may be charged. A merchant charges against that authorization. Funds move once, from the payer’s wallet to the merchant’s wallet, and the transfer is the settlement.

Jorvi submits the charge instruction and receives the settlement event. It is never a destination.

flowchart TB
  subgraph money[" "]
      direction LR
      PAYER["Payer<br/>own wallet"] -->|"approves once,<br/>sets a per-period cap"| AUTH["Capped, revocable<br/>authorization"]
      AUTH ==>|"funds move once"| MERCH["Merchant<br/>own wallet"]
  end
  Orch["Jorvi<br/>no balance account"]
  AUTH <-.->|"instruction / event"| Orch

  class AUTH chainNode
  class Orch orch

Solid line is money. Dotted is instructions.

There is no third box in the middle of the solid line, and that is the entire design.

Two things follow from the shape rather than from a promise:

The cap is enforced on-chain, not by our backend. A compromised Jorvi server still cannot charge a payer more than they approved, because the limit does not live on our side.

Revoking the authorization makes future charges fail immediately, and it requires no cooperation from the merchant or from us. The payer does it directly.

Funds settle on-chain directly from payer to merchant. Jorvi never takes custody.

Why say it this precisely

There is a looser version of this claim that is easy to write and hard to defend. “We never touch your money” is the usual phrasing, and it falls apart the moment someone asks a careful question, because a payment system does orchestrate instructions and does submit transactions.

Custody is the word that is exactly true and legally meaningful. We hold no funds, at any point, for any duration. Everything else is orchestration, and orchestration is software.

That distinction is worth being pedantic about, because it is the whole difference between a payments company and a regulated financial institution.

Where this is

Jorvi is pre-launch. The engine, refunds, multi-tenancy, signed webhooks and hosted checkout are built and tested. Settlement runs against a simulated client today, and the live on-chain client swaps one adapter without touching anything above it.

More soon.

Jorvi | Blog

A payment gateway should not hold your money

What the middle step actually costs

The shape without the middle step

Why say it this precisely

Where this is