How to Accept Crypto Payments by QR Code with QRLynx

A merchant needs a receiving route, a QR payload that matches that route, a visible asset and network label, a way to confirm payment, and a record that connects the transfer to the sale.

There are two practical paths. A direct-wallet QR encodes a public receiving address or payment URI, and the merchant monitors the wallet or account. A processor-checkout QR opens a hosted invoice or checkout URL, and the processor manages the payment request, status, and settlement options it supports.

QRLynx can create both QR surfaces. Its Bitcoin and Ethereum types create static address-based payment URIs. Its Website / Link type can open a processor checkout as a static or dynamic URL QR. QRLynx creates and manages the QR, while the wallet or payment processor executes and confirms the financial transaction.

The current QRLynx Bitcoin QR type encodes bitcoin:ADDRESS. The current Ethereum QR type encodes ethereum:ADDRESS. Both are static-only payloads, and the current forms do not add an amount, order reference, Ethereum chain ID, or token contract.

For another public-address format, QRLynx can encode the exact supplied value as a static Text QR. Wallet recognition varies, so a merchant should decode the finished QR and test it with the intended payer wallet and receiving account.

For a processor flow, create the invoice or checkout in the chosen processor first, then place its HTTPS URL in the QRLynx Website / Link type. Static mode directly encodes the checkout URL. Dynamic mode uses a QRLynx short link, supports destination updates and scan analytics, and is appropriate only when the processor URL remains valid for the intended use. A scan is not proof of payment, so the merchant still confirms status in the wallet, processor, or order system.

Define the exact assets and networks the receiving account supports, who controls wallet access, how staff confirm a completed payment, how the fiat sale value is recorded, and how refunds are authorized. A short, specific policy gives staff one repeatable process.

For a direct QR, place the asset and network beside the code, such as Bitcoin on Bitcoin mainnet or USDC on Base. Show a recognizable portion of the receiving address so the payer can compare it with the wallet preview. If the QR does not contain an amount, tell the payer where the final amount appears.

For a hosted checkout, display the order amount and currency in the checkout itself and keep the customer on the processor’s documented confirmation path. Transaction-specific checkouts usually provide a clearer match between an order and an onchain transfer than one reusable wallet address.

A reusable wallet address can receive several transfers, so the merchant needs a reliable way to match each transfer to an order. Record the transaction identifier, timestamp, asset, network, crypto amount, fiat sale value, customer or order reference where appropriate, and the account that received it.

A processor checkout can supply transaction-level status and references when those features are part of its current product. For a direct wallet, the merchant builds the matching process around wallet records and the point-of-sale or invoicing system.

QRLynx scan analytics measure interaction with a dynamic checkout URL. They do not establish that a wallet authorized a transfer or that the merchant received funds. Financial reconciliation should use the authoritative wallet, blockchain, processor, and order records.

For a refund, verify the customer, approved amount, asset, network, and a current receiving destination before an authorized person sends funds or approves the processor refund. The address that originally sent a payment can belong to an exchange or intermediary, so it is not automatically the correct refund destination.

Keep private keys and recovery phrases within the wallet or custodian’s approved security process. A receive QR contains public payment information only. Use role-based access, hardware signing or multisignature controls when appropriate, and a documented recovery process for merchant-controlled wallets.

Inspect physical displays against an approved master image. For screens, control access to the device and checkout account. The official Bitcoin and Ethereum URI specifications both place final authorization with the payer, so the customer should review the recipient and amount before confirming.

For United States federal tax purposes, the IRS treats digital assets received for services as income measured in US dollars at the time of receipt. The IRS also states that the basis of digital assets received for services is generally their fair market value when received, and it requires records sufficient to establish positions reported on a tax return.

A US merchant record should therefore retain the receipt time, asset, quantity, fair market value source, transaction identifier, fees, and later disposition information when applicable. Sales tax, financial reporting, and licensing questions depend on the business and jurisdiction.

This section is operational information, not tax or legal advice. US businesses can review the IRS digital-asset FAQs and work with a qualified professional. Merchants elsewhere should use the current rules and professional guidance for their jurisdiction.

Processor products, supported jurisdictions, assets, networks, fees, settlement choices, and integrations change. Evaluate the current first-party documentation and contract for the exact merchant account rather than relying on a dated provider leaderboard.

• Availability: merchant country, customer geography, business category, onboarding, and support.
• Payment request: transaction-specific address or QR, quote duration, supported assets and networks, underpayment and overpayment handling.
• Settlement: crypto or fiat options, timing, fees, minimums, and withdrawal rules.
• Operations: payment status, order references, receipts, refunds, exports, API or commerce-platform integration.
• Controls: account permissions, custody model, security documentation, compliance responsibilities, and incident support.

Once a processor checkout URL is approved, QRLynx can turn that route into a branded, tested QR surface without claiming to replace the processor’s payment system.

The payment URI structure is documented in the official Bitcoin BIP 321 and Ethereum ERC-681 specifications. US businesses can review the current IRS digital-asset FAQs. Merchant acceptance models and operational decisions were also checked against a current first-party business crypto-payment guide.

For payload-specific guidance, see the QRLynx guides to USDC QR codes and USDT QR codes. Create a direct address QR with the Bitcoin generator or Ethereum generator, build other payment surfaces with the QRLynx QR generator, and decode the exported result with the QRLynx QR scanner.