[w3c/webpayments] QR use cases (#257)

In recent [WPWG meetings](https://www.w3.org/2020/11/12-wpwg-minutes.html), we have been examining the question of how to handle QR-code based payments in the context of Payment Request.

Typically QR-code experiences assume that a user device with a camera/scanner capability is available.  QR is used commonly in many countries as a way of initiating payment, including Alipay, WeChatPay, banking applications and EMV card payments. 

There appear to be a number of user cases which I have attempted to summarise in this diagram:
![image](https://user-images.githubusercontent.com/12412636/101766881-55ffac00-3adb-11eb-81c8-dada627904e0.png)

In short we have four flavours of use case.

1. The user is browsing on a first device (e.g. their desktop), reaches a point in a payment experience where the call to action is a QR code which resolves to a URL (WeChatPay appears to work this way). The user takes a second device (typically their mobile phone), opens an app (camera app, barcode scanner app, payment app or other native app), scans the QR code, and is taking into their payment experience

1. The user is browsing on a first device (e.g. their desktop), reaches a point in a payment experience where the call to action is a QR code which does not resolves to a URL (the EMVCo QR specification appears to work this way). The user takes a second device (typically their mobile phone), opens an app (camera app, barcode scanner app, payment app or other native app), scans the QR code, and is taking into their payment experience as long as the application knows how to handle the specific format. If not, the experience breaks.

1. The user is browsing on a first device (e.g. their desktop), reaches a point in a payment experience where the call to action is a QR code which resolves to a URL and the image includes meta data (for example, an <a> tag) which includes the URL. The user does not have a second device available, but can still click on the QR image, the URL is resolved by the browser, and the user is taken into their payment experience.

1. The user is browsing on a first device (e.g. their desktop), reaches a point in a payment experience where the call to action is a QR code which may or may not resolve to a URL but the image does not include meta data that allows the browser to act. The user cannot move that particular payment experience. The user is stuck. 

Use cases ① & ② are handed off outside the web environment. Use case ③ can be easily dealt with by the browser if the image that displays the QR code is appropriately tagged with URL meta data. However, use case ④ is not handled.

It's worth taking a second to consider where the QR codes might be displayed. Most commonly, the QR code would be shown on some kind of check out page as the "pay now" call to action. Should we consider also allowing the QR code to be shown in the payment sheet in the browser? This could be achieved by creating a generic "QR-based payment" payment method that included the image in its method data, so that the merchant could get the advantages of a clean single "pay" button that initiated payment request, and then jumped into the specific payment process for that method from the sheet. 






-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/257