Skip to main content
Commerce Security Authority
Category: Payment Ecosystem

EMV QR Codes

Also known as: EMV QR Code, EMV Merchant QR Code, EMV QR Codes (MPM/CPM)
Simply put

EMV QR Codes are two-dimensional, machine-readable barcodes used to initiate payments, commonly at the point of sale or for mobile payments. They follow a common specification set by EMVCo so that a single QR code can support a range of payment options for a merchant's customers.

Formal definition

EMV QR Codes are QR code payment specifications maintained by EMVCo that standardize the data format used to initiate QR-based transactions, promoting interoperability across payment methods and providers. EMVCo defines two models: a Merchant-Presented Mode (MPM), in which the merchant displays a QR code that the consumer scans, and a Consumer-Presented Mode (CPM), in which the consumer displays a code the merchant scans; per the evidence, the MPM specification can support both account-based and card-based payment. As a data-format and interoperability standard, EMV QR Codes govern how transaction data is encoded and exchanged, but they are distinct from PCI DSS and related PCI standards that govern the protection of cardholder data and sensitive authentication data; implementers should confirm scope, security, and data-handling obligations against the applicable PCI standards and the current EMVCo specifications rather than assuming any single label implies a given security outcome.

Why it matters

QR code payments have become an increasingly common way to facilitate mobile payments at the point of sale, and fragmentation across proprietary QR formats can create friction for merchants and consumers. EMV QR Codes address this by providing a common EMVCo specification so that a single QR code can support a range of payment options for a merchant's customers, promoting interoperability across payment methods and providers rather than locking a merchant into one wallet or scheme.

For payment teams, the practical significance is that EMV QR Codes standardize how transaction data is encoded and exchanged, but they do not by themselves define how cardholder data or sensitive authentication data must be protected. It is important not to assume that adopting the EMV QR Code label implies a particular security outcome. The specification is distinct from PCI DSS and related PCI standards, and the security and data-handling obligations for a given deployment depend on implementation and the applicable standards, not on the format label alone.

Because EMVCo defines two operating models — Merchant-Presented Mode and Consumer-Presented Mode — the data flow and the party that scans differs, which can affect where transaction data is handled. Implementers should confirm scope, security, and data-handling obligations against the current EMVCo specifications and the applicable PCI standards rather than treating interoperability and security as the same thing.

Who it's relevant to

Merchants and Merchant Risk Teams
Merchants adopting QR-based acceptance use EMV QR Codes to offer customers a range of payment options through a single code at checkout, in-store or online. Risk teams should confirm which mode (MPM or CPM) is deployed and where transaction data is handled, and should validate data-handling and PCI scope obligations against the applicable PCI standards rather than assuming the format label implies a given security outcome.
Payment Processors and Acquirers
Processors and acquirers integrating QR acceptance rely on the EMVCo specification for interoperability across payment methods and providers, including account-based and card-based payment supported by the MPM specification. They should implement against the current EMVCo specifications and confirm the security and data-handling responsibilities that fall to each party in the flow.
Compliance Officers
Compliance teams need to distinguish the EMV QR Code specification, which is a data-format and interoperability standard maintained by EMVCo, from PCI DSS and related PCI standards that govern protection of cardholder data and sensitive authentication data. Scope, security, and data-handling obligations should be assessed against the applicable PCI standards and current EMVCo specifications for the specific deployment.
Security Engineers
Engineers designing or reviewing QR payment integrations should account for how transaction data is encoded and exchanged in Merchant-Presented versus Consumer-Presented Mode, and where cardholder data or sensitive authentication data may be present. Security controls are determined by implementation and the applicable PCI standards, not by the EMV QR Code label, so verify obligations against the current published specifications.

Inside EMV QR Codes

EMVCo QR Code Specifications
EMV QR Codes are defined by EMVCo specifications covering two models: merchant-presented mode (the merchant displays a QR code the consumer scans) and consumer-presented mode (the consumer displays a QR code the merchant scans). Each mode has a distinct data structure and flow.
Data Objects and Payload Format
The QR code encodes a structured payload of data objects using an identifier-length-value format, including elements such as payload format indicator, merchant account information, transaction currency and amount, country code, and merchant identifiers. Exact fields depend on the mode and implementation.
Payment Credentials Carried
Depending on the deployment, the payload may reference an account or token rather than exposing a full PAN. Where a token is used, it is distinct from encryption or truncation; its effect on data handling depends on the tokenization implementation and validation, not on the presence of a QR code alone.
Merchant-Presented vs. Consumer-Presented Mode
Merchant-presented mode typically carries static or dynamic merchant and transaction data for the consumer's app to process. Consumer-presented mode carries a token or credential generated by the consumer's app that the merchant reads at the point of interaction. The two modes have different data exposure and risk characteristics.
Relationship to Other Standards
EMV QR Code specifications are separate from PCI DSS, PCI P2PE, PCI PIN, and PCI 3DS. Any cardholder data or sensitive authentication data handled in a QR-based flow remains subject to the applicable PCI standards; the QR specification governs the code format, not the security validation of the surrounding environment.

Common questions

Answers to the questions practitioners most commonly ask about EMV QR Codes.

