cyberphone
commented
3 years ago Since the "second device" with a native payment application is pretty much the de-facto standard these days, most systems probably work as follows:
- If on a desktop: checkout with XYZ-pay using QR
- If on a mobile: checkout with XYZ-pay
An advantage with this arrangement is that you can use the same scheme at PoS terminals as on the desktop Web.
A minor "glitch" in this scheme is that the definition of mobile versus desktop is not entirely clear.
A problem with building on the payment sheet in the browser is that it haven't got much traction.
Goosth
halimnadergrace
Malvoz
ianbjacobs
In recent WPWG meetings, 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:
In short we have four flavours of use case.
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
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.
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 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.
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.