Skip to content
ProxyPay home
Apply for the pilot

Product

How a sale works at the register.

Eight steps, one of which is ProxyPay moving money. That step does not exist.

01

The sale, step by step

  1. The cashier rings the sale

    The POS produces a total. The cashier chooses stablecoin as the tender and the register app requests a payment request for that exact amount.

  2. ProxyPay issues a signed request

    The request carries the merchant name, the location, the receiving address, the network, the token mint, the amount as a whole number of base units, an expiry, and a random reference. It carries no customer identity, no basket, no receipt number.

  3. The customer’s wallet verifies it

    Any wallet implementing the open request protocol re-canonicalises the bytes, checks the signature against the published issuer key, checks the network and mint against its own configuration, and refuses anything that does not match exactly.

  4. The customer approves the payment

    Approval happens in the customer’s wallet, on the customer’s device, with the customer’s keys. The customer pays the network fee. Nothing ProxyPay does can approve or submit that transfer.

  5. ProxyPay observes the ledger

    The control plane watches the public chain for a confirmed transfer that matches the request reference, the mint, the exact amount and the merchant’s receiving address, at the finality the merchant configured.

  6. The register shows one state

    Waiting, paid, expired, or check with a manager. The state is the observation, not a guess: a request that has not been observed as paid is never shown as paid.

  7. The day reconciles

    Chain facts and POS facts are stored separately and matched. A POS fact never substitutes for chain evidence. The timeline is append-only: a re-org or a second signature adds a fact, it does not erase one.

  8. Close-out and sweeps are proposed

    At the end of the day ProxyPay prepares a close-out summary and, where policy allows, a sweep proposal. A manager reviews it and merchant-controlled keys approve it.

02

The flow of funds

There is one funds line, and ProxyPay is not on it.

Where ProxyPay sits relative to the flow of funds Funds move along one line: from the customer wallet to the merchant vault, then to the merchant's own exchange account, then to the merchant's own bank. ProxyPay sits above that line and connects to it only by dashed control lines — it issues the signed request, observes settlement on the public ledger, and prepares proposals the merchant approves with the merchant's own keys. No funds line touches ProxyPay. PROXYPAY CONTROL PLANE issues · observes · reconciles · proposes never holds funds or keys, never signs signed request observes settlement proposals for approval CUSTOMER WALLET customer-held keys MERCHANT VAULT merchant, multi-key EXCHANGE merchant account BANK merchant account customer pays the network fee here merchant approvals authorise every later hop SOLID LINE = FLOW OF FUNDS. IT NEVER ENTERS PROXYPAY. DASHED LINE = CONTROL AND EVIDENCE ONLY. EVERY ACCOUNT ON THE SOLID LINE BELONGS TO THE CUSTOMER OR THE MERCHANT.
ProxyPay sits above the rail, not on it. Every transfer is authorised by the customer's wallet or by the merchant's own multi-approval vault.
03

What the cashier can see

Five states, each of them a colour, an icon and a word. Staff are never asked to tell two states apart by colour alone.

Register states and the action each one requires
StateIndicatorWhat it meansWhat staff do
WaitingWaitingA request is live and has not yet been observed as paid.Keep the request on screen until it is paid or it expires.
PaidPaidA confirmed transfer matching this request was observed at the configured finality.Hand over the goods and print or send the receipt.
ExpiredExpiredThe request passed its expiry without an observed payment.Start a new request. Never accept a screenshot as proof.
Check with a managerCheck with a managerThe observation is ambiguous: a second signature, a partial or unexpected amount, or a re-org touching this request.Stop, call a manager, do not release goods or refund on the spot.
OfflineOfflineThe register cannot reach the control plane, so it cannot confirm anything.Do not issue new stablecoin requests. Use another tender.

Ambiguity is a state, not an error message

A second matching signature, late evidence, or a chain re-org does not silently resolve itself. The request goes to check with a manager and stays there until a named person records a decision. The full-screen designs for these states live in the register UI specification that ships with the pilot.

04

What ProxyPay deliberately does not do

Hold funds
ProxyPay software does not hold, receive or transmit funds. There is no ProxyPay account that merchant money passes through.
Hold keys
There is no customer signer and no merchant signer in ProxyPay. Approval keys belong to the customer and to the merchant.
Sign or submit a transfer
ProxyPay prepares and displays a proposal. Signing and submission happen on merchant-controlled systems.
Guarantee a payment
A request is a signed message asking for a payment. It is not a guarantee, an authorisation hold, or a promise that funds exist.
Carry customer data in a request
The request format prohibits customer identity, contact details, loyalty identifiers, item data, memos and receipt identifiers.