Presumably if the payer displays and the recipient scans; however that's technically solved by the POS showing the target address, amount, and bill/reference ID; the shopper then scanning, visually confirming the amount, and approving.

A few seconds later the money can have arrived (depending on system): in Europe today with normal banks and their online banking apps: the QR-on-POS-screen concept using the standard SEPA instant push transaction encoding, to prompt a <10 seconds confirmed-or-aborted "Echtzeit-Überweisung" (German phrase; the standard works across some borders already though) that's polled by the recipient (to release the customer out of the store), with the obvious fallback of "guess you have to pay a different way".

If for example the self-checkout terminal would just print a bill that then has to be paid by scanning a code on the bill or bringing it to a manned till or such, before the gate releases you from the area just behind the self-checkout kiosks (in response to you scanning the bill at the gate), this could absorb the online banking app friction/delays and offer a fallback of presenting the bill and a backup credit card at one of those kiosks as soon as one frees up in addition to the mentioned human-till cash payment or whatever else they do if your card suddenly misbehaves.

QR Code is too cheap to produce, it is easy for scammer to just print a fake one and take your money.

https://www.straitstimes.com/tech/can-i-trust-this-qr-code-c....

Where I am most of the systems have an option to use static printed QR codes that the payer scans. This is easy to use for small businesses like bars since it requires zero hardware or staff training.

There have been reports of people printing their own QR codes and sticking them over the QR codes for businesses.

There are no more than using a plastic banking card. You still need to think what are you doing and what are you paying for and how much.