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.

Yup it’s that simple. That’s how QR code payments work in many countries in Europe.

I think my main point still stands: a Jony Ive type person would not be any help whatsoever.