Merchant and POS

A code on the counter. Any wallet. Done.

The customer scans what is already on your screen and pays from whatever wallet they brought. Your till knows which sale it was before they have put the phone away.

Start building Other situations

Request · available Verify · available Route · in development

Self contained

A payment code should not depend on a website staying up.

Hosted checkouts are smooth until the page is slow, the provider has an incident, or the shop's connection drops. A Payvol code is the request itself, so the only things that have to work are the customer's phone and the ledger.

The code carries the request, not a link to it

Everything the wallet needs is in the bytes on the screen. Nothing is fetched, so nothing can be unreachable at the moment of sale.

One code, whoever the customer banks with

Because the format is open and the vectors are public, a wallet either reads it correctly or fails its own tests. You are not asking customers to install anything.

The sale number stays inside your shop

The request carries an identifier. Your point of sale keeps that identifier next to its own sale number, locally, and nothing about what was bought or by whom goes near the ledger.

No terminal fleet, no provider account

There is no gateway to sign up for, no per transaction share to negotiate, and no third party holding a record of every sale you make. The counter and the ledger deal with each other directly.

How it works

Show, scan, settle.

Show

Your point of sale builds a request for the amount
It renders as a code on the screen or a printed slip
Nothing has been written to the ledger yet

Scan

The customer's wallet reads the bytes on the spot
It checks the destination and the asset
It shows what it established, and what it could not

Settle

The transfer runs on the network's own rails
Your node sees it arrive with the identifier
The till marks the sale, without anyone typing

Honest about the fit

Where this does not fit yet.

A counter is an unforgiving place to be early, so these matter more here than anywhere else.

Customers need a wallet that reads the format Until wallets ship support, this works for customers who brought the right one. That is a real limit at a busy counter.

There is no offline settlement The code works with your connection down; the payment still needs the customer's. A card machine degrades differently.

Refunds are a separate flow A refund is a new request pointing back at the old one, and the link between them is designed rather than built.

No terminal certification This is software reading a code, not a certified payment terminal. Where regulation demands one, it still does.

Route, which would let one code offer several ways to settle, is planned and not built. Today a request names one instrument.

Put one on a screen and scan it.

The app renders a real request as a code and reads it back from a phone camera.

Open the app Treasury requests