Apple Pay QR Codes: How They Actually Work in 2026

Before we get to the QR architecture, here is the product map. Each of these lives inside the same Wallet app icon on the iPhone home screen, which is the root of the confusion.

Apple Pay. The card wallet. Stores credit and debit credentials tokenized via the issuer (the actual primary account number never leaves the Secure Element). Surfaces at NFC point-of-sale terminals, in Safari via the Apple Pay JavaScript API, and inside native iOS apps via PassKit. There is no shareable URL for Apple Pay itself — the merchant integrates the Apple Pay button into their checkout, or they accept it on a contactless terminal. A merchant cannot post a QR code that says "open Apple Pay and pay me $20" because Apple does not expose that primitive.

Apple Cash. The peer-to-peer balance product. Lives inside the Wallet app as a virtual card. Transfers happen inside iMessage (you tap the Apple Cash button in the message thread and send a dollar amount) or, since iOS 17, via a shareable Wallet link. The shareable link is the one Apple-native URL flow that gets called "an Apple Pay QR" — and the disambiguation matters because Apple Cash is only between Apple users with Apple Cash enabled, US-only as of this writing, and not a merchant tool. It is the venmo-equivalent inside Apple's walled garden.

Tap to Pay on iPhone. Apple's merchant acceptance product, launched 2022. Allows an iPhone XS or newer to act as a contactless reader, accepting tap payments from customer cards and customer phones. Requires integration with a payment processor (Stripe, Square, Adyen, Stripe Terminal, Shopify POS, and a growing list). The customer taps their card or phone against the merchant's iPhone — there is no QR scan in the flow. This is the product most non-technical merchants are imagining when they search "Apple Pay merchant QR" — but the implementation is NFC, not QR.

The table later in this guide collapses all three into a one-glance reference with the QR support column made explicit. The short version: Apple Pay supports no QR, Apple Cash supports a shareable URL (which can be wrapped in a QR), and Tap to Pay supports no QR. The fourth row in that table is the workaround everyone actually uses — a Stripe / Square / Shopify URL wrapped in a standard QR, which is not an Apple product at all but is what gets sold to merchants as "Apple Pay QR."

iOS 17 introduced a Wallet feature called shareable Apple Cash links. From inside the Wallet app, an Apple Cash user can generate a URL that, when opened by another Apple user on iOS 17 or later, deep-links into a pre-filled send-money screen for a specific amount and recipient. The URL looks roughly like https://cash.apple.com/... with an opaque identifier appended.

This is the closest thing to a "send-money QR code" Apple has ever shipped, and it is what most posts titled "how to generate an Apple Pay QR code" are actually describing when they show step-by-step screenshots. The user generates the link inside Wallet, copies the URL, and wraps it in a standard URL QR using any generator including EZQR's URL QR. When someone scans that QR with the iPhone camera, the camera recognizes the cash.apple.com domain and routes the user into Wallet's send-money flow.

The constraints are sharp and worth naming.

Apple users only. The link does nothing useful for an Android user. The camera scans the URL, the browser opens, and the cash.apple.com page renders a "download Apple Cash" prompt that an Android user cannot act on. For a person-to-person split-the-bill flow between iPhone users, this is fine. For a merchant displaying a QR in their café window, half the customers walk through the door holding an Android phone.

Apple Cash must be enabled on both sides. Apple Cash requires identity verification, US residency, and a US bank link. A traveler from outside the US cannot send Apple Cash even if they own an iPhone. A US user who has not gone through the Apple Cash setup flow gets prompted to set it up before they can pay.

The link is peer-to-peer, not merchant. There is no business-side reporting, no settlement to a merchant bank account, no tax reporting integration. The money lands in another person's Apple Cash balance. For a sole-proprietor contractor who happens to have an LLC bank account linked to Apple Cash via their personal account, this is workable but messy. For any real business with bookkeeping, it is not a merchant tool.

