| I'd argue that the problem is that QR codes shouldn't be an 'app' problem, and yes there's a chicken-egg problem with PoS terminals verifying incoming bank payments but that's a separate issue. If you want to do account-to-account payments you can show the customer the account/routing number, amount & invoice ID - but obviously that's high friction and the customer needs to login to their account and send a payment with lots of manual data entry. Making yet another app, adding a financial intermediary, requiring you to link your bank account - these aren't solving the friction points. We already have bank apps, when I scan a QR code in an industry-wide format it should ask me or confirm which bank app to open and pre-fill all the payment information. So from my perspective, the problem is that FedNow in the US, and Open Banking in the UK - they could have just dictated "Banks must support EPC QR, or EMV QR code scanning and deep-links", and QR code payments would happen very quickly - even with NFC/RFID you can do passive scanning to achieve the same thing. * Choose Account
* Confirm details
* Press send That's about as easy as you can get for push payments, with a real industry-wide standard for communicating payment intents via NFC/QR. But both FedNow and UK OpenBanking are structured in a way which requires friction, and onerous regulation, through their clunky APIs - meaning you can't actually solve that problem on your own. |