Hacker News new | past | comments | ask | show | jobs | submit login

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.

And the point you mentioned probably makes this a non-issue in many cases anyway:

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: