That would have been nice, but not backwards compatible with millions of POS terminals and payment processing setups out there.

One big advantage of contactless card payments as implemented in most countries is that you can seamlessly introduce it, making it look like a regular chip or even magnetic stripe transaction to the POS and everything behind it.

With the recent new QR systems around Southeast Asia, they got around this by adding support to existing terminals with just a software update. They print out the QR code for the payer to scan. It’s a bit janky, but works until the merchant updates their terminal to one with a screen capable of displaying the QR.

It might work for some use cases, but being able to receive a payment is often only part of the story. There's reconciliation, settlement, refunds, tax reporting, handling of/liability for fraud disputes and much more.

For example, consider a rental car agency or a hotel reservation. These usually make extensive use of the pre-authorization "feature" [1] of credit cards to reserve a deposit without actually charging it before the final billing amount is known. After a rental car is returned, toll charges are often posted to the card weeks or months after the rental.

QR payment systems often don't support these use cases at all (since they're usually payer-initiated and confirmed); and even if they did, chances are that their API semantics are sufficiently different from credit cards as to require significant reworking of the POS and/or backoffice systems of the merchant.

[1] It's actually more of a historical artifact of how authorization and clearing/settlement used to, and to some extent still do, run over almost completely independent rails, but for some use cases, this can actually simplify things.

> It might work for some use cases, but being able to receive a payment is often only part of the story. There's reconciliation, settlement, refunds, tax reporting, handling of/liability for fraud disputes and much more.

Disputes are quite simplified by the fact that this is always a "customer present" transaction; the platforms generally simply do not provide the ability for the payer to dispute and this is understood by the payer.

Refunds are fully supported by every QR system in wide use. Reporting and reconciliation is different but not a problem; the QR service providers all integrate with POS systems and accounting systems.

In many cases in these markets, merchants and consumers both went from dealing mostly with cash to dealing mostly with QR, so there is less of a legacy issue.

> For example, consider a rental car agency or a hotel reservation. These usually make extensive use of the pre-authorization "feature" [1] of credit cards to reserve a deposit without actually charging it before the final billing amount is known. After a rental car is returned, toll charges are often posted to the card weeks or months after the rental.

> QR payment systems often don't support these use cases at all (since they're usually payer-initiated and confirmed); and even if they did, chances are that their API semantics are sufficiently different from credit cards as to require significant reworking of the POS and/or backoffice systems of the merchant.

Bharat QR (India), Alipay & WeChat Pay (China) and QRIS (Indonesia) all support pre-auth and are widely accepted for hotels and car rentals in their respective markets.

Sure, the APIs are different, but that hasn't prevented almost universal adoption in the world's largest and second-largest markets (India & China) and rapid ongoing adoption in the world's fourth-largest (Indonesia).

> Bharat QR (India), Alipay & WeChat Pay (China) and QRIS (Indonesia) all support pre-auth and are widely accepted for hotels and car rentals in their respective markets.

Interesting, I didn’t know that!

Anyway, all requirements I mentioned definitely all feasible using QR codes (and apparently it’s already been done) – I just don’t think it would be a drop-in replacement at the terminal-to-POS interface if the existing terminal expects a credit/debit card like interface.

The point you mentioned probably makes this a non-issue in many cases though:

> In many cases in these markets, merchants and consumers both went from dealing mostly with cash to dealing mostly with QR, so there is less of a legacy issue.

This is how it works in a lot of places, including everywhere in China and parts of south east Asia. The merchant’s device displays a QR code, which you scan with your phone. The details of the transaction are shown on your screen, and you can select things like where the money should come from, sometimes discounts etc, and then tap to complete the transaction.

so that means that all payment methods must be stored on your phone? How is that any safer than Apple Pay or PayPal?

In the case of Bharat QR (India) or QRIS (Indonesia), it's just a standard which various payment methods implement. So you can choose to scan the QR with the app of the bank that you want to pay from, or with a mobile wallet app (those wallets themselves usually being able to be linked to bank accounts, cards, etc).

In the case of Alipay and WeChat Pay (China), the QR codes are proprietary to the mobile wallet app, but both also support connecting the wallet to bank accounts and cards.

When using a card the safety characteristics are quite similar to Apple Pay or PayPal: the card details are neither stored on your phone nor transferred to the merchant. But in these markets few people use cards; they either pay directly from their bank account using these QR systems, or they keep a balance in a mobile wallet and pay from that.

EMV is in a substantially better position than online credit card payments: the terminal cannot clone a card (though it sees a PIN and card number, it does not see the CVV, so it is not useful for online transactions, and the card contains private keys which are relatively hard to extract. The only remaining hole is creating a magstripe card, but these are becoming rare even in the US). The card does see and verify the transaction. The two main issues are the PIN entry onto the pad (which exposes some information, though with NFC this hole is somewhat removed), and the fact that the payment is still initiated by the terminal, with no way for the user to independently see the transaction amount before authorising the transaction (NFC on a phone can in principle fix this, though in a somewhat annoying manner: it could refuse the transaction the first time, then prompt the user, and accept the next transaction for the same amount).

at least in this respect the now prevalent UPI (unified payments interface) used throughout India fares better.

each merchant -- even a roadside vendor or a mobile hawker of wares -- displays a QR code that has their payment account details / UPI handle.

Customer uses their own phone and UPI payment app to scan that QR code, look at the merchant details displayed, punch in the amount to pay and authorize the payment using their PIN.

(a variation on this is: hand-held POS terminals display a QR code that also encodes the amount to be paid so that the customer doesn't have to punch in the exact amount).

and since this is a unified protocol the users are not stuck with a single payment app or a single payments processor or a single bank network to transact with each other. QR codes are universal - can be scanned by any UPI app.

I have other reservations about the digital trail this leaves for every petty transaction of your life -- and the small risk of a petty vendor being able to harass you later based on the information you leave in their records.

If we don't trust the government -- this makes us jittery about how much they can track you or even cripple your life by disabling a few key things that you need this all to work smoothly.

Those risks aside,this UPI system has been a boon to ease of transactions (without worrying about handling cash and change) across the country. Net positive with some scope for improving privacy protections.

> look at the merchant details displayed, punch in the amount to pay and authorize the payment using their PIN.

Feels like a lot of work. I prefer just tapping my phone and then getting the amount charged pushed to my phone and watch so I can complain if its wrong whilst I'm at the checkout.