A payment QR code makes data entry easier but does not decide that the recipient or request is correct. It can contain an address, amount, invoice, link or application-specific instruction. After scanning, inspect what opened and review the actual payment again before authorizing it.
A clear image and familiar logo do not authenticate the payment instruction.
BTKWIN.COM · EDUCATIONAL EXAMPLESuccessful decoding does not prove a genuine payment
A camera extracts data from an image. The image can be readable while directing payment somewhere other than the intended recipient. A shop name, embedded logo or secure-payment caption is not a substitute for matching the instruction with a trusted source.
Imagine someone placing a replacement sticker over a shop’s receiving code. The camera will decode the replacement if it is valid. Repeatedly scanning it does not establish ownership. Confirm the receiving request through an independent appropriate channel.
The FTC’s QR-code warning explains how encoded links can lead to misleading pages. If a browser opens instead of the expected wallet workflow, inspect the domain and task before entering credentials or approving anything.
Determine what the wallet actually read
A bare address may leave the amount for you to enter. A payment request can prefill an amount and description. A code can also refer to another payment method, a web page or an application connection. Not every square image represents an ordinary Bitcoin on-chain payment.
Read the resulting fields and selected route. If the application rejects the request, do not delete unfamiliar parts merely to force acceptance. You may remove necessary instructions or change the request type.
Ask the intended recipient for a compatible current request if needed, and verify that new version independently. A prior working code does not establish that a different invoice or route is appropriate now.
Interpret the result after scanning
| Result | Inspect | Insufficient conclusion |
|---|---|---|
| Address field | Asset, network and recipient | Amount is already agreed |
| Amount and description | Unit, destination and source | Recipient name is authenticated |
| Website | Domain and actual requested action | Opening means a valid payment began |
| Several payment routes | Which method the wallet selects | All routes have equal support or cost |
Bitcoin amount fields need unit checks
The current BIP321 URI specification replaces BIP21 and supports payment-request conventions. Its publication does not establish that every wallet implements every option or authenticate the request creator.
In that format, an amount is expressed in decimal BTC using a period and no thousands separators. A hypothetical amount=0.00025 represents 0.00025 BTC, or 25,000 satoshis. It is not 0.00025 satoshis or 25,000 units of a fiat currency.
A wallet showing 25,000 sat for that request can therefore be consistent. A display of 25,000 BTC would describe a radically different amount. Match value and unit rather than visual similarity of digits.
Descriptions and labels are not identity certificates
A request creator can supply a label such as shop invoice. That text helps describe the request without proving who created it. Confirm its source and agreement through your actual relationship with the recipient.
Do not assume a request message will necessarily be stored on-chain. Its interpretation depends on format and wallet. The key question is the meaning of the final operation you authorize, not every piece of descriptive text in the source image.
If the invoice is priced in fiat, review conversion price, quote time and any expiry. A newly issued request can require a changed amount. Do not pay an expired old value without checking how the recipient associates and accepts the payment.
Match asset, network and receiving method
A USDT label alone does not describe its network or exact token identity. An address valid on several networks does not prove a receiving service accepts all of them. Refresh the recipient’s current instructions for the selected route.
A Bitcoin request can offer on-chain and Lightning alternatives. Determine which your wallet actually uses and which evidence and conditions apply. Do not expect every payment method to produce the same public explorer record.
For a custodial deposit, inspect required extra fields and current account instructions. A saved image can refer to another account, an obsolete route or a request with a limited purpose. Source and context remain necessary.
Separate invoice amount from the budget
Suppose an invoice requires a hypothetical 25,000 satoshis and the wallet estimates a 1,800-satoshi fee. Paying the fee in addition means a 26,800-satoshi budget. Deducting it from the entered payment can change the net recipient amount.
The figures illustrate allocation rather than current network cost. Construction and rate affect fees, and a service can add other processing or conversion charges. Use the transfer cost calculator to organize distinct costs without counting the same charge twice.
Check the final net amount against the invoice. A correct unit conversion does not repair a payment that becomes too small because fee treatment was misunderstood.
Read the approval request after the scan
The scan stage fills or opens something; signing authorizes the actual operation. Recheck destination, amount, network and fee at confirmation. With an independent signer, use its official display and understand warnings rather than relying solely on the original picture.
Some codes open application connections, message signatures or token permissions instead of simple payments. If paying an invoice leads to broader authority, ask for a clear explanation. An absent immediate gas fee is not a complete safety test.
Ordinary receiving does not require giving the recipient recovery words or a private key. Close a page that turns a payment task into that request and inspect the verified wallet directly.
If a problem appears after scanning
Identify what you actually did: decoded an image, opened a page, entered information, signed or sent. Scanning alone is not evidence that money moved. Inspect the wallet’s records and appropriate payment evidence.
If submitted but unconfirmed, do not pay again solely because an invoice page still waits. If executed but uncredited, compare receiving conditions. Our transfer help tool locates the stage before another action.
Retain invoice reference and payment evidence while protecting unrelated account details. A code image may contain an address, amount and private invoice context, so share only the information needed with the intended party.
Continue reading
English content and examples reviewed: 27 October 2026. Read the Arabic edition.
