RE: Payment Apps Proposal

Hi Adrian,

This is my first post to the group but I have been working in Worldpay with Nick and Matt on a reference implementation of this spec and have been following this group.

I have had a chance to review the Payment Apps proposal with the following feedback. We can discuss tomorrow at the appropriate time.


4.1 - Do we need to mention versioning of payment apps? For example, what happens when there are multiple versions of the same payment app registered on various user-agents? What if there is incompatibility somewhere in between? Is this a concern?

6.1 - Suggestion, icon could be a struct or multiple members allowing for { icon_regular, icon_list }. A regular sized icon to be displayed in detail view and also a smaller version shown in list views. perhaps regular isn’t an icon and more of a “banner” type image. Similar to app store type listings.

6.2 - Would using .register(“request_url”, empty) to unregister an app cause confusion. Is there a reason .unregister(“request_url”) has not been proposed?

Issue 112 - Recommended payment apps - Should this algorithm consider extra charges applied to certain payment methods. For example, airlines charge extra for credit and certain retailers may apply a surcharge for premium cards. This would be tedious to implement.

6.2

-Issue - Invocation Model: If this is all happening within the user agent, then isn’t Javascript/JSON more lightweight, less complex than HTTP?

- Issue - Registration of native payment apps: Is the user agent agnostic to type of payment application? Should it know if app is native, web based or other? Similar to Payment App Invocation (4.4) should something like this happen during registration to give the payment an opportunity to perform “first run” tasks. If not, I foresee a case where these type of tasks might run during the first payment attempt, and irritate the user if there are errors, thus increasing chances of “cart abandonment”. Propose two events that may work as follows:

- PreRegistrationComplete - User agent has performed initial registration, but will now invoke the payment app and provide an opportunity to initialise itself.

- AppInitComplete(bool) - Payment has completed initialisation with a boolean stating success/failure. User agent takes over and completes/abandons registration.

8.1 - Issue - Display algorithm. Suggest two lists, recommended and enabled. Recommended is first and in alphabetical order for fairness. Possibly merge both lists so the user only sees one list (UI implementation, out of scope?)


Regards,
Conor

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
Sent: 04 July 2016 12:51
To: Payments WG
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.

https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html

Some key concepts to note:

Scope
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.
Structure
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.
Issues/Notes
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.
Adrian
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.