QR Code Phishing and PCI DSS

QR code phishing, sometimes called quishing, is phishing with the link carried in a QR code instead of in text. The FBI warned in January 2022 that criminals were tampering with both digital and physical QR codes to send people to sites that take login and financial details, to deliver malware, and to redirect payments (FBI public service announcement I-011822-PSA). This article covers the two ways it reaches people, which PCI DSS requirements it touches, and what a business that uses QR codes for payment can do.

Two routes

In a message. An email, letter or parcel carries a QR code that claims to lead to a delivery update, a document to sign, a security check or an unpaid bill. The FBI warned in July 2025 about unsolicited packages containing QR codes used to start fraud schemes (I-073125-PSA). The code is usually scanned with a phone, so the page opens away from the work computer and whatever protections it has.

On a printed code. A sticker is placed over a genuine code on a sign, a parking meter, a restaurant table or a shop's pay-here card. The FBI's 2022 announcement describes exactly this for payments: a business gives customers a code for a payment site, and a criminal replaces it so the payment goes to them.

What PCI DSS asks

No PCI DSS requirement names QR codes. Where a QR code is used to phish the entity's own personnel, the phishing requirements apply as they do to any other phishing:

• 5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing attacks. A QR code carries its link as an image, so when choosing or checking the mechanism, confirm how it handles links inside images.
• 12.6.3.1 requires security awareness training to cover phishing and social engineering. A QR code in an unexpected message belongs in that training alongside the link and the attachment.
• 12.10.1 requires an incident response plan. A member of staff entering credentials on a page reached by a QR code is an incident, the same as one reached by a link.

PCI DSS Requirement 5.4.1: protecting personnel against phishing covers these in detail.

A business that displays QR codes for payment

When a customer scans a merchant's printed code and pays on a page run by a payment provider, a swapped code sends the customer to the attacker instead. The customer's card data then never reaches the merchant or the provider, so the merchant's own controls do not see it. The protection is practical:

• Print the destination next to the code, so a customer can compare it with what the phone shows before paying. Many phone cameras preview the address before opening it.
• Mount codes so a sticker on top is noticeable, for example behind a cover, or displayed on a screen instead of paper.
• Check the codes as part of a routine, the way 9.5.1.2 asks staff to inspect card terminals for tampering, and scan one to confirm it still opens the right page.
• Offer another way to pay for customers who would rather not scan a code.

How a QR payment channel is validated depends on how it is built, and is for the acquirer to confirm. Two points help. If the code leads to a page the merchant controls, that page is a payment page and the controls on its scripts in 6.4.3 and 11.6.1 may apply, as Understanding PCI DSS 11.6.1 explains. If it leads straight to a page hosted by a PCI DSS compliant provider, the nearest case the Council describes is a link sent to a customer by email that takes them to the provider's site to pay, which its FAQ 1588 treats as fully outsourced payment.

For anyone scanning a code

• Look at the address the phone shows before opening it, and do not pay or log in if it is not the organisation you expect.
• Be wary of a code on a sticker, or one that arrives in a message or parcel you did not expect.
• Do not install an app from a QR code. Use the phone's app store.
• If you entered a password, change it; if you paid, call your bank.

How to recognise and avoid phishing attacks covers the wider warning signs.