Payment Method Identifiers
-The Payment Method Identifiers [[METHODIDENTIFIERS]] specification defines the format of +
The Payment Method Identifiers [[METHOD-IDENTIFIERS]] specification defines the format of Payment Method Identifiers.
Payment Method Identifiers
Payment Request API
- The Payment Request API [[PAYMENTREQUESTAPI]] specification defines the API that makes a + The Payment Request API [[PAYMENT-REQUEST-API]] specification defines the API that makes a user agent the conduit for messages exchanged between web pages (or applications) and payment apps. The web page supplies a list of payment methods accepted by the merchant. The Payment Mediator matches those against payment methods supported by the user’s registered Payment Apps. @@ -293,7 +296,7 @@
Payment Method Specifications
to that method.We expect some message definitions to be shared amongst different - payment apps. One example is the [[BASICCARDPAYMENTS]], which defines a payment + payment apps. One example is the [[BASIC-CARD-PAYMENTS]], which defines a payment method identifier, method-specific request data, and method-specific response data for a basic card payment method. We expect this specification to be a model for other payment method specifications.
diff --git a/specs/basic-card-payment.html b/specs/basic-card-payment.html index 84e45817..1e60d98c 100644 --- a/specs/basic-card-payment.html +++ b/specs/basic-card-payment.html @@ -36,35 +36,38 @@ issueBase: "https://github.com/w3c/browser-payment-api/issues/", localBiblio: { - "PAYMENTARCH": { + "PAYMENT-ARCH": { title: "Payment Request Architecture" - , href: "architecture.html" + , href: "https://w3c.github.io/browser-payment-api/specs/architecture.html" , authors: [ "Adrian Bateman" , "Zach Koch" , "Richard Barnes" + , "Roy McElmurry" ] , status: "ED" }, - "PAYMENTREQUESTAPI": { + "PAYMENT-REQUEST-API": { title: "Payment Request API" - , href: "paymentrequest.html" + , href: "https://www.w3.org/TR/payment-request/" , authors: [ "Adrian Bateman" , "Zach Koch" , "Richard Barnes" + , "Roy McElmurry" ] - , status: "ED" + , status: "WD" }, - "METHODIDENTIFIERS": { + "METHOD-IDENTIFIERS": { title: "Payment Method Identifiers" - , href: "method-identifiers.html" + , href: "https://www.w3.org/TR/payment-method-id/" , authors: [ "Adrian Bateman" , "Zach Koch" , "Richard Barnes" + , "Roy McElmurry" ] - , status: "ED" + , status: "WD" } } }; @@ -82,7 +85,7 @@The Basic Card Payment specification describes the data formats used by the - PaymentRequest API [[!PAYMENTREQUESTAPI]] to support payment by payment cards such as + PaymentRequest API [[!PAYMENT-REQUEST-API]] to support payment by payment cards such as credit or debit cards.
Introduction
This specification is a Payment Transaction Message Specification used by the PaymentRequest API - [[!PAYMENTREQUESTAPI]] to support payment by payment cards such as credit or debit cards. It is intended + [[!PAYMENT-REQUEST-API]] to support payment by payment cards such as credit or debit cards. It is intended to provide compatibility for merchants who currently request card details from customers to ease adoption of the PaymentRequest API.
@@ -125,14 +128,14 @@Dependencies
- The Payment Request API [[!PAYMENTREQUESTAPI]] requires that merchants supply a list + The Payment Request API [[!PAYMENT-REQUEST-API]] requires that merchants supply a list identifiers for supported payment methods. This document defines those identifier strings and how they are created.
@@ -367,7 +368,7 @@Identifier equivalence
Dependencies
-A reverse domain name is defined by [[REVERSEDOMAINS]]. For example, com.example.somemethod.
A reverse domain name is defined by [[REVERSE-DOMAINS]]. For example, com.example.somemethod.
Discussion topics
@@ -415,7 +416,7 @@Issues
The following issues are tracking aspects of the payment method identifier specification:
Should the format of the identifiers be URLs (e.g. http://example.com/paymentmethod) or reverse host name (e.g. com.example.paymentmethod) or some other extensible syntax?
+Should the format of the identifiers be URLs (e.g., http://example.com/paymentmethod) or reverse host name (e.g., com.example.paymentmethod) or some other extensible syntax?
If the identifier is a URL, should there be a resource that can be fetched from the URL?
Is there a need to describe the payment method at the URL or provide some other information?
This specification describes a web API to allow merchants (i.e. web sites selling physical or digital goods) to easily accept payments from different payment methods with - minimal integration. User agents (e.g. browsers) will facilitate the payment flow between + minimal integration. User agents (e.g., browsers) will facilitate the payment flow between merchant and user.
Introduction
over and over again. Likewise, it is difficult and time consuming for developers to create good checkout flows that support various payment schemes. -This specification describes an API that allows user agents (e.g. browsers) to act - as an intermediary between the three key parties in every transaction: the merchant (e.g. an - online web store), the buyer (e.g. the user buying from the online web store), and the - Payment Method (e.g. credit card). Information necessary to process and confirm a +
This specification describes an API that allows user agents (e.g., browsers) to act + as an intermediary between the three key parties in every transaction: the merchant (e.g., an + online web store), the buyer (e.g., the user buying from the online web store), and the + Payment Method (e.g., credit card). Information necessary to process and confirm a transaction is passed between the Payment Method and the merchant via the user agent with the buyer confirming and authorizing as necessary across the flow.
In addition to better, more consistent user experiences, this also enables web sites to take - advantage of more secure payment schemes (e.g. tokenization and system-level authentication) + advantage of more secure payment schemes (e.g., tokenization and system-level authentication) that are not possible with standard JavaScript libraries. This has the potential to reduce liability for the merchant and helps protect sensitive user information.
The API described in this document forms part of the Payment Request system described in - the Payment Request Architecture [[PAYMENTARCH]] document.
+ the Payment Request Architecture [[PAYMENT-ARCH]] document.Goals
@@ -179,11 +181,11 @@Dependencies
PaymentRequest interface
Promise<PaymentResponse> show(); void abort(); - readonly attribute ShippingAddress? shippingAddress; + readonly attribute PartialShippingAddress? partialShippingAddress; readonly attribute DOMString? shippingOption; /* Supports "shippingaddresschange" event */ @@ -242,7 +244,7 @@PaymentRequest interface
A web page creates a PaymentRequest to make a payment request. This is
- typically associated with the user initiating a payment process
+ typically associated with the user initiating a payment process
(e.g., selecting a "Power Up" in an interactive game, pulling up to an automated kiosk in a parking structure,
or activating a "Buy", "Purchase", or "Checkout" button).
The PaymentRequest allows the web page to exchange information with the
@@ -276,11 +278,11 @@
PaymentRequest constructor
method specificdata.
PaymentRequest constructor
data into request@[[\data]].shippingAddress attribute on request to null.
+ Set the value of the partialShippingAddress attribute on request to null.
shippingOption attribute on request to null.
@@ -516,16 +518,20 @@ abort()
State transitions
The internal slot [[\state]] follows the following state transitions:
-
shippingAddress
+partialShippingAddress
- shippingAddress is populated when the user provides a shipping
- address. It is null by default.
+ partialShippingAddress is populated when the user provides a shipping
+ address before payment has been approved. It is null by default.
When a user provides a shipping address, the shipping address changed algorithm runs.
+ A PartialShippingAddress should provide minimal information to identify potential shipping
+ options. For instance, in the United States, the state and postal code would be specific
+ enough to determine shipping options, but would not leak sensitive user information
+ to the client before the user has approved a payment.
onshippingaddresschange is an EventHandler for an
@@ -605,13 +611,13 @@
CurrencyAmount
required DOMString value; }; -
A CurrencyAmount dictionary is used to supply monetary amounts.
The following fields MUST be supplied for a CurrencyAmount to be valid:
@@ -627,8 +633,8 @@
CurrencyAmount
value^-?[0-9]+(\.[0-9]+)?$.
@@ -768,8 +774,9 @@ ShippingAddress interface
If the requestShipping flag was set to true in the PaymentOptions
passed to the PaymentRequest constructor, then the user agent will populate the
- shippingAddress field of the PaymentRequest object with
- the user's selected shipping address.
+ shippingAddress field of the PaymentRequest and ultimately the
+ PaymentResponse object with the user's selected shipping address after
+ the user has accepted the payment.
ShippingAddress interface are
@@ -781,6 +788,25 @@ ShippingAddress interface
PartialShippingAddress interface
+
+ interface PartialShippingAddress {
+ /* [...] fields TBC */
+ };
+
+
+ If the requestShipping flag was set to true in the PaymentOptions
+ passed to the PaymentRequest constructor, then the user agent will populate the
+ partialShippingAddress field of the PaymentRequest object with
+ the user's selected shipping address.
+
PartialShippingAddress interface are
+ yet to be defined, but they are a minimal subset of the fields of ShippingAddress.
+ ShippingOption interface
@@ -818,6 +844,7 @@PaymentResponse interface
interface PaymentResponse { readonly attribute DOMString methodName; readonly attribute object details; + readonly attribute ShippingAddress? shippingAddress; Promise<void> complete(boolean success); }; @@ -838,6 +865,12 @@PaymentResponse interface
A JSON-serializable object that provides a payment method specific message used by the merchant to process the transaction and determine successful fund transfer. +
shippingAddresstrue in the PaymentOptions
+ passed to the PaymentRequest constructor, then shippingAddress will
+ be the full and final shipping address chosen by the user.
+ User agent delegates payment request algorithm
- This specification should describe how the user agent will pass the - payment request data and the complete signal to a native payment app + This specification should describe how the user agent will pass the + payment request data and the complete signal to a native payment app and also how it will receive the payment response from the payment app.