QR Code Payments Explained: How Pay-by-Scan Actually Works

How QR code payments work—customer-presented vs merchant-presented codes, wallets, POS flows, security basics, and when dynamic marketing QR codes are a better fit.

12 min

Pay-by-scan looks simple: point a camera, confirm an amount, done. Behind that moment sits a stack of wallets, payment networks, point-of-sale (POS) software, and risk controls that are very different from a marketing QR on a poster. This article explains how QR code payments actually work, what “customer-presented” and “merchant-presented” mean, where open-banking and tip-jar flows fit, and when a marketing dynamic QR is the better tool.

It belongs in the General silo alongside how QR codes work and types of QR codes (URL, Wi‑Fi, vCard, and more). It does not replace a static vs dynamic primer or an NFC vs QR comparison. The focus here is the payment ecosystem: what the square encodes, who moves the money, and how that differs from campaign links.

What a payment QR code really encodes

A QR code is still just a data carrier. In a payment context, the payload is rarely “a pretty landing page.” It is structured information that a wallet or banking app knows how to interpret—often a payment URI, a merchant identifier plus amount and currency, a one-time token, or a deep link into a specific payment rail.

Typical payloads include:

  • A merchant-presented order or invoice reference (amount may be fixed or entered later)
  • A customer-presented wallet token that the cashier’s scanner reads once
  • An open-banking or pay-by-link style URL that opens a bank-authorized checkout
  • A peer-to-peer handle or tip destination (common on street carts, creators, and charity jars)

The phone camera decodes bytes the same way it would for any other QR. What changes is the application layer: the wallet validates the merchant, asks for biometric or PIN approval, and settles through card networks, real-time bank rails, or a closed-loop balance (store credit, Alipay/WeChat-style wallets, and similar). For a refresher on modules, finder patterns, and decoding, see how QR codes work.

Payment QR vs marketing QR (keep them separate)

Aspect Payment QR Marketing / campaign QR
Primary job Move money or open a wallet checkout Open content, offers, menus, lead forms
Who issues it Banks, wallets, acquirers, POS apps Marketers, operators, dynamic QR platforms
Payload Payment tokens, EMV/QR scheme data, pay links Usually a URL (often a short redirect)
Success metric Authorized, settled transactions Scans, clicks, conversions, campaign ROI
After cancel of a QR tool Depends on the payment provider Depends on the redirect host’s policy

A dynamic marketing generator such as Izoukhai’s unlimited dynamic QR tool is excellent for editable destinations, analytics, SVG export, and smart redirects—but it is not a payment processor. Do not expect it to authorize card charges or replace your POS. Use payment rails for money; use marketing QR codes for discovery, menus, reviews, and follow-up.

Two directions: customer-presented vs merchant-presented

Almost every in-person QR payment falls into one of two orientations. Getting this wrong is a common source of staff training friction.

Merchant-presented QR (you show the code)

The merchant displays a code—on a terminal screen, printed stand, sticker, or receipt. The customer’s wallet app scans it. That code may be:

  • Static merchant ID — same graphic every day; the customer types or confirms the amount
  • Dynamic order QR — generated for this cart total, often with a short expiry
  • Pay-by-link style — URL that launches a hosted checkout in a browser or app

Merchant-presented codes dominate café counters, market stalls, and many Asia-Pacific wallet ecosystems. Staff do not scan the customer’s phone; the customer does. Printed static merchant codes are convenient but weaker on amount integrity unless the wallet locks the total from the payload. Dynamic order codes reduce that risk because the terminal encodes the exact total.

Customer-presented QR (the customer shows the code)

The customer opens their wallet and shows a one-time or rotating QR (or barcode). The merchant’s scanner or camera reads it. Settlement hits the customer’s linked funding source. This feels closer to presenting a card: the cashier initiates the read, the amount comes from the POS, and the customer confirms on their phone if required. These flows suit checkouts that already have barcode scanners, and wallets that prefer not to expose a long-lived merchant graphic that could be photocopied onto a fraudulent stand.

Hybrid and “scan to tip” variants

Tip jars, buskers, and donation boxes often use a static merchant-presented code that opens a peer-to-peer or wallet payment screen—amount chosen by the payer. Charity posters work the same way. Restaurants sometimes combine both worlds: a dynamic marketing QR for the menu on the table, and a separate payment QR or NFC tap at the till. Mixing jobs into one code (“scan for menu and pay”) usually creates confusing UX—prefer clear separation.

Major payment QR ecosystems (high level)

You do not need every brand name to understand the architecture. Patterns repeat across regions.

Closed-loop and super-app wallets (Alipay / WeChat Pay style). The QR is a native object inside a super-app. Merchant-presented codes map to a merchant account; customer-presented codes are ephemeral tokens. Settlement, disputes, and KYC live inside the wallet operator’s rules. Multi-wallet cities may need several codes or a switching terminal—that is a payments ops problem, not a marketing QR job.

Card-network QR and POS order codes. Some regions use QR formats aligned with card network standards so a scan can initiate a card-funded or account-funded payment with familiar chargeback frameworks. The acquirer or gateway still matters: the QR is an initiation channel, similar to tap or insert. Modern POS systems generate a dynamic order QR on the customer-facing display for the current ticket and regenerate it when the ticket changes—the gold standard for amount accuracy in merchant-presented mode.

Open banking, pay-by-link, and in-app wallet pay. In open-banking markets, a scan may open a bank-authorized account-to-account payment. The QR often encodes a URL to a consent screen: choose bank → authenticate → confirm amount → receive receipt. Pay-by-link invoices are cousins of this flow; printing the same link as a QR changes only the entry point. These flows shine for invoices, deposits, and higher-value tickets. Many consumer wallets can also show a receive code or scan a pay code—mechanically still scan → validate → authorize. Peer-to-peer apps popularized the tip-jar pattern globally.

End-to-end: what happens in a typical scan-to-pay

Walk through a merchant-presented dynamic order at a coffee shop:

  1. POS totals the cart and requests a payment payload from the gateway or wallet plugin.
  2. Terminal renders a QR encoding merchant ID, amount, currency, order reference, and often a nonce/expiry.
  3. Customer opens a compatible wallet (or camera that hands off to the wallet) and scans.
  4. Wallet shows merchant name, amount, and funding source; the customer approves with biometrics or PIN.
  5. Risk checks may soft-decline or step-up authenticate; authorization returns to the POS; settlement follows the rail’s rules.

Customer-presented mode flips the middle steps: the POS scans the customer’s rotating code, then pushes the amount into the wallet session. The QR does not “contain the money” or magically make an untrusted sticker safe. Trust comes from the wallet brand, merchant verification, and the confirmation screen—not from the black-and-white modules alone.

Security and trust basics for pay-by-scan

Payment QR fraud overlaps with general QR risk, but the stakes are cash. Pair this section with QR code security risks and safe scanning for phishing and overlay tactics. The threats that matter most are sticker overlays on static merchant codes, fake stands at events, quishing pages that harvest card details, amount manipulation on poorly locked static codes, and shoulder surfing of long-lived customer-presented tokens.

Merchants: prefer dynamic, amount-locked codes from your POS or acquirer; laminate and inspect static tip codes; display the legal merchant name guests will see in their wallet; keep marketing posters separate from payment codes; monitor settlement reports after outdoor events.

Customers: prefer official wallet apps; confirm merchant name and amount before approving; treat unexpected “pay this fine” QR codes with the same skepticism as phishing emails; treat confirmation screens as seriously as chip-and-PIN prompts.

Understanding types of QR payloads helps you notice when a code is “just a URL” versus a structured payment object—useful when something feels off.

When QR payments shine—and when they frustrate

QR payments fit well where customers already live in wallet apps, at contact-light counters without reliable card terminals, for invoice and deposit collection via pay-by-link, for tips and donations, and for pop-ups that can onboard to a wallet merchant profile quickly.

They frustrate guests without the required app and no fallback, ultra-fast lanes where every extra tap hurts throughput, offline environments if the wallet cannot authorize, and brands that need one global UX—QR payment rails are still fragmented by country.

For broader business context beyond checkout—menus, packaging, loyalty, events—see QR code use cases for business. Retail operators often combine pay hardware with scannable store journeys described in dynamic QR codes for retail stores.

