How do QR code payments work?

What a QR code payment is

A QR code is a two dimensional barcode, standardized by GS1, that stores far more than the stripe of a traditional barcode. In a payment, the code carries the information a payment app needs: an account reference, an invoice, or a link that resolves to one. A camera reads the pattern, the app decodes it, and the payment proceeds.

There are two directions this can run. In the merchant presented mode, the shop shows a code and the customer scans it. In the customer presented mode, the customer's app shows a code and the merchant's scanner reads it. Both end in the same place, with one party's device having read a code the other displayed.

How a QR payment clears

The flow is simple and it leans on the internet. A camera captures the code, the app decodes the payload, and the app contacts the payment provider over a network connection to move the money and return an approval. Without connectivity at the moment of the scan, most QR payments cannot complete, because the code itself is only a pointer, not an authorization.

Codes come in two kinds. A static code is printed once and always encodes the same destination, which is cheap but means the amount is keyed in by hand. A dynamic code is generated per transaction and can carry the exact amount and a one time invoice, which is safer and smoother but needs a screen to display it. The choice between them is a trade between cost and control.

QR code payment versus tap to pay

QR and tap to pay are often mentioned together as contactless options, yet they work on entirely different principles. One is optical and one is radio, and that difference decides how each behaves in practice.

Where QR wins and where it strains

QR wins on cost and reach. A payee needs only to print or display a code, and a payer needs only a camera, which every phone already has. That is why QR spread fastest where installing NFC readers everywhere was impractical. It asks very little of the hardware on either side.

It strains on the human factors. The customer has to open a camera, frame the code, and hold steady, and that fails in poor light, at an awkward angle, or on a scratched printout. It is also one code to one payee, so it does not help when many sellers are close together. The scan resolves a payment the customer has already lined up. It does not choose the provider for them.

QR code payment risks

The format itself is neutral, and GS1 defines it plainly. The risk lives in the destination the code points to. A printed code can be covered with a sticker that redirects payment, and a shared image can carry a link to a convincing fake. Because a human cannot read a QR code by eye, the customer is trusting that the square in front of them leads where it claims to.

Dynamic codes reduce the exposure, since a fresh, transaction specific code is harder to swap unnoticed, and good apps show the payee before confirming. But the underlying weakness is structural. An optical pointer to an online destination is only as safe as the destination and the display it appeared on.

Beyond scanning: proximity payment

Proximity payment removes the camera and the aiming that QR depends on. Instead of pointing a phone at a printed square, the customer is simply near the right provider, and presence does the work the scan used to do.

Parousya's patent US10657515B2 covers the mechanism. A provider broadcasts a short range signal, the customer's phone detects it and identifies the nearest provider, and the payment routes through a central server so the two devices never connect directly. There is no code to swap, because there is no code, and the method can pick the right provider among several rather than relying on the customer to have found the correct square. The divisional patent US11392923B2 adds identification without a payment, so a match can be confirmed by presence before any charge. Where QR points a camera at a destination, the proximity method senses the provider directly and lets the server carry the rest.