Security & privacy
QR codes and PCI DSS — what is actually in scope
Merchant-presented QR codes such as UPI, PIX and EPC carry account references and payment instructions, not card numbers, so the code itself is largely outside PCI DSS cardholder-data scope. A QR that opens a card-payment page is different: that page is in scope for its owner, and printed codes need the same tamper checks as card terminals.
What PCI DSS protects
PCI DSS is the card industry's standard for protecting cardholder data — above all the primary account number (PAN), plus expiry, cardholder name and the sensitive authentication data around it. Scope follows the data: systems and processes that store, process or transmit card data are in; everything else is out. This page is educational orientation, not legal or QSA advice — scoping decisions belong with your assessor.
Merchant-presented payment codes are not card data
The reassuring structural fact: the big merchant-presented QR schemes are push-payment instructions built on account references, and no card number appears in the payload.
| Scheme | What the payload carries |
|---|---|
| UPI | A virtual payment address and payee name |
| PIX | A PIX key and merchant details |
| EPC / SEPA | An IBAN, payee name and amount |
| EMVCo merchant-presented | Merchant account information objects |
The customer's payment app reads the instruction and pushes funds from their side; the merchant's printed material never stores, processes or transmits a PAN. A standee with a UPI code on it does not become part of a cardholder data environment. (These payloads are bank-account references, which deserve care for their own reasons — just not PCI's.)
The absolute rule
Never encode a card number in a QR code. A QR payload is plain text readable by any scanner; a PAN in a code is unprotected cardholder data printed on paper, which is indefensible under any reading of the standard. No legitimate payment scheme asks for it.
Where a QR flow does touch scope
A QR code that opens a card payment page — a checkout URL, a hosted payment link — changes the picture. The code is just a URL, but the page it opens takes card data, and that page is in scope for whoever operates it. Using a hosted payment provider narrows your exposure the same way a redirect checkout does on the web, and recent PCI DSS versions have added explicit expectations around payment-page script management and tamper detection for exactly these pages. If your QR opens your own checkout, your checkout's obligations follow it there.
The skimming overlap
PCI's oldest physical discipline — periodically inspecting card terminals for skimmers — has a direct QR analogue. A sticker pasted over your payment code diverts payments exactly as a skimmer harvests cards, and the countermeasures rhyme: inspection routines and tamper-evident labels. Extend the terminal inspection habit to every printed payment code: feel for edges, rescan, and confirm the payee name your app shows matches the business.
Practical checklist
- Payment codes carry scheme payloads (UPI, PIX, EPC) or URLs — never card data.
- QR-opened checkout pages inherit your normal PCI obligations; hosted payment pages keep them with the provider.
- Printed payment codes get the terminal treatment: tamper-evident stock and a scheduled inspection, verified with a decode check.
- Payee name printed large beside the code, so substitution shows up on the customer's confirmation screen.
FAQ
Are QR code payments PCI compliant?
Scheme-based codes like UPI, PIX and EPC carry account references rather than card data, so the printed code sits outside cardholder-data scope. Compliance questions attach instead to any card-payment page a code opens, which carries its owner's normal PCI obligations.
Can I put card details in a QR code?
No. A QR payload is plain text that any scanner can read, so a card number in a code is exposed cardholder data. No legitimate payment flow requires it, and any that asks is a scam or a design error.
Does printing a UPI or PIX QR code put me in PCI scope?
The payload contains your payment address, not anyone's card number, so the printed material does not store, process or transmit cardholder data. Protect it against substitution attacks instead — that is where the real risk sits.
What about a QR code that opens a payment page?
The page, not the code, is the in-scope system. If it is your page, your PCI obligations apply to it as usual; if it is a hosted payment provider's, most of the burden stays with them, as in any redirect checkout model.
Try it — free, no signup
Related
- Are QR codes safe? — Scanning a QR code is safe in itself — it decodes text and nothing else. The risk is entirely in what you do next. A code cannot install software, dial,…
- QR codes and GDPR — when a scan becomes personal data — When a QR flow processes personal data under GDPR — scan logs, lawful basis, notices at the code, and the static-direct design that avoids processing entirely.
- Tamper-evident QR labels — Destructible vinyl, void laminates and holographic overlays make QR sticker swaps visible for pennies per label — if you pair them with a physical audit routine.
- QR code stickers placed over real ones — the overlay attack — The cheapest QR attack is a printed sticker pasted over a genuine code. Why it works, where it happens, and what venues can do to make overlays obvious.