W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2016

RE: Payment Apps Proposal

From: Telford-Reed, Nick <Nick.Telford-Reed@worldpay.com>
Date: Mon, 4 Jul 2016 12:41:02 +0000
To: 'Adrian Hope-Bailie' <adrian@hopebailie.com>, Payments WG <public-payments-wg@w3.org>
Message-ID: <F83606EEAA40AC4EA2919143B15B74C18A15209F@UKDC2-PC-MBX03.worldpay.local>
Thank you Adrian

I would be very grateful if members of the working group travelling to the Face to Face can review this document which will inform much of the discussion over the two days.


Nick Telford-Reed
e: nick.telford-reed@worldpay.com<mailto:nick.telford-reed@worldpay.com> | m: +447799473854 | t: +44 203 664 5069

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
Sent: 04 July 2016 12:51
To: Payments WG <public-payments-wg@w3.org>
Subject: Payment Apps Proposal

Hi all,
Sorry that this is late, we did promise to have this ready by 1 July but took the liberty of delaying and not sending it out over the weekend. There will be no major changes to this before we discuss it at the face to face on Thursday so please consider this the final draft for review.


Some key concepts to note:

This specification is intended to be a partner to the Payment Request API specification. It is focused on the browser specifically and how payment apps will be registered, updated and unregistered in browsers and also how browsers invoke payment apps and pass them a payment request and get back a payment response.
i.e. Payment Apps invoked via other APIs such as the HTTP API are not explicitly in scope for this document, however the invocation mechanism proposed (HTTP POST to a payment app endpoint URL) will likely be the same mechanism used in the HTTP API. How these specifications relate can be decided later as they become finalized.
The document is structured such that it follows the life cycle of a payment app. It addresses registration/update and deregistration and also the lifecycle of a payment request including matching, user selection, invocation and response back to the browser.
User Display - Payment Options
There have been a number of questions about how a payment app can expose payment instruments to the user up-front in the selection screen. This proposal includes the concept of "Payment Options" which are the options presented to a user when they are choosing how to pay.
A payment app will register one or more payment options (each with it's own label and icon for display purposes) and each option will be linked to a group of one or more payment methods.
The intention is for payment apps to use Payment Options to group related payment methods or as a way to represent specific payment instruments. This will also make it easier for browsers to render pricing for different payment methods and the same app.

App Invocation
This specification proposes that payment apps are invoked by the browser sending an HTTP POST to an endpoint URL defined by the app during registration. The payment app can either return an HTML response which is rendered by the browser or a JSON response which is parsed by the browser as the payment response (and passed directly to the calling website).
The advantage of this approach is that the payment app does not need to define UI (through HTML) if it is able to perform user interaction and payment auth through an alternative channel. For example a payment app may consist of a native mobile app and a remote web service. When the payment request is posted to the web service URL the webservice sends a push message to the user's mobile phone and the native app prompts the user to authorize the transaction following which the webservice responds to the browser with a JSON encoded payment response.
An offline/local only payment app can still be defined by installing a ServiceWorker during registration that has an event listener for the fetch event. When the browser attempts the HTTP POST the ServiceWorker will process the request locally and may respond without the request ever going online. (e.g. https://gist.github.com/adrianhopebailie/a79f0a32ac5af54dd7c0d2200b251bf3)
If the browser renders the HTML response then it will expose a DOM API for the website to submit a payment response.
There are a number of issues and notes captured both in the main repo issue list and as markers in the spec. Ideally we will adopt this proposal (either as is or with changes) and create a dedicated repo for it so we can migrate the existing issues to that dedicated list before the issue list grows too much more.

Next Steps
Please review this proposal BEFORE the face to face meeting. The goal at the face to face will be to adopt a proposal that covers payment apps (either this proposal or a counter-proposal) as an editor's draft and WG deliverable that we can begin to progress toward publishing in the near future.
This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.

Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
Received on Monday, 4 July 2016 12:41:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:18 UTC