W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > September 2017

RE: Singapore to develop common QR code for payments

From: David Ezell <David_E3@VERIFONE.com>
Date: Fri, 1 Sep 2017 16:59:04 +0000
To: Ian Jacobs <ij@w3.org>, KETELS Kris <Kris.KETELS@swift.com>
CC: Web Payments IG <public-webpayments-ig@w3.org>
Message-ID: <SN1PR0301MB16155414C7A23A0D1178AC53C8920@SN1PR0301MB1615.namprd03.prod.outlook.com>
Hi Kris and Ian:
Ian - thanks for the links.
Kris - thanks for the question.

One way (somewhat accurate) to think about the EMVCo QR code is as being similar to a "contactless" EMV transaction.
That means that once the hardware specific exchanges (ICC*, NFC, or Optical) are complete, there remains
Information that should be able to be handled by the Payment Request API.  Note that information flow from
a device (card) into a place where it can be used hasn't been a strong focus to this point.

Best regards,
David

*Note that ICC is bi-directional, so it's less straightforward.

> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Friday, September 01, 2017 12:19 PM
> To: KETELS Kris
> Cc: Web Payments IG
> Subject: Re: Singapore to develop common QR code for payments
>
>
> > On Sep 1, 2017, at 3:26 AM, KETELS Kris <Kris.KETELS@swift.com> wrote:
> >
> > Dear all,
> >
> >
> >
> > Do anyone know of other similar initiatives like this? Is this stg for the IG?
> > https://www.finextra.com/newsarticle/31011/singapore-to-develop-common

> > -qr-code-for-payments?utm_medium=dailynewsletter&utm_source=2017-8-
> 30
>
> Hi Kris,
>
> I’m happy to share a few thoughts here about QR codes and Web Payments! I
> welcome corrections to the description below.
>
> Assuming that a QR code includes the necessary information to identify an
> origin and populate a payment request, here is how a user experience could
> work using Web standards (that are currently not yet widespread):
>
> 1) The user starts an app that reads QR codes. The app could either be native
> or Web.
>     If a Web app, it will use Media Capture and Streams [1] to get access to the
> camera (with
>     user permission).
>
> 2) The app translates the QR code into a URL with enough data to build a
> payment request.
>
> 3) The app causes the browser to open that (checkout) page.
>
> 4) The user pushes the buy button, which invokes Payment Request API [2].
> After that,
>     it’s the PR API user experience.
>
> Comments:
>
> - Variation: User is already shopping on merchant.com and pushes a button to
> scan QR codes
>   (e.g., to populate a shopping cart). When done, the user pushes the “buy”
> button.
>
> - There are JavaScript libraries to decode QR codes. While it is possible that
> encoding and
>   decoding QR codes could become built-in browser capabilities, I have not
> heard enthusiasm
>   from browser makers to move in that direction.
>
> Questions:
>
>  - Of the two variations of user experience describe above, is either realistic?
> Are there others?
>
>  - Is there value in publishing a QR code “vocabulary" that would make it easy
> for a Web site to build a payment request?
>    (Cf the related EMVCo spec [4]).
>
> Ian
>
> [1] https://www.w3.org/TR/mediacapture-streams/

> [2] https://www.w3.org/TR/payment-request/

> [3] https://www.iso.org/standard/62021.html

> [4] https://www.emvco.com/terms-of-use/?u=wp-

> content/uploads/documents/EMVCo-Merchant-Presented-QR-Specification-
> v1_0.pdf
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/

> Tel: +1 718 260 9447
>
>
>
>
>

*********************************************************
This electronic message and any attachments are intended only for the use of the addressee. The information in this electronic message is confidential and proprietary, and may include privileged information. If you are not the intended recipient, please delete this electronic message and any attachments and notify the sender of the error. Please be aware that any unauthorized use, dissemination, distribution or copying of this message or any attachments is strictly prohibited.
Received on Friday, 1 September 2017 17:00:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:59 UTC