From 385257afc827872011fd5a00a5b1781f480b392f Mon Sep 17 00:00:00 2001 From: rvm4 Date: Sun, 10 Apr 2016 15:44:35 -0400 Subject: [PATCH] provide partial shipping address in PaymentRequest and full shipping address in PaymentResponse --- specs/paymentrequest.html | 74 +++++++++++++++++++++++++++------------ 1 file changed, 52 insertions(+), 22 deletions(-) diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index 7d269907..e769b66b 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -229,7 +229,7 @@

PaymentRequest interface

Promise<PaymentResponse> show(); void abort(); - readonly attribute ShippingAddress? shippingAddress; + readonly attribute PartialShippingAddress? partialShippingAddress; readonly attribute DOMString? shippingOption; /* Supports "shippingaddresschange" event */ @@ -242,7 +242,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 +276,11 @@

PaymentRequest constructor

method specific data.

- It is proposed that a conformance criteria for implementations of this API be - that any data passed into the request is passed on to the payment app unaltered. - This would allow extensions of the data schema such as the addition of - properties that are not documented in this specification or known to implementors - such as JSON-LD @context or similar to be passed between the website and + It is proposed that a conformance criteria for implementations of this API be + that any data passed into the request is passed on to the payment app unaltered. + This would allow extensions of the data schema such as the addition of + properties that are not documented in this specification or known to implementors + such as JSON-LD @context or similar to be passed between the website and payment app.
@@ -429,7 +429,7 @@

PaymentRequest constructor

  • Store data into request@[[\data]].
  • Set the value request@[[\state]] to created.
  • - Set the value of the shippingAddress attribute on request to null. + Set the value of the partialShippingAddress attribute on request to null.
  • Set the value of the shippingOption attribute on request to null. @@ -516,16 +516,20 @@

    abort()

    State transitions

    The internal slot [[\state]] follows the following state transitions:

    - Transition diagram for internal slot state of a PaymentRequest object
    -

    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 +609,13 @@

    CurrencyAmount

    required DOMString value; }; -
    - The resolution of the WG per Issue #57 defined - a format for currencies and amounts that lacked support for negative values. The format below adds this +
    + The resolution of the WG per Issue #57 defined + a format for currencies and amounts that lacked support for negative values. The format below adds this capability in a way that is not common for financial messaging standards (using signed numbers). The rationale for negative numbers is to support discounts. The group is still discussing whether functionality to support discounts might be implemented in a different manner (e.g., via a transaction type). -
    +

    A CurrencyAmount dictionary is used to supply monetary amounts. The following fields MUST be supplied for a CurrencyAmount to be valid: @@ -627,8 +631,8 @@

    CurrencyAmount

    value
    A string containing the decimal monetary value. If a decimal separator is needed then the string - MUST use a single U+002E FULL STOP character as the decimal separator. The string MUST begin - with a single U+002D HYPHEN-MINUS character if the value is negative. All other characters must + MUST use a single U+002E FULL STOP character as the decimal separator. The string MUST begin + with a single U+002D HYPHEN-MINUS character if the value is negative. All other characters must be characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9).
    The string should match the regular expression ^-?[0-9]+(\.[0-9]+)?$. @@ -768,8 +772,8 @@

    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 PaymentResponse object with + the user's selected shipping address after the user has accepted the payment.

    The fields of the ShippingAddress interface are @@ -781,6 +785,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. +

    +
    + The fields of the PartialShippingAddress interface are + yet to be defined, but they are a minimal subset of the fields of ShippingAddress. +
    +
    +

    ShippingOption interface

    @@ -818,6 +841,7 @@ 
    PaymentResponse interface
    
         interface PaymentResponse {
           readonly attribute DOMString methodName;
           readonly attribute object details;
+          readonly attribute ShippingAddress? shippingAddress;
 
           Promise<void> complete(boolean success);
         };
@@ -838,6 +862,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.
       
+      
    shippingAddress
    
+      
    
+        If the requestShipping flag was set to true in the PaymentOptions
+        passed to the PaymentRequest constructor, then shippingAddress will
+        be the full and final shipping address chosen by the user.
+      
    
       
 
       
    
@@ -1149,8 +1179,8 @@ 
    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.