Crypto payment requests that are documents, not messages

A public page, no login, that names who is requesting payment, the amount and asset due, the due date, the itemised reason for the charge, and the payment instructions: asset, network, receiving address, a copy button and a QR code.

Because it is a page rather than a message, it forwards cleanly to whoever releases funds — which in most organisations is not the person you have been talking to. If they need a file instead, the PDF carries the same content line for line.

To be direct about the product: VegaPal has three document types — quotation, proforma invoice and tax invoice. A payment request is not a fourth. What you create is a real invoice, and the shareable payment page is what makes it feel like a request.

That mapping is deliberate rather than a limitation. A numbered document with dates and line items is what a finance team can process and what your own records need; a bare request is neither.

Nothing passes through VegaPal. There is no checkout, no escrow, no custody, no wallet connection and no chain monitoring. The page publishes the instructions you saved and the client sends funds from their wallet to yours.

That is why no percentage is taken from what you receive, and why confirming payment is a step you perform rather than something the software claims to know. You look at your wallet, then you set the status.

Pike & Vale, a small legal consultancy, is owed 1,800 USDT for a contract review with no prior paperwork. Instead of sending an address, they issue tax invoice INV-2026-0074 with one line — 'Commercial contract review, 22 pages, with markup — 1 × 1,800.00' — issued 14 August, due 21 August.

The payment page shows Pike & Vale as payee, 1,800.00 USDT due by 21 August, the line item, and a payment block reading 'USDT on TRON (TRC20)' with the address, a QR code and a copy button. Their contact forwards the link to the client's finance manager, who pays it that afternoon. Pike & Vale check the wallet, mark it paid, and the shared page updates.

Sending an address with no amount, so a rounded-down payment becomes your problem to argue about.

Requesting payment in advance on a tax invoice. Money before delivery belongs on a proforma invoice.

Omitting the network, which is the one mistake in crypto billing that is not recoverable.

Describing the page as a payment link. There is no processor behind it; calling it one sets an expectation it will not meet.

Screenshotting an address into a chat. Screenshots cannot be copied, so the client retypes — and retyping addresses is how funds get lost.