Comment by lxgr
2 years ago
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).
1 reply →