QR code payments at the counter

A QR payment moves the transaction onto the customer's phone: they scan a code, their app opens, and they authorise the payment from their side of the counter. The store may display a static code, or the register may generate one for the specific amount. It is common in some markets and patchy in the United States, where contactless cards already solved most of the same problem.

For a small store the decision is narrow: it is useful for specific situations and it carries one risk that has no equivalent at a card terminal.

How do the two versions differ?

A static code is printed and permanent. The customer scans it, types the amount themselves, and pays. It is cheap, it needs no integration, and it depends on the customer entering the right number.

A dynamic code is generated per transaction with the amount already in it. The customer cannot mistype, the payment reconciles to the sale automatically, and the register knows when it arrives. It requires the code to come from your system rather than from a sticker.

What is the risk with a static code?

Someone replaces it. A sticker over your sticker sends every payment that day to a stranger's account, and nobody at the counter notices because the customer's phone shows a successful payment and the customer walks away satisfied.

This has happened to market traders and small shops in several countries. The defences are physical: laminate it, place it where staff can see it, and check it at open and close. If you use a static code, the daily check is not optional.

Where does it genuinely help?

Three places. A customer whose card is not present but whose phone is. A payment taken away from the counter — a delivery, a market pitch, a table. And customers who use a specific app your neighbourhood has adopted.

It is a supplement rather than a replacement. In the United States a store that accepts contactless cards has already covered most phone-based payment, because wallets present as contactless cards.

How does reconciliation work?

That is the part to get right before adopting it. A dynamic code tied to your point-of-sale reconciles itself. A static code produces payments in an app with no link to your register, which means somebody has to match them manually at the end of the day.

Manual matching is where small stores lose money quietly. If the volume is more than a handful of payments a day, the integration is not optional either.

The end-of-day arithmetic is the honest test of whether the method suits you. A store that can tie every payment to a sale in five minutes is fine. One that carries a list of unmatched payments into the next week has found a slow leak rather than a payment method.

What about the money itself?

Settlement timing, fees and dispute handling depend entirely on the provider behind the code, and they vary far more than card processing does. Some settle instantly, some daily; some have dispute processes resembling card networks and some have almost none.

Read that before the rate. A slightly cheaper payment method with no dispute mechanism and unpredictable settlement is not cheaper. The general mechanics of the format are well described in the QR code overview, but the money questions are specific to whoever you sign with.