> Tough problem. You need a Jony Ive on your team to help solve it.

I don't think so. A Jony Ive will not be in a position to solve the actual problem - what use is a non-universal payment mechanism to consumers and to retailers?

I read the linked page and don't see answers to the main adoption problem: how is the purchaser supposed to pay?

1. Purchaser has to download the app? Okay, but purchaser already has a few equivalents on their phone (Pix, etc) - added friction!

2. How does the App get money to make payment? Purchaser has to fund a new account? Okay, but that is more friction!

3. How does merchant accept the payment? Do they need a new payment terminal? Must their payment terminal be updated with new software? Even more friction!

I've worked in the EMV space, even quite recently, and merchants do not want to update and will only do so when forced to. Any new payment system (QR codes, etc) needs around 5 years (maybe more) before it is universally accepted.

The best way, where I am, to rollout a new payment terminal is to pitch it to the banks, who then offer it to the merchants who have accounts with them.

Adding new functionality to EMV terminals is a lot easier these days, since most of the new terminals are Android, and the vendors have app stores for third parties to write software for these terminals (Pax has Maxstore, etc).

Now, maybe I missed it, but I did not see this application on Maxstore, or some of the other stores. I could have missed it, because these stores have literally thousands of payment applications.

The long and short of it is, you came up with a non-universal payment method, and predictably it did not take off.

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.