Placement still matters (even for payment codes)

A perfect payment payload fails if the code is tiny, low-contrast, or glare-blasted on a glossy screen protector. The same physical rules as marketing codes apply: quiet zone, size versus scan distance, and lighting. Follow QR code print and placement for standees and counter mats. On product inserts that deep-link to a pay-by-link invoice or warranty deposit, QR codes on packaging and product labels covers durability and print substrates. Keep on-screen POS codes large enough for older cameras, and re-test printed tip codes after reprinting—faded thermal stickers are a silent conversion killer.

Where marketing dynamic QR codes are the better tool

Teams sometimes ask a payment QR to do marketing jobs, or ask a marketing QR to “handle checkout.” Both create gaps.

Use a payment QR / POS rail when the scan’s job is authorization and settlement. Use a marketing dynamic QR when you need to change a destination after print, measure scans by placement or device, route iOS and Android users differently (smart redirects), keep unlimited campaign codes without reprinting packaging, or export crisp SVG artwork for designers.

That is the lane for Izoukhai: a strong, low-cost unlimited dynamic QR generator for campaigns—$3.99/month or $39.99/year, unlimited codes and scans, edit destinations anytime, real-time analytics, SVG export, smart redirects, and codes that keep working after you cancel. It will not replace your bank’s QR merchant tool, card gateway, or Alipay/WeChat onboarding. Point marketing codes at a hosted checkout page or pay-by-link URL if you want a scan-to-pay web journey; the money still moves through your payment provider.

If you are still choosing between fixed and editable campaign codes, read static vs dynamic QR codes—then come back here when the question is “who settles the funds?”

Sensible architecture for stores and restaurants

A practical split looks like this:

  1. Table / window / packaging: dynamic marketing QR → menu, loyalty signup, or store locator
  2. Till / handheld: payment QR or tap-to-pay from your acquirer
  3. Receipt / follow-up: optional marketing QR → review or reorder page (trackable)

Restaurants and cafés can dig into menu and table workflows in the restaurants dynamic QR guide; retail floor journeys are covered in the retail stores guide. Neither turns a marketing platform into a card network—and that boundary is intentional.

Scenario walkthroughs

Night market stall. A vendor displays one laminated WeChat/Alipay-style merchant code plus a card reader backup. Customers scan and enter the amount. Risk: overlays and wrong totals. Mitigation: dynamic POS QR when Wi‑Fi allows; otherwise call out the amount and watch on-screen confirmation.

Boutique with open-banking invoices. A furniture shop emails a pay-by-link deposit and prints the same link as a QR on the quote. Marketing codes on the window still point to a lookbook—not the invoice—so a stolen sticker cannot collect deposits.

Creator tip jar plus campaign code. A peer-to-peer QR handles tips (payment). A separate dynamic marketing QR opens a mailing list or merch store. Two codes, two jobs. The same split works for pop-up retail: POS for wallet checkout; window vinyl for a swappable collection page.

Choosing tools without mixing metaphors

Ask three questions before you generate anything:

  1. Does this scan need to move money under regulated payment rules? → Use your wallet, bank, or acquirer QR tools.
  2. Does this scan need analytics, edits after print, or campaign routing? → Use a dynamic marketing platform (see Izoukhai above)—not a payment terminal.
  3. Do guests need both? → Two codes (or a landing page with separate “View menu” and “Pay bill” actions).

Barcodes still dominate SKU scanning at grocery lanes, while QR dominates camera-based consumer flows—see QR codes vs barcodes. Tap-to-pay NFC and QR payments can coexist; choose based on hardware and habits (NFC vs QR codes covers contactless trade-offs without repeating this payments deep dive).

Conclusion and next steps

QR code payments succeed when the wallet and merchant account do the heavy lifting: identity, amount integrity, authorization, and settlement. The QR is only the handshake. Merchant-presented and customer-presented modes change who scans whom; Alipay/WeChat-style wallets, card-network QR, open-banking pay-by-link, and tip jars are variations on that handshake. Marketing dynamic QR codes remain the right tool for menus, packaging stories, retail journeys, and measurable campaigns—not for replacing your payment stack.

Next steps: