This specification relies on several other underlying specifications.
+
The Working Group has not yet agreed that the system should support recommended payment apps. - Inclusion might involve small changes to payment request API. See issue 112.
+ Inclusion might involve small changes to payment request API.- The difference between supported and enabled payment methods is one of design-time vs runtime consideration. - A Payment App supports all the payment methods it was designed to support however at runtime only a subset + The difference between supported and enabled payment methods is one of design-time vs runtime consideration. + A payment app supports all the payment methods it was designed to support however at runtime only a subset may be enabled due to configuration or other runtime requirements that may not have been met for all supported payment methods.
@@ -303,13 +307,14 @@We expect this data to be serialized as JSON.
The data passed between the browser and the payment app will serialized as JSON data.
To support registration and unregistration, the browser provides @@ -367,11 +376,12 @@
The start_url in the PaymentApp dictionary assumes an HTTP approach to communication between the browser and the payment app. The Working Group is currently exploring other approaches to communication as well; this particular proposal has been included to foster discussion. See also issue 110.
+ The start_url in the PaymentApp dictionary assumes an HTTP approach to communication between the browser and the payment app. The Working Group is currently exploring other approaches to communication as well; this particular proposal has been included to foster discussion. See also issue 110.
name membername member is a
- string that represents the name of the payment app as it
- is usually displayed to the user (e.g., among a list of other
- payment apps, or as a label for an icon).
- start_url memberstart_url is a string that
- represents the start URL, which is the URL that accepts
- payment request messages via HTTP POST.
- The start_url is the API entry point for the payment
- app and must have the same origin as the web application that attempts
- to register the payment app.
-
- The start_url is also the unique identifier for the payment app.
- If a payment app is already installed with the same start_url
- it will be replaced if a new payment app is registered with the same URL.
-
enabled_methods memberenabled_methods member
- lists the payment method identifiers of the enabled payment methods.supported_methods membersupported_methods member
- lists the payment method identifiers of the supported payment methods.name membername member is a
+ string that represents the name of the payment app as it
+ is usually displayed to the user (e.g., among a list of other
+ payment apps, or as a label for an icon).
+ start_url member
+ The start_url is a string that
+ represents the start URL, which is the URL that accepts
+ payment request messages via HTTP POST.
+
+ The start_url is the API entry point for the payment
+ app and must have the same origin as the web application that attempts
+ to register the payment app.
+
+ The start_url is also the unique identifier for the payment app.
+ If a payment app is already installed with the same start_url
+ it will be replaced if a new payment app is registered with the same URL.
+
enabled_methods memberenabled_methods member
+ lists the payment method identifiers of the enabled payment methods.supported_methods membersupported_methods member
+ lists the payment method identifiers of the supported payment methods.
+ navigator.payments.createPaymentRequest?The steps for installing a payment app are given by the following algorithm. The algorithm takes a PaymentApp argument (payment_app) as input. The algorithm, if successful, returns nothing; otherwise, it terminates prematurely and throws an exception.
-The following example shows how to register a payment app:
try {
@@ -452,16 +456,21 @@ registerPaymentApp()
console.error("Uh oh, something bad happened", err.message);
});
- + At each registration, the browser MUST replace all previous registration + information with the new registration information. Payment apps MAY use this + feature to provide updates.
++ We need to confirm the registration approach we wish to take. HTTP or JavaScript? What is the role of service + workers?
+This would + improve the user experience for UIs that provide direct selection of payment instruments (otherwise multiple + clicks required).
+What, if anything, should we say about + registering native payment apps? Should we publish separate "good practices" documents for different + platforms?
+ We anticipate that the Payment Method Identifier specification will define the PMI matching algorithm. This + specification will explain how to invoke that algorithm using data available from the Payment Request API input + and payment method information aggregated from:
+ Define browser display of payment app information in terms of the Payment Request API show() algorithm. +
+What information is needed by the browser to display selectable apps?
+Which of these scenarios do we expect to support through the set of technologies, and should we seek to harmonize the user experience across them? -
+ Which of these scenarios do we expect to support through the set of technologies, and should we seek to harmonize + the user experience across them? +
++ Current ideas for supporting 4 and 5 include (1) using the "recommended payment apps" approach of this spec (2) using payment method identifiers to designated recommended payment apps. +
+This section is informative.
-The following are examples browser display behavior.
+The following are examples of browser display behavior.
Once the user has selected a payment app, the browser is responsible - for preparing payment app invocation data, providing it to the payment app for processing, and returning the payment app response through the Payment Request API. This specification defines an HTTP-based mechanism to provide data to the payment app. Payment apps may use a variety of mechanisms to handle the incoming data, including server-side processing, or client-side interception of the HTTP message by a service worker.
+Once the user has selected a payment app, the browser is responsible for preparing payment app invocation data, + providing it to the payment app for processing, and returning the payment app response through the Payment Request + API. This specification defines an HTTP-based mechanism to provide data to the payment app. Payment apps may use + a variety of mechanisms to handle the incoming data, including server-side processing, or client-side interception + of the HTTP message by a service worker.
+ Let P be the intersection of payment methods supported by the payee and enabled by the selected app. Send the + data corresponding to P, as well as any global transaction data (total, etc.) to the payment app. The details + depend on discussions about the shape of the Payment Request API. +
The Working Group is still discussing
- how to invoke payment apps (e.g., via an HTTP POST
- to start_url or by executing a piece of JS provided
- at registration). The following algorithm assumes an HTTP POST
- approach. See issue 130.
+ The Working Group is still discussing how to invoke payment apps (e.g., via an HTTP POST to
+ start_url or by executing a piece of JS provided at registration). The following
+ algorithm assumes an HTTP POST approach.
text/html go to the section below on Payment App Displayapplication/json then go to the section below on Payment App Responsetext/html go to the section below on Payment App Displayapplication/json then go to the section below on Payment App ResponseCommunication mail fail at various points in the flow, including between server and payment app:
The Working Group is still discussing how payment apps are instantiated for user interaction.
- ++ The Working Group is still discussing how payment apps are instantiated for user interaction. +
+text/html, the
- browser renders the Response in a new top-level browsing
- context. Browser-based payment
- apps MUST run in a secure
- context.submitPaymentResponse (see below).text/html, the
+ browser renders the Response in a new top-level browsing
+ context. Browser-based payment
+ apps MUST run in a secure
+ context.submitPaymentResponse (see below).@@ -676,17 +692,14 @@Payment App Response
aPaymentResponsefrom JSON.
+ Define how the response from the payment app is returned to the merchant via the Payment Request API "user + accepts the payment request" algorithm (e.g., setting the payment repsonse in step 5 to be the payment app's + response). +