What a Crypto Payment QR Code Actually Contains

Scanning a crypto payment QR code gives a wallet information to read. The square pattern can represent a receiving address or a more detailed payment request, depending on what was encoded. It supplies information for the next action rather than completing that action itself. A payment request can specify a destination and other details, while a wallet-pairing code starts a connection with an application. Their contents determine which kind of request the wallet receives.

The difference is in the encoded text. A receiving address is a destination identifier. A structured payment request uses a URI, or Uniform Resource Identifier, to organize information for software. Spark’s August 2026 explanation of Bitcoin payment URIs describes the bitcoin format, which can combine a receiving address with named fields for further instructions. A QR code presents that string in a machine-readable form. The format defines what its parts mean.

From Deposit Address to Wallet Request

For an online crypto casino, a payment QR code can present the receiving details used to fund an account. The service’s deposit instructions describe selecting a cryptocurrency, receiving the deposit address for that cryptocurrency, and either copying that address or scanning a QR code with a crypto wallet app. The account identifies where the deposit will be used within the service, while the wallet handles the transfer from the sender’s side. Scanning brings the receiving information into the wallet without manually entering the displayed address.

The selected cryptocurrency and its deposit address belong together in that funding process. The address directs the transfer toward the receiving side; the sender’s wallet manages the action of sending. The resulting account funding is used within the entertainment service.

Inside a Bitcoin Payment Request

Bitcoin payment URIs show how a request can contain more than an address. The bitcoin: prefix identifies the URI scheme. An address can occupy the main address portion, followed by named fields called query parameters. The field names identify the kind of information supplied, so the wallet can distinguish a requested quantity from a recipient label.

These are different kinds of data in the standardized Bitcoin request format. An amount describes the quantity requested, rather than naming a separate payment asset. A label is optional text describing the recipient for display in wallets, rather than proof of identity. Neither changes the meaning of the receiving address. The fields do not all have to be present: a request’s contents depend on which instructions the recipient includes. The wallet interprets what is supplied according to the format.

BIP321, a Bitcoin URI specification, extends this structure to accommodate different payment methods. It defines named parameters for Lightning invoices and other payment instructions. The conventional address portion can be empty when a payment instruction appears in a parameter. One structured request can therefore offer more than one payment route. This describes the format’s capacity, rather than establishing that every wallet handles all the listed methods or that every merchant includes them.

The wallet identifies the methods it understands and chooses among supported instructions according to its own policy. Several routes can share one QR code because the URI carries them in one string. BIP321 does not impose a universal priority order. Supported payment methods and selection behavior remain properties of the wallet implementation.

The amount of information also affects the code’s visual density. Spark notes that including a lengthy Lightning invoice can produce a pattern that lower-quality cameras struggle to scan. Reading that pattern and interpreting its payment instructions place different demands on the scanner and wallet.

When the Code Connects a Wallet

A wallet connection begins with a different request. In its July 2025 WalletConnect release note, SSP Wallet describes an application generating a URI beginning with wc:. The user can copy the string or scan its QR representation, then approve pairing in SSP. That establishes a connection through which the application can send later requests. SSP’s pairing remains active until either side ends it, so the connection can continue beyond the initial scan.

The later requests can ask for a message signature, a transaction, or a blockchain change. SSP’s personal-sign interface handles human-readable messages used for authentication or consent outside the blockchain. Its transaction interface handles a separate action. For transactions, SSP requires approval on the wallet and a phone before broadcasting the fully signed result. This two-device arrangement belongs to SSP’s implementation. The application receives signatures without receiving the wallet’s private keys; the connection carries requests while the wallet handles signing.

What the Wallet Does With the Request

The software needs to understand the instructions it receives. BIP321 distinguishes optional parameters from required ones, marked with the req- prefix. An unsupported optional parameter can be ignored. The wallet rejects a request containing required parameters it cannot interpret. This is a compatibility rule within the Bitcoin URI specification, not a claim that all crypto QR codes or all wallets follow one format.

Authorization then concerns the action described by a supported request. Reading a destination, approving an application pairing, and signing a transaction have different purposes, even when a wallet presents them through related screens. Copying and scanning are methods of supplying information to that software. A payment QR code delivers the receiving instructions encoded by its creator; a connection QR code delivers the request to pair. The wallet’s interpretation and approval process determine how that request becomes an action.