Does using EMV QR codes make a transaction PCI DSS out of scope automatically?
No. The use of an EMV QR code format does not by itself remove a system from PCI DSS scope. Scope depends on whether cardholder data or sensitive authentication data is present, transmitted, processed, or stored, and on how the implementation is designed and validated. Some QR-based flows may reference tokens or other data elements rather than a raw PAN, but whether that reduces scope depends on the specific implementation, the data actually handled, and the validation performed, not on the QR label alone. Confirm scope against the current published PCI DSS and your own data flows.
Does an EMV QR code payment prevent fraud because it uses the EMV specification?
No. Referencing the EMV specification does not mean a QR-based payment eliminates fraud. EMV QR code specifications define data formats and structures for presenting or consuming payment data via QR codes; they are distinct from EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication, which address different risks at different points in a transaction. A QR code flow may or may not incorporate those additional controls. Any fraud mitigation depends on the full set of authentication and risk controls applied, and no single control guarantees prevention.
What data might be carried in an EMV QR code, and how does that affect handling requirements?
Depending on the flow, an EMV QR code may carry data elements used to initiate or complete a payment. If a flow includes cardholder data such as a PAN, that data must be handled under applicable PCI DSS controls. Sensitive authentication data, such as full track data, card verification values, or PIN data, must not be stored after authorization even when encrypted. Whether a given QR implementation carries a PAN, a token, or other reference data determines the applicable handling controls, so review the actual data elements in your specific implementation.
How should merchants approach whether a QR flow uses a raw PAN or a token?
Merchants should identify the actual data elements exchanged rather than assume. Tokenization, encryption, truncation, masking, and hashing transform data differently, and their effect on scope and handling depends on implementation and validation, not on the label. If a QR flow references a token rather than a raw PAN, the token's characteristics and how it is generated, mapped, and secured determine the resulting handling obligations. Document the data flow and confirm the treatment with the relevant standard and your assessor.
Which standards and network rules should teams consult when implementing EMV QR code payments?
Teams should distinguish the applicable requirements: PCI DSS governs the protection of cardholder data environments, while related standards such as the PCI Software Security Framework, PCI PIN, PCI P2PE, and PCI 3DS address separate areas and may or may not apply depending on the design. EMV QR code data formats are defined by the relevant EMV specifications. Acceptance rules, liability treatment, and dispute handling are governed by card brand and network rules, which vary by region and change over time. Confirm each against its current published source.
What limitations should teams keep in mind when relying on QR-based payment flows for risk reduction?
Teams should treat QR-based flows as one part of a layered approach. A QR flow does not inherently perform cardholder authentication, and its role in mitigating card-not-present fraud, account takeover, or other fraud types depends on which additional controls are integrated. Detection controls applied around these flows involve false-positive and false-negative trade-offs. Consider what is out of scope for the QR format itself, and combine it with appropriate authentication, monitoring, and data protection controls validated against the current standards.

Common misconceptions

An EMV QR Code payment is inherently secure because it uses a QR code and involves EMVCo.
The EMV QR Code specification defines a data format and modes of interaction, not a comprehensive security guarantee. Security depends on how credentials are represented (for example, tokenized versus exposed), how data is transmitted and stored, and whether the surrounding environment meets the applicable PCI standards. The QR format alone does not determine PCI DSS scope.
EMV QR Codes provide the same chip authentication protections as an EMV contact or contactless card transaction.
EMV chip authentication and EMV QR Codes are different mechanisms addressing different flows. A QR-based flow does not automatically deliver the cryptographic card authentication associated with EMV chip transactions. Authentication in a QR flow depends on the specific implementation and any additional controls layered on top, and no single control eliminates fraud.
Because a QR code can carry a token instead of a PAN, using EMV QR Codes removes the environment from PCI DSS scope.
Tokenization is distinct from encryption, truncation, masking, and hashing, and its effect on scope depends on implementation and validation rather than on the label. A QR flow may still process cardholder data or sensitive authentication data at some point; scope reduction must be assessed against the current PCI DSS, not assumed from the use of a QR code or a token.

Best practices

Identify which mode is in use (merchant-presented or consumer-presented) and map exactly what data is carried in the payload, distinguishing any cardholder data from sensitive authentication data, and confirm that sensitive authentication data is not stored after authorization even when encrypted.
Assess how the flow affects PCI DSS scope based on the specific implementation and validation of any tokenization, encryption, truncation, or masking, rather than assuming scope reduction from the QR format or token label alone.
Do not rely on the QR-based flow to provide EMV chip authentication protections; determine what authentication is actually delivered and consider layering additional controls such as strong customer authentication where appropriate to the risk.
Confirm all requirements against the current published EMVCo QR Code specifications and the current PCI standards, since requirement numbering and wording differ between versions.
Apply the relevant separate PCI standards to the components involved (for example PCI PIN, PCI P2PE, or PCI 3DS) where their controls apply, rather than treating PCI DSS as covering every element of the flow.
Evaluate fraud exposure for the specific flow, recognizing that card-not-present and card-present risks differ, and that liability shift and chargeback rules are governed by card brand and network rules that vary by region and change over time.