QR Checkout

Overview

A QR checkout moves payment instructions from a merchant screen, receipt, or terminal into a customer’s wallet camera flow. The encoded data can be a direct address, a standardized payment URI, or a short URL that resolves to a server-side invoice. Dynamic codes are normally safer for commerce because they can bind one order, amount, asset, network, and expiration.

The wallet should display the decoded merchant, destination, network, asset, amount, and any memo before signing. A QR image is not inherently trustworthy: attackers can replace printed stickers, alter a web page, redirect a short link, or generate a code for the wrong network. HTTPS and authenticated invoice retrieval help, but the customer still needs a clear confirmation screen.

Static codes that contain only an address require additional attribution logic. The merchant may need a unique amount, memo, account mapping, or post-payment claim step, and reused addresses can complicate privacy and reconciliation. Dynamic codes reduce ambiguity but must handle expiry and clock differences without changing the original order silently.

After scanning, the wallet may reject, broadcast, or submit a transaction that fails or pays a different amount. The checkout should show pending status until payment confirmation validates the intended asset, destination, received amount, execution result, and configured finality. A wallet return screen or camera success animation is not authoritative.

Operations should retain the QR payload or request version, invoice, device session, expiration, selected route, transaction identifiers, and settlement result. Idempotent callbacks prevent repeated scans or refreshes from creating duplicate orders.

QR checkout differs from wallet checkout mainly in the handoff channel: one begins with scanning encoded instructions, while the other begins with an interactive wallet connection or selection. The payment and reconciliation controls remain the same.