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.
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).
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.
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.