What you will end up with
A Bitcoin payment request can carry an address, an amount and a short description in one link. A compatible wallet can open that link or scan its QR code and fill in the payment screen. That is less error-prone than asking somebody to copy an address and type an amount separately.
This guide shows how to create a request in a wallet, inspect the information it contains, share it, and confirm that the payer received the same details. It does not send bitcoin. The practice examples use an address that the BIP 321 specification deliberately marks as invalid, so they cannot become accidental payments.
BIP 321 is the current Complete specification for bitcoin: payment instructions. It replaced BIP 21 and documents modern address types plus optional Lightning and silent-payment instructions. Wallet support still varies, so the safest everyday process starts with the simple fields that almost every payment screen can explain: destination, amount, label and message.
Before you start
You need:
- a Bitcoin wallet that can create a fresh on-chain receive address
- the amount you want to request, stated in bitcoin or sats
- a short description that makes sense to the payer
- a private or authenticated way to share the request when identity matters
Do not paste a seed phrase, private key, wallet backup or extended public key into a payment-request tool. None of those is needed. A receive address is public by design, but sharing it can still link a payment to you.
Use a fresh address for this request. Reusing an address still works, but it makes separate payments easier to connect on the public chain. Bitcoin Design's requesting guidance also treats a request as information for one transaction, not as a permanent identity.
1. Create the request in your wallet
Open the wallet that should receive the payment and choose Receive or Request. Select the correct Bitcoin account. If the wallet offers several networks, choose Bitcoin mainnet for real bitcoin, not Testnet, Testnet4, Signet, Liquid or Lightning unless the payer explicitly expects that other system.
Generate a new receive address. If you use a separate signing device, verify the address on that device before continuing. A computer or phone can display an altered address if it is compromised. The request should be built from the address your trusted wallet or signing device confirms.
Enter the requested amount. Wallets may let you type sats, BTC or a government-currency amount. Check the unit before accepting the conversion. In the underlying URI, BIP 321 keeps the amount field in decimal BTC. For example, 150,000 sats is 0.0015 BTC, not 150000 BTC.
Add a short label or message if the wallet supports it. Use something the payer can verify, such as September invoice 1042 or Table 7. Do not place a home address, account password, recovery words or other secret in either field. Metadata can be copied, logged and shown by several applications.
The wallet should now show a QR code, a payment link, or both. Do not share it yet.
2. Read the request before sharing it
Choose Copy, Share or an equivalent action and paste the result into a temporary note. A basic request looks like this:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.0015&label=Coffee%20order&message=Table%207
The example address is intentionally invalid and must not be paid. Its parts are still useful:
bitcoin:tells the device to open a compatible Bitcoin wallet.- The text before
?is the on-chain destination. amount=0.0015requests 0.0015 BTC, which is 150,000 sats.label=Coffee%20ordergives the wallet a recipient label.message=Table%207describes the purpose.
%20 represents a space. Other punctuation and non-ASCII characters are encoded too. Let the wallet build this text when possible. Editing a URI by hand makes it easy to damage an address, change an amount or create a link that another wallet cannot parse.
Compare the full destination in the request with the fresh address your wallet displayed. Then compare the amount in both units:
0.0015 BTC = 150,000 sats
The commas in 150,000 sats are for human reading only. A URI amount uses a period as the decimal separator and no thousands separators. amount=1,5 is not a valid way to request 1.5 BTC.
3. Check the request in a second view
Use one of these checks before sharing a request for a meaningful amount:
- Scan the QR code with a second compatible wallet, but stop at its review screen.
- Open the copied link on another device that has a wallet registered for
bitcoin:links. - Ask the payer to read back the destination, amount and description before they approve anything.
The review screen should show the same on-chain address and amount. A label or message helps the humans coordinate, but Bitcoin does not enforce either one. If the second wallet omits a label, the payment can still go to the address. If it changes the address or amount, cancel and recreate the request.
BIP 321 reserves parameters beginning with req- for features that are required to understand the request. A wallet that does not understand one of those parameters must reject the whole request. Do not remove an unfamiliar req- field just to make a link open. Ask the requester to produce a simpler request instead.
Unknown fields without req- may be ignored. That makes the format extensible, but it also means two wallets can show different optional details. The destination and amount still need an explicit human check.
4. Share through the right channel
For an in-person payment, let the payer scan the QR code directly from your wallet screen. Keep the code large, bright and unobstructed. Confirm the amount on their review screen before they approve it.
For a remote payment, send the link through a channel the payer already associates with you. If somebody receives a payment request from a new account or an unexpected message, the link itself does not prove who sent it. Confirm the request through a second known channel when impersonation would matter.
A QR code is only another representation of the same text. It is not a signature, certificate or proof of address ownership. A convincing code can still point to an attacker's address. Identity and destination verification happen outside the QR format.
Do not publish a request unnecessarily. On-chain addresses and later transactions are public. A fresh address limits linkability between payments, but posting it next to your real name creates that link yourself.
5. Confirm receipt without confusing the states
After the payer approves the transaction, your wallet may show several different states:
- Request created: no payment has necessarily been sent.
- Transaction seen or pending: the wallet has learned about a transaction, but it is not yet in a block.
- Confirmed: the transaction has been included in a block.
The payment request does not update itself on the Bitcoin network. Its label and message are wallet metadata, not fields miners preserve for you. Check the receiving wallet for the actual transaction and expected amount.
Do not treat a screenshot of the request as a receipt. It proves only that somebody displayed payment instructions. If you need to inspect a public test record without connecting a wallet, use our guide to reading a Bitcoin transaction.
If something goes wrong
The scan opens the wrong network: cancel. Return to the receiving wallet and choose the Bitcoin account on the network the payer will use. Do not try to repair the mismatch by changing the first characters of an address.
The amount is far larger or smaller than expected: check the unit. The URI uses BTC, while many wallet screens default to sats. Compare both representations before approval.
The link opens a browser search instead of a wallet: copy the full text into the wallet's Send or Scan function. The operating system may not have a handler registered for bitcoin: links.
The wallet rejects the request: look for a truncated QR scan, unsupported payment instruction or unknown required parameter. Ask for a plain on-chain address and amount rather than deleting fields yourself.
The address changes after copying: stop. Reconnect or reopen the receiving wallet, generate a new address and verify it again. Do not send a small test payment to an address you already distrust.
The payer says the request expired: ordinary on-chain addresses do not expire, but a combined request may also contain a Lightning invoice, and Lightning invoices do. Create a new request rather than assuming every instruction inside the old one remains usable.
The payment is pending: a valid request cannot guarantee when a transaction confirms. Confirmation depends on broadcast, fee conditions and block inclusion. Check the transaction itself, not the age of the QR code.
What this process does and does not prove
The process checks that the destination, amount and description survived from your receiving wallet to the payer's review screen. It reduces manual copying mistakes and catches some address substitution.
It does not prove the identity of the requester, guarantee that the receiving wallet is secure, reserve an exchange rate, guarantee confirmation, or provide a refund path. It also does not make a reused address private.
For this guide, the BIP 321 examples were parsed in a disposable local script on 30 September 2026. The valid-format fixture produced the expected scheme, address, decimal amount, label and message. Negative controls detected an unknown req- field and rejected a comma-formatted amount. No wallet interface, QR scanner, real address, account, key or funds were used, so the wallet-specific screens and camera behavior remain untested here.
The final check belongs on the payer's review screen: correct destination, correct amount, expected network, then explicit approval. A payment request carries instructions. It never replaces that decision.