Status: Draft material for discussing during WPWG virtual meeting 19-22 October 2020

Background

QR codes are a popular way to pay in various regions (e.g., Alipay and China Union Pay in China). The COVID pandemic appears to be driving interest in contactless QR payments in other regions as well.

Payment QR codes are utilized in various environments, such as presented in physical retailer, printed on banners or in magazines, on utility bills, and even carried around by people selling goods at a sports event. This mechanism is also becoming more relevant at digital checkout, since allows a checkout experience where a user does not need to enter any details to complete a payment and where the authentication can happen on a previously trusted environment.

Typically a payment QR code can only be scanned by a dedicated App. Since a merchant wants to enable the widest possible range of QR Codes, this may force them to offer a wide range of QR codes to consumers. This may cause a confusing checkout experience with a customer having to select from multiple QR codes. This problem is even bigger on the web, since the consumer is frequently not in the same country as the merchant, so an even wider set of QR codes has to presented for all the possible countries in which the consumer may be active.

Flows

There are two common payment flows involving QR codes:

• A Merchant presents a QR, which is then scanned by a Consumer from an app. The QR represents the transaction details and the consumer then approves the transaction on their phone. Payment could be submitted from a merchant or consumer perspective.
• A Consumer presents a QR Code, that is then scanned by a Merchant. In this case the merchant typically submits the transaction with the consumer's generation of the QR acting as consent for the transaction and the QR typically conveying the consumer's banking/store of value/card details.

EMVCo (www.emvco.com) has defined a QR Standard for both of these use-cases. Other organizations also enable them, including PayPal and China Union Pay. ApplePay is reportedly considering QR codes.

Focus of this Discussion

QR Codes are a mechanism to convey information between two devices. This can and has been used for many different use cases, such as Login Authentication, device pairing identity sharing, and more.

The focus of the WPWG discussion is on payments and enabling the existing Payment QR formats to work better on browsers.

As the web community we cannot influence interoperability between payment qr and payment networks. Our goal is to find out how to make it easier for a merchant and consumer to select a use-case and QR format that both support; ideally preventing a merchant from having to present various QR options to a consumer that has to select the right one, and who potentially has to download a different QR scanning app and sign up for that to complete their payment.

Questions

Currently browsers can generate QR codes, and even scan them.That's not a problem.

• What browser capabilities are needed?
• What are security risks when reading QR codes that the browser could help to mitigate? (e.g., see risks in wikipedia)
• Would it be valuable for browsers to recognize any QR code (standards) that encode information other than a URL?
• What activities are currently underway around QR codes? (e.g., EMPSA, PayPal, Alipay, EMVCo, Zapper, SnapScan, etc.)
• How could we remove the need for merchant to require a user to select from a range of qr formats? Could we support this by getting a consumer to indicate their preference and then that QR will be automatically presented for all other QR's. Could we make the generating and parsing of the QR easier?
• Should we consider the scenario where a QR cannot be scanned, since the 'scanning app/site' is on the same device. How can the QR perhaps detect that their is a QR processing capability on the same device and then redirect to that site or app with the qr details for processing.