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