# 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.

Source: https://useqr.app/docs/security/qr-codes-and-pci-dss · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## 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](/docs/payments/upi-qr-code-format) | A virtual payment address and payee name |
| [PIX](/docs/payments/pix-qr-code-format) | A PIX key and merchant details |
| [EPC / SEPA](/docs/payments/epc-qr-code-format) | An IBAN, payee name and amount |
| [EMVCo merchant-presented](/docs/payments/emvco-merchant-presented-qr) | 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](/docs/security/qr-code-stickers-placed-over-real-ones) diverts payments exactly as a
skimmer harvests cards, and the countermeasures rhyme: inspection routines and
[tamper-evident labels](/docs/security/tamper-evident-qr-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

1. Payment codes carry scheme payloads (UPI, PIX, EPC) or URLs, never card data.
2. QR-opened checkout pages inherit your normal PCI obligations; hosted payment pages
   keep them with the provider.
3. Printed payment codes get the terminal treatment: tamper-evident stock and a scheduled
   inspection, verified with a [decode check](/scan).
4. 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

- https://useqr.app/upi
- https://useqr.app/pix
- https://useqr.app/epc