How settlement works

This is the page to read first if you are evaluating Jorvi against anything else. Everything else is detail.

The usual model

Most gateways that accept digital assets work like a card processor. The payer pays the gateway, the gateway holds the funds, applies an exchange rate, deducts a fee, and the merchant withdraws a balance later.

flowchart LR
  PAYER["Payer"]
  PSP["Gateway balance account<br/>funds held here"]
  OUT["Payout<br/>T+0 / T+1 / manual"]
  MERCH["Merchant"]

  PAYER -->|"pays"| PSP
  PSP -->|"rate applied<br/>fee deducted"| OUT
  OUT -->|"withdrawal"| MERCH

  class PSP,OUT held

Funds rest in an account the merchant does not control.

Between the sale and the payout, the merchant’s money sits in someone else’s account. That is what custody means, and it is what brings settlement delay, counterparty risk, and licensing.

The Jorvi model

flowchart TB
  subgraph money[" "]
      direction LR
      PAYER["Payer<br/>own wallet"] -->|"approves once,<br/>sets a per-period cap"| AUTH["Capped, revocable<br/>authorization · on-chain"]
      AUTH ==>|"funds move once,<br/>payer to merchant"| MERCH["Merchant<br/>own wallet"]
  end
  Orch["Jorvi · orchestration<br/>no balance account, nothing to withdraw"]
  AUTH <-.->|"charge instruction<br/>settlement event"| Orch
  Orch -.->|"signed webhook + receipt"| MERCH

  class AUTH chainNode
  class Orch orch

One hop. Jorvi sends instructions and receives events, and is never in the money path.

Read the solid line. Funds go payer to merchant and touch nothing else. Jorvi attaches with dotted lines only: it submits charge instructions and receives settlement events.

There is no Jorvi balance account, so there is nothing to withdraw from.

What this means in practice

You are paid in what the payer paid. USDC on Solana arrives as USDC in your wallet. No conversion step, no rate applied by us.

There is no settlement delay to configure. The transfer is the settlement. There is no T+1, no minimum payout, no withdrawal request.

Refunds return to the original payer, and they work differently here than on a pooled rail. See Refunds below.

Your keys stay yours. Jorvi never asks for a private key or a seed phrase. A merchant proves ownership of a payout wallet by signing a challenge, which is a signature, not a transfer.

Refunds

Money moves back through the same shape it moved forward through, which means a refund is not what it is on a card network.

A refund is a second, independent transfer, not a reversal. An on-chain transfer is final once it settles, nothing undoes it. So a refund is a new payment in the opposite direction, from the merchant’s wallet back to the payer’s, authorised by the merchant.

flowchart LR
  P1["Payer"] ==>|"1 · charge"| M1["Merchant"]
  M2["Merchant"] ==>|"2 · refund, a separate transfer later"| P2["Payer"]

Two separate transfers, not one transfer reversed.

What is enforced

The amount can never exceed what was received. The engine rejects it rather than warning about it.
The destination is fixed to the original payer. It is not caller-supplied, so there is no parameter an attacker could set to route a refund somewhere else. A compromised backend cannot redirect refunds.
Refunds are tenant-isolated. One merchant cannot refund another merchant’s charge.
The network fee for the refund transfer is paid by the refunder. It is a real transaction and it costs what a transaction costs.

The trade-off, stated plainly

Because Jorvi never holds funds, a refund requires the merchant to still have them.

A gateway that pools settlement can reverse a refund out of a balance it controls, even after the merchant considers the money theirs. Jorvi has no such balance. If a merchant has already moved or spent the USDC, there is nothing for Jorvi to draw on and no mechanism for us to refund on their behalf.

This is the direct cost of the custody model, and it is worth being clear about rather than discovering later. The same property that means nobody can freeze, delay or take your settlement also means nobody can reach into your wallet to fund a refund you did not authorise.

Merchants who issue refunds regularly should keep a working balance, exactly as they would for any other outgoing payment.