What a Bitcoin Payment QR Code Actually Contains

Image Source: Created with AI

A Bitcoin payment QR code represents information that a wallet can read. Depending on its contents, that information may be a receiving address or a fuller request containing an amount and other details. The square pattern presents that information in a scannable form. The code’s appearance alone cannot reveal which optional fields are included in the underlying payment request.

The distinction begins with the text encoded in the image. A Bitcoin address identifies a destination, while a payment URI, short for Uniform Resource Identifier, packages payment information into a recognizable link. Lightspark’s explanation of Bitcoin URIs describes how an address-bearing request can include an optional amount, label, or message. Those additional fields give a wallet more information than an address alone.

Receiving details connect online services with the wallets used to fund their accounts. For instance, on a bitcoin casino deposit screen, a receiving address can be copied or presented as a QR code for an external wallet to scan. The code belongs to this exchange of payment information between the service and the wallet. When it is used, the funds will go into the user’s casino account and can then be used to play games and access features, just as with fiat currency. Copying an address and scanning a code are different ways of passing receiving details to the software that will prepare the transfer to the casino.

Offering both copying and scanning establishes how a service presents receiving details. The decoded contents of the code establish what information is being passed. An address-only code communicates the destination, while a structured request may carry additional fields. The wallet can use those fields only where it supports the request’s format. This separates the presentation options on a deposit screen from the payment information actually available to the sender when they receive a request from a casino or another similar service.

An address and a payment request

Image Source: Created with AI

In a conventional address-bearing Bitcoin URI, the prefix bitcoin: identifies the type of request. The receiving address follows it, with optional fields providing further payment information. This structure lets software recognize the request and distinguish its components, rather than treating the whole text as a receiving address.

An optional amount field in this format specifies the quantity the recipient requests in BTC. Knowing the destination address alone does not establish that quantity. An address-only code leaves it to be supplied separately, while a request containing an amount can pass it to compatible wallet software. The recipient can therefore provide both the destination and the requested quantity through one structured request, leaving the wallet to interpret each field according to its purpose.

Labels and messages provide descriptive context. A label can name the recipient, while a message can describe the payment request. These fields are optional, so their absence does not make an address-bearing request incomplete.

The same request can travel as a link

A payment URI can be presented as a clickable link as well as encoded in a QR image. The underlying request is text in either case. The bitcoin: prefix identifies a payment request even when no QR image is involved. Clicking the link and scanning the image provide different routes for passing that text to an application capable of interpreting it. The QR presentation does not add payment fields that were absent from the request.

The request also does not prescribe a particular wallet for the sender. The payer’s system determines which application handles the URI. That separates the information supplied by the recipient from the software used to read it.

What BIP321 added to payment requests

Bitcoin’s payment-request conventions have developed beyond the older address-first format. In May 2025, Bitcoin Optech reported the merge of BIP321, a Bitcoin Improvement Proposal that modernizes and extends BIP21, the earlier URI scheme. The change concerns how payment instructions are described and organized.

BIP321 retains the familiar address-bearing structure while standardizing the use of query parameters, the additional fields within a URI. Different payment instructions can be identified through their own parameters. The proposal also allows the address field to remain empty when at least one payment instruction is supplied in a query parameter.

An empty conventional address field therefore need not mean that receiving instructions are missing. Another parameter can supply them. Software has to examine the instructions contained in the request, rather than assume that everything needed appears immediately after the prefix. Under this format, the absence of the older address field and the absence of payment instructions are different conditions.

A published proposal gives software developers a specification they can implement. It does not demonstrate that every wallet supports it or that every Bitcoin-accepting service produces requests using it. The relevant distinction is between what a format permits and what particular software implements.

Scanning and sending are separate actions

Reading a request gives the wallet information to work with. Where supported, that information can populate payment details for review. The user’s decision to send remains a separate part of the process, which is why a displayed code and a completed transaction describe different events.

A wallet’s ability to scan a QR image does not establish that it supports every instruction encoded in a Bitcoin URI. Reading the image and understanding its formatted contents are separate tasks. Recognizing the request as Bitcoin-related is only part of interpreting the payment instructions that it carries.

Optional fields can make that preparation more descriptive, but they do not turn the QR image into a transaction record. An amount describes what is requested; a label or message supplies context. None of those fields alone establishes that the requested transfer was authorized or sent. The code communicates the request; the wallet’s later action determines whether a payment is sent.