Payment requests and links
A payment request gives the paying wallet enough information to prepare a review. Opening or copying the request does not approve a transfer. VOUT checks the destination, asset, amount, and network before the user authorizes a payment.
Match the request to the payment
| Request | Intended use | What the sender must check |
|---|---|---|
| Bitcoin address or Bitcoin payment URI | An on-chain BTC payment | Network, destination, amount, and transaction fee |
| RGB receive invoice | A compatible RGB transfer | Contract ID, exact amount and precision, network, expiry, and supported proof delivery |
| Bitcoin Lightning invoice | A supported BTC Lightning payment | Network, recipient, amount, expiry, and fee review |
| VOUT recipient or supported VOUT payment request | A payment resolved through VOUT | Actual resolved recipient, asset, amount, and settlement path |
The QR code is a way to carry the request. Its appearance does not determine which payment system is involved. A normal Bitcoin address cannot receive an RGB transfer on its own, and a Bitcoin Lightning invoice does not identify an RGB asset simply because the payer selected that asset.
RGB requests bind a particular transfer
The receiving wallet creates a request for a contract and quantity. The sender should preserve the request exactly. Removing an endpoint, changing its encoding, or replacing the contract with a ticker can change what the wallet is able to validate.
Use a fresh request for each payment. If an unpaid request expires or the amount changes, ask the receiving wallet to create a new one. Creating a new request does not cancel an earlier, unexpired request. If a payment is already in progress, resolve its saved status before arranging another payment. See Send and receive for the user flow.
The web sharing page
VOUT’s payment-sharing page uses the /pay route with a URL fragment. The browser reads the fragment locally and offers to copy the complete request for review in the wallet. The page checks the envelope’s shape; it does not validate an RGB proof, confirm a payment, or inspect a wallet balance.
The fragment is the part after #. A browser does not include it in the ordinary HTTP request for the page. That reduces what the web server receives, but the complete URL can still be exposed through browser history, clipboard contents, screenshots, or the person receiving it. Treat a live request as information intended for its payment participants.
Preserve the entire share link when forwarding it. The app owns interpretation and validation. Building a new link by copying selected fields from an existing one can lose information that the wallet needs. The web share format is not a supported replacement for a versioned integration API.
Links to people and groups
VOUT invitation links have a separate purpose. Referral and group links open an invitation flow; they are not payment approvals. A profile or conversation can help people find each other, but a name, avatar, or group invitation cannot replace the final payment review.
If you are adding a payment button to another application, use a supported request obtained from the recipient and provide a way to return to the saved payment after a timeout. Check the integration guide before depending on a link format that has no public versioning commitment.