What You Are Actually Scanning When You Scan an Apple Pay QR Code
Apple Pay has no QR payload. There is no string you can encode that means "pay me with Apple Pay", and nothing in Wallet produces a square for a cashier to scan. In a shop, Apple Pay is a contactless card transaction over NFC: the phone talks to the terminal by radio, the terminal talks to the card networks, and nothing visual passes between them at any point.
Which leaves a real question, because people do scan codes and then pay with Apple Pay, and they are not imagining it. Three different things get called an Apple Pay QR code. They work in three different ways, and only one of them is something a business can print.
Why the payment itself cannot be a code
A contactless card payment is a conversation. The terminal sends a challenge, the secure element in the phone answers with a cryptogram that is valid once, for that amount, at that terminal, and the transaction clears on the strength of that exchange.
None of that can be reduced to a printed string, because a printed string is replayable by definition and a payment authorization must not be. This is the structural split between a printed code and a tap, set out in full in QR codes versus NFC. A QR code is ink in a shape. It can carry an address, an instruction or a reference. It cannot carry a one-time response, because it cannot respond to anything.
So wherever a code and Apple Pay appear in the same transaction, the code is doing a different job: pointing at a page, identifying an account, or presenting a reference for a reader to look up.
The common case is a checkout page that offers Apple Pay
This is what nearly everyone means, and it is worth being precise about the chain.
A printed code carries an ordinary https URL, nothing more. That URL is a hosted payment page run by the merchant's payment provider. The customer scans it, Safari opens the page, and among the payment options on that page is an Apple Pay button, because the merchant has Apple Pay enabled for web payments. Apple Pay on the web requires the merchant's domain to be registered and verified with Apple, which a provider normally handles during setup. When all of that is in place and the customer is on a supported Apple device, the button appears. When any part of it is missing, the page simply shows card fields instead.
Two things quietly break this in the field. The first is the in-app browser: a code scanned from inside a social or messaging app opens in that app's embedded browser rather than in Safari, and the Apple Pay button may not appear there at all, so the customer sees a card form and assumes your sign is wrong. The second is that nothing on a printed code announces Apple Pay, so a customer looking for it has no reason to scan in the first place.
The code already in Wallet is a pass, not a payment
Open Wallet and some of what is in there displays a barcode: a boarding pass, an event ticket, a coffee shop store card, a gym membership. Those are Wallet passes, and a pass can carry a QR code, an Aztec code, a PDF417 or a linear barcode, whichever the issuer chose.
Because Wallet is also where your cards live, people reasonably call the barcode on a store card an Apple Pay code. It is not a payment instrument. It is an identifier that the merchant's own system resolves, working the same way as a ticket code at a venue gate. Some store cards do draw down a stored balance when scanned, which is why the confusion persists, but the money is moving on the merchant's rails and Apple Pay is not in the loop.
If you are on the other side of that, scanning a pass off somebody else's phone, the difficulties are screen brightness and glare rather than anything to do with payments.
A link to a person, not to Apple
The third case is a code carrying a personal payment link: a PayPal.me address, a Stripe payment link, a request page from a peer-to-peer app. Somebody scans it, a page or an app opens already addressed to you, and the payer finishes with whatever method that destination supports, which on an iPhone may well include Apple Pay if the provider offers it.
Apple Cash, the peer-to-peer balance that lives inside Messages on US accounts, is not part of this. Apple does not publish a QR format for requesting money into Apple Cash, so anything circulating as an Apple Cash code is pointing at something else. If what you want is a printed square that gets you paid by a stranger, the rails worth reading about are in Zelle and Cash App codes and, for small amounts, tip codes.
How the Camera app decides where a payment URL goes
Scan a payment link and sometimes Safari opens, sometimes an app does. The code is not choosing; it holds one string either way.
The mechanism is universal links. An app can claim a set of paths on a domain it controls by publishing an association file on that domain, which the device checks when the app is installed. Afterwards, when an https URL matching a claimed path is opened, iOS hands it to the app instead of the browser. Same URL, different destination depending on what the person has installed. Deep links versus universal links covers the setup and the ways it fails.
One practical consequence for anyone printing a payment code: encode a plain https URL and never a custom app scheme. A custom scheme fails in a way the customer cannot fix when the app is missing, while an https URL always has somewhere to land.
What to print
The useful configuration for a business taking payment from a printed square is short.
Point the code at your payment provider's hosted checkout, on your own verified domain if the provider supports that, and confirm with the provider that Apple Pay for web payments is switched on. Then test the actual printed code on a real iPhone in Safari, and check the button appears, before you order a hundred signs.
Label the sign with your business name and what the payment is for, not with an Apple Pay mark. Apple's marks come with their own usage rules, and "scan to pay" above your own name is clearer to a customer than a wallet logo anyway. The sign also inherits the risk every printed payment code carries: the overlay sticker described in the Zelle and Cash App notes works exactly the same way against a hosted checkout, so laminate it and scan your own sign each morning before the first customer.
And if you are looking for an Apple Pay scanner because you want to accept Apple Pay in person, the answer is not a scanner at all. It is a contactless reader, or the feature that turns a recent iPhone into one. A camera cannot take an NFC payment, and no printed code changes that.
So the square on your counter is a link, and what it should link to is a payment page you control on a domain your provider has verified. Build it as a dynamic URL code and the printed sign survives every change of provider, price and page you make behind it.