The practical use case is narrow. Splitting a restaurant bill between friends. Tipping a street performer. Reimbursing a roommate for the electric bill. A nonprofit running a casual donation drive among iPhone-using donors. A small-scale fundraiser among an Apple-heavy social circle. Beyond that, the limits compound fast. For anything that resembles a merchant flow with mixed-platform customers, you want the URL-QR-to-hosted-checkout pattern in the next section.

Here is the architecture that almost every "Apple Pay QR code" online is actually using, even when the marketing copy says otherwise.

Step 1. The merchant creates a hosted checkout page on Stripe, Square, Shopify, or any payment processor that supports the Apple Pay JavaScript button. Stripe Payment Links are the cleanest example — stripe.com hosts the URL, no merchant infrastructure required. Square Online checkout, Shopify hosted checkout, PayPal hosted checkout, and Adyen pay-by-link all follow the same pattern.

Step 2. The merchant takes the hosted checkout URL and wraps it in a standard URL QR using any generator. EZQR's URL QR generates the code; the QR conforms to ISO/IEC 18004 — the same standard underneath every other URL QR in the world. A free static QR works for permanent Payment Links; a dynamic QR is worth it only when the destination URL will rotate.

Step 3. The customer scans the QR with their phone camera. The browser opens to the hosted checkout. On iOS Safari, the checkout page detects Apple Pay availability via the Payment Request API and surfaces the Apple Pay button at the top of the payment options. On Android Chrome, the same checkout surfaces the Google Pay button. On desktop, both buttons fall back to a card-entry form. One QR, three good outcomes, zero merchant configuration on the wallet side.

This is the pattern behind the "Pay with Apple Pay" QR stickers in donation kiosks, market stalls, and pop-up retail. There is no Apple Pay primitive in the QR itself. The QR encodes a normal HTTPS URL pointing at a hosted checkout that happens to surface Apple Pay on iOS. The Apple Pay magic is on the checkout page, not in the QR.

The operator implications of this architecture are not obvious until you have run one. Conversion is highest when the checkout is single-product or single-amount. A Stripe Payment Link for a $5 coffee converts better than a multi-product menu where the customer has to pick. A donation page with three preset amounts ($10 / $25 / $50 buttons that route to three separate payment links) converts better than a free-form amount entry. The QR is not the bottleneck. Apple Pay surfaces in 1–2 seconds on a modern iOS Safari load. The bottleneck is the merchant's checkout page UX — taps between landing and payment. Two is the goal; three is workable; five is dead on arrival.

Tracking attribution gets fuzzy. Apple Pay tokenizes the card before it touches the merchant, so the Stripe dashboard shows "Apple Pay" as the payment method but does not surface the underlying card brand to the merchant in the same way a manual entry does. For most operators this is fine; for affiliate tracking and per-card-brand analytics it is a known limitation. The QR codes for payment use case and the QR codes for small business use case cover the downstream attribution patterns in more depth.

Tap to Pay on iPhone deserves its own section because the search intent for "Apple Pay merchant QR" almost always overlaps with "can I accept Apple Pay on my iPhone?" The answer to the second question is yes — but the mechanism is NFC, not QR.

Launched in 2022 in the US and now available in roughly 20 countries, Tap to Pay on iPhone allows an iPhone XS or newer to act as a contactless reader. The merchant integrates with a supporting payment processor (Stripe, Square, Adyen, Shopify POS, and a growing list), opens the processor's app, enters an amount, and presents the iPhone screen to the customer. The customer taps their physical contactless card, their Apple Pay-enabled phone, their Google Pay phone, or their contactless smartwatch against the merchant iPhone. The transaction settles through the merchant's payment processor.

There is no QR in this flow. There is no scanning. The customer's card credentials transit via NFC, the same radio protocol used at every contactless point-of-sale terminal. The merchant iPhone is acting as the terminal.

The practical fit is excellent for contractors, food trucks, in-home services, mobile beauty providers, market stalls, and pop-up retail. The merchant carries the terminal in their pocket. The customer can pay with whatever wallet they have. The friction is lower than a hosted-checkout QR because there is no phone-to-phone scan handoff — the customer's existing tap behavior at any contactless terminal carries over.

The trade-off versus the URL-QR-to-checkout pattern is whose phone is doing the work. Tap to Pay requires the merchant to be present with the iPhone, the processor app open, the amount entered. A printed QR on a café window or a donation kiosk works while the merchant is asleep. Both can coexist in the same business — the QR for unattended scenarios (window display, donation jar, table tents) and Tap to Pay for in-person interactions where the merchant is already at the counter. For most small businesses, both belong in the toolkit.

The full disambiguation in one table, with the QR support column made explicit and the practical fit flagged.

The architecture decisions are easier to make once you have the use case in mind. Six patterns that recur across EZQR's small-merchant cohort.

Donations (nonprofit, church, fundraiser). A printed QR on the donation envelope, the offering plate sign, the event poster, or the lobby sign. Wraps a Stripe Payment Link with three preset amounts, or a Shopify donation page, or a dedicated platform like Donorbox or Givebutter. On iOS Safari the Apple Pay button surfaces at the top of the checkout; on Android the Google Pay button does the same. Conversion lift versus a write-a-check call-to-action is in the 3–8x range for digital-comfortable donor segments. See our QR codes for donations guide for the full pattern.

Market stalls and farmers markets. A printed QR mounted on the front of the table, paired with a Tap to Pay-capable iPhone for in-person card swipes. The QR routes to a Square Online or Stripe checkout where the customer can browse the day's items and pay; the Tap to Pay phone handles in-line transactions. The QR is the unattended-payments fallback for when the vendor is helping another customer.

Food trucks. Two-QR pattern. One QR on the order window pointing at a Square Online or Toast menu where customers can browse before ordering. One QR on the pick-up counter pointing at a tip-only Stripe Payment Link with $1 / $3 / $5 / custom amount buttons. Both surface Apple Pay on iOS. The combined effect is fewer order-counter conversations about menu items and a tip rate that lifts measurably when the customer does not have to dig for cash.

Contractor invoices (plumber, electrician, handyman, mobile mechanic). A QR printed on the printed or emailed invoice routes to a Stripe Invoice URL where the customer can pay with Apple Pay, Google Pay, or card. The contractor never touches a card terminal. For larger jobs (multi-thousand-dollar HVAC installs) the Apple Pay $10K per-transaction soft limit may bind — fall back to ACH or wire on the same Stripe Invoice page.

Small business retail POS (boutique, coffee shop, hair salon). The point-of-sale system (Square, Shopify POS, Toast, Clover) handles the primary payments; the QR pattern adds an unattended self-service surface — a window sticker for after-hours appointment booking, a table tent QR for self-pay at the table, a check-out QR on the back of the receipt for loyalty signup with a discount. The QR codes for restaurants guide covers the dine-in patterns in more depth.

Subscription and recurring billing. A QR on the gym kiosk, the SaaS demo brochure, or the subscription-box card routes to a Stripe Checkout in subscription mode. Apple Pay surfaces on iOS, the customer's payment method gets tokenized, and the recurring billing starts immediately. Useful for converting in-person interest into committed subscribers without a hand-off to email or app download.

The pattern across all six is the same: the QR is a URL QR, the destination is a hosted checkout, the Apple Pay button surfaces automatically on iOS. The merchant work is choosing the checkout platform and writing the destination URL. The QR generation is the trivial step.

The mistakes are predictable enough that they cluster into five categories. Each one is the kind of thing a marketing intern does on a Friday afternoon and then nobody catches until the QR has been printed on 5,000 menus.

Do not link a QR to a screenshot of the Apple Pay logo. This sounds obvious and it happens constantly. A brand designer puts the Apple Pay logo PNG in the corner of the menu, generates a QR pointing at the PNG file's CDN URL, and prints. The customer scans, the camera opens to a static image, and there is no way to pay. The destination has to be a working hosted checkout URL, not a logo.

Do not point a QR at a wallet pass that has not been minted. PassKit wallet passes (loyalty cards, coupons, event tickets) require server-side mint via the PassKit framework, signed with an Apple Developer certificate. A QR linking to a *.pkpass URL works only if a properly signed pass file is hosted at that URL and served with the application/vnd.apple.pkpass MIME type. A common failure is generating the QR before the pass server is live, then printing, then trying to fix the pass server while the QRs are already on the table tents.

