diff --git a/index.html b/index.html index 21270e2c..bbf7c928 100644 --- a/index.html +++ b/index.html @@ -125,12 +125,19 @@
+ The details of how to fulfill a payment request for a given payment + method are handled by payment apps. In this specification, + these details are left up to the user agent, but future + specifications may expand on the processing model in more detail. +
In addition to better, more consistent user experiences, this also enables web sites to take advantage of more secure payment schemes @@ -276,13 +283,15 @@
The PaymentRequest is constructed using the supplied
- methodData
list including any payment method
- specific data
, the payment details
, and the
- payment options
.
+ methodData list including any payment method
+ specific data, the payment
+ details, and the payment options. The
+ methodData supplied to the PaymentRequest
+ constructor SHOULD be in the order of preference of the caller.
- The methodData
sequence contains
+ The methodData sequence contains
PaymentMethodData dictionaries containing the payment
method identifiers for the payment methods that the web
site accepts and any associated payment method specific
@@ -305,7 +314,7 @@
- The details
object contains information about the
+ The details object contains information about the
transaction that the user is being asked to complete such as the
line items in an order.
- The options
object contains information about what
+ The options object contains information about what
options the web page wishes to use from the payment request system.
@@ -364,6 +373,8 @@+
- Set request.[[\methodData]] to - methodData. -
-- The methodData supplied to the PaymentRequest - constructor SHOULD be in the order of preference of the caller. - Implementations MAY show payment methods in this order if - possible but SHOULD prioritize the preference of the user when - presenting payment methods. -
+supportedMethods
sequences from each
- PaymentMethodData in the
- request.[[\methodData]] sequence.
- + Otherwise, show a user interface to allow the user to interact + with the payment request process, using those payment apps + and payment methods which the above step identified as + feasible. The user agent MAY show payment methods in the order + given by supportedMethods, but SHOULD prioritize the + preference of the user when presenting payment methods and + applications. +
++ The acceptPromise will later be resolved by the + user accepts the payment request algorithm through + interaction with the user interface. +
methodData
supplied to the constructor.
+ The methodData
supplied to the constructor, but
+ represented as tuples containing supported methods and a string
+ or null for data (instead of the original object form).
The shippingOptions
field is only used if the
PaymentRequest was constructed with PaymentOptions
- requestShipping
set to true.
+ requestShipping set
+ to true.
If the sequence has an item with the selected
field
@@ -1529,11 +1552,10 @@
requestShipping
value of
+ shippingAddress
attribute of request is
- null
or if the shippingOption
attribute of
- request is null
, then terminate this
- algorithm and take no further action. This should never occur.
+ shippingAddress
+ attribute of request is null or if the shippingOption attribute of
+ request is null, then terminate this algorithm and take no
+ further action. This should never occur.
methodName
attribute value of
- response to the payment method identifier for the
- payment method that the user selected to accept the payment.
+ details
attribute value of
- response to a JSON-serializable object containing
- the payment method specific message that will be used by the
+ requestShipping
value of
- request.[[\options]] is true, then copy the
- shippingAddress
attribute of request to the
- shippingAddress
- attribute of response.
- requestShipping
value of
- request.[[\options]] is true, then copy the
- shippingOption
attribute of request to the
- shippingOption
- attribute of response.
+ be defined for each payment method, and the contents of the
+ response will be determined by the payment app used. If the
+ response is provided as a Web IDL dictionary, first convert it to an
+ ECMAScript object.
+ requestPayerName
value of
- request.[[\options]] is true, then set the
- payerName attribute of
- response to the payer's name provided by the user.
+ requestPayerEmail
value of
+ requestPayerPhone
value of
+ payerPhone
attribute of response to the
- payer's phone number selected by the user.
+ payerPhone attribute of
+ response to the payer's phone number selected by the user.
The term JSON-serializable object used in this - specification means an object that can be serialized to a string - using JSON.stringify and later deserialized back to an - object using JSON.parse with no loss of data. + specification is not well defined; see issue + #307. +
++ The term JSON-serialize + applied to a given object means to run the algorithm specified by + the original value of the JSON.stringify function on the + supplied object, passing the supplied object as the sole argument, + and return the resulting string. This can throw an exception.
The algorithm for converting an ECMAScript value to a - dictionary is defined by [[!WEBIDL-2]]. + dictionary and for converting a dictionary to an + ECMAScript value is defined by [[!WEBIDL-2]].