Do not assume the iPhone camera will deep-link into Apple Pay from any URL. It will not. The only URL the iPhone camera deep-links into the Wallet app for is the iOS 17 cash.apple.com/... shareable Apple Cash link. Every other URL opens in Safari. The Apple Pay button on the Safari checkout page is what brings up Apple Pay — not the QR itself.

Do not print a QR that is hard-coded to a campaign-specific URL on permanent collateral. This is the dynamic-vs-static trap. A donation QR printed on permanent signage with a static link to donate.charity.org/spring-campaign-2026 survives precisely until the spring campaign ends. After that the URL 404s, the QR is dead, and you have a sign that needs replacing. For long-lived signage, either use a dynamic QR where the destination can be updated, or hard-code to a permanent generic donate URL and route campaigns at the destination side via UTM parameters and landing-page logic.

Do not use a free QR generator that adds tracking domains you do not control. Some free generators wrap the destination URL in their own tracking domain (qr.example.com/abc123 → 302 redirect → your URL). If that vendor disappears, raises prices, or starts injecting ads, your printed QR is hostage. EZQR's static QRs are direct — the QR encodes your URL with no intermediary domain. Our permanent QR generator post covers the cancellation-survival policy in more depth.

The pattern across these five: the QR is the trivial part of the system, but the system has plenty of failure modes. Treat the QR like a piece of physical infrastructure that will outlive the campaign, and design the destination architecture accordingly.

If your destination is a permanent Stripe Payment Link, a Square Online checkout URL, or a Shopify checkout that will not change — a free static URL QR from EZQR is correct. The QR encodes the URL directly. There is no subscription, no vendor lock-in, no cancellation risk. The QR is permanent in the same way ink on paper is permanent. This covers a meaningful majority of small-merchant deployments.

If the destination URL will rotate — seasonal menus, campaign-specific donation pages, per-event ticketing, multi-product catalogs that get refreshed monthly — a dynamic QR is worth the $5/mo for EZQR Lite. Dynamic codes route through a short URL that you can re-point at a new destination without reprinting the physical QR. The trade-off is vendor dependency, which is why we publish a written cancellation policy that keeps your codes redirecting after you stop paying. See our permanent QR code generator post for the full breakdown.

The tier breakdown:

Free static — Single-product Payment Links, permanent donation URLs, contractor invoice QRs. No analytics, no destination editing, no vendor relationship. Right answer for ~40% of small-merchant Apple Pay QR deployments.

Lite $5/mo — Dynamic redirect, basic scan analytics, destination editing. Right answer for food trucks running seasonal menus, donation drives that swap campaigns, small businesses that want to know whether the window QR is being scanned at all.

Pro $10/mo — Multiple dynamic codes, per-code analytics, branded short link domain. Right answer for multi-location small businesses, nonprofits running multiple concurrent campaigns, restaurants with multiple table-tent QRs.

Max $20/mo — Bulk QR generation, API access, team accounts. Right answer for high-SKU retailers, franchise operations, and any merchant deploying QRs at hundreds of locations or per-SKU on packaging.

The critical point: the QR pricing is independent of the payment processor pricing. Stripe charges roughly 2.9% + $0.30 per Apple Pay transaction (the same as any other card method on Stripe). Square charges roughly 2.6% + $0.10 in-person and 2.9% + $0.30 online. The QR generator pricing is a flat monthly fee for dynamic codes; the payment fees are per transaction and unrelated to which generator you use. Plenty of merchants confuse "do I need a paid QR plan?" with "do I need a paid Stripe plan?" The answer to both is independent.

For most market stalls, food trucks, and donation drives, the right setup is: free static URL QR from EZQR pointing at a Stripe Payment Link. Total monthly cost: zero on the QR side, 2.9% + $0.30 on each successful transaction. The Apple Pay button surfaces automatically on iOS Safari. The Google Pay button surfaces on Android. Cards work as a fallback on desktop. One QR, three good outcomes, zero subscription burden.