From e336f1edce8cb23069845c8bbf15817e34b0acbe Mon Sep 17 00:00:00 2001 From: rvm4 Date: Sun, 10 Apr 2016 16:02:50 -0400 Subject: [PATCH 1/5] 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.

    From 190ea823877a2028a58e8a272a43ca4507779737 Mon Sep 17 00:00:00 2001 From: Ade Bateman Date: Sun, 10 Apr 2016 13:23:45 -0700 Subject: [PATCH 2/5] Change e.g. to e.g., (#126) Fixes #66. --- specs/method-identifiers.html | 2 +- specs/paymentrequest.html | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/specs/method-identifiers.html b/specs/method-identifiers.html index d765ecfa..0c316d7d 100644 --- a/specs/method-identifiers.html +++ b/specs/method-identifiers.html @@ -415,7 +415,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?

    diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index 7d269907..556ee0fc 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -73,7 +73,7 @@

    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.

    @@ -100,15 +100,15 @@

    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.

    From 12173eeb03d899664289269006eb3f5da83748df Mon Sep 17 00:00:00 2001 From: Ade Bateman Date: Fri, 15 Apr 2016 14:39:31 -0700 Subject: [PATCH 3/5] Updating bibliography for FPWD. Cherry pick from 465086b28988dda4119d8adcef4f54eef03905e1. --- specs/architecture.html | 15 +++++++++------ specs/basic-card-payment.html | 13 ++++++++----- specs/method-identifiers.html | 5 +++-- specs/paymentrequest.html | 4 +++- 4 files changed, 23 insertions(+), 14 deletions(-) diff --git a/specs/architecture.html b/specs/architecture.html index 633462c5..5cc5f13f 100644 --- a/specs/architecture.html +++ b/specs/architecture.html @@ -50,33 +50,36 @@ localBiblio: { "PAYMENTREQUESTAPI": { 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": { 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" }, "BASICCARDPAYMENTS": { title: "Basic Card Payment" - , href: "basic-card-payment.html" + , href: "http://www.w3.org/TR/payment-method-basic-card/" , authors: [ "Adrian Bateman" , "Zach Koch" , "Richard Barnes" + , "Roy McElmurry" ] - , status: "ED" + , status: "WD" } } }; diff --git a/specs/basic-card-payment.html b/specs/basic-card-payment.html index 84e45817..bb2c7d09 100644 --- a/specs/basic-card-payment.html +++ b/specs/basic-card-payment.html @@ -38,33 +38,36 @@ localBiblio: { "PAYMENTARCH": { 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": { 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": { 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" } } }; diff --git a/specs/method-identifiers.html b/specs/method-identifiers.html index 0c316d7d..e5e31be7 100644 --- a/specs/method-identifiers.html +++ b/specs/method-identifiers.html @@ -38,13 +38,14 @@ localBiblio: { "PAYMENTREQUESTAPI": { 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" }, "REVERSEDOMAINS": { title: "Reverse Domain Name Notation" diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index 556ee0fc..ad2e862f 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -43,16 +43,18 @@ "Adrian Bateman" , "Zach Koch" , "Richard Barnes" + , "Roy McElmurry" ] , status: "ED" }, "METHODIDENTIFIERS": { title: "Payment Method Identifiers" - , href: "https://w3c.github.io/browser-payment-api/specs/method-identifiers.html" + , href: "https://www.w3.org/TR/payment-method-id/" , authors: [ "Adrian Bateman" , "Zach Koch" , "Richard Barnes" + , "Roy McElmurry" ] , status: "ED" } From a9669e568fa56332241aaed94711dd0a53704e19 Mon Sep 17 00:00:00 2001 From: Ade Bateman Date: Thu, 7 Apr 2016 07:58:30 -0700 Subject: [PATCH 4/5] Reference names should have hyphens Fixes #63. --- specs/architecture.html | 12 ++++++------ specs/basic-card-payment.html | 16 ++++++++-------- specs/method-identifiers.html | 8 ++++---- specs/paymentrequest.html | 10 +++++----- 4 files changed, 23 insertions(+), 23 deletions(-) diff --git a/specs/architecture.html b/specs/architecture.html index 5cc5f13f..60e8bce7 100644 --- a/specs/architecture.html +++ b/specs/architecture.html @@ -48,7 +48,7 @@ }], localBiblio: { - "PAYMENTREQUESTAPI": { + "PAYMENT-REQUEST-API": { title: "Payment Request API" , href: "https://www.w3.org/TR/payment-request/" , authors: [ @@ -59,7 +59,7 @@ ] , status: "WD" }, - "METHODIDENTIFIERS": { + "METHOD-IDENTIFIERS": { title: "Payment Method Identifiers" , href: "https://www.w3.org/TR/payment-method-id/" , authors: [ @@ -70,7 +70,7 @@ ] , status: "WD" }, - "BASICCARDPAYMENTS": { + "BASIC-CARD-PAYMENTS": { title: "Basic Card Payment" , href: "http://www.w3.org/TR/payment-method-basic-card/" , authors: [ @@ -260,7 +260,7 @@

    Specifications

    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.

    @@ -274,7 +274,7 @@

    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. @@ -296,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 bb2c7d09..1e60d98c 100644 --- a/specs/basic-card-payment.html +++ b/specs/basic-card-payment.html @@ -36,7 +36,7 @@ issueBase: "https://github.com/w3c/browser-payment-api/issues/", localBiblio: { - "PAYMENTARCH": { + "PAYMENT-ARCH": { title: "Payment Request Architecture" , href: "https://w3c.github.io/browser-payment-api/specs/architecture.html" , authors: [ @@ -47,7 +47,7 @@ ] , status: "ED" }, - "PAYMENTREQUESTAPI": { + "PAYMENT-REQUEST-API": { title: "Payment Request API" , href: "https://www.w3.org/TR/payment-request/" , authors: [ @@ -58,7 +58,7 @@ ] , status: "WD" }, - "METHODIDENTIFIERS": { + "METHOD-IDENTIFIERS": { title: "Payment Method Identifiers" , href: "https://www.w3.org/TR/payment-method-id/" , authors: [ @@ -85,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.

    @@ -108,7 +108,7 @@

    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.

    @@ -128,14 +128,14 @@

    Dependencies

    The terms Payment Method, Payment App, and Payment Transaction Message Specification are defined by the Payment Request Architecture document - [[!PAYMENTARCH]].
    + [[PAYMENT-ARCH]].
    Payment Request API
    The term PaymentRequest constructor is defined by the PaymentRequest API - specification [[!PAYMENTREQUESTAPI]].
    + specification [[!PAYMENT-REQUEST-API]].
    Payment Method Identifiers
    The term Payment Method Identifier is defined by the Payment Method Identifiers specification - [[!METHODIDENTIFIERS]].
    + [[!METHOD-IDENTIFIERS]].
    Web IDL
    The IDL in this specification is defined by Web IDL [[!WEBIDL]].
    diff --git a/specs/method-identifiers.html b/specs/method-identifiers.html index e5e31be7..0a567218 100644 --- a/specs/method-identifiers.html +++ b/specs/method-identifiers.html @@ -36,7 +36,7 @@ issueBase: "https://github.com/w3c/browser-payment-api/issues/", localBiblio: { - "PAYMENTREQUESTAPI": { + "PAYMENT-REQUEST-API": { title: "Payment Request API" , href: "https://www.w3.org/TR/payment-request/" , authors: [ @@ -47,7 +47,7 @@ ] , status: "WD" }, - "REVERSEDOMAINS": { + "REVERSE-DOMAINS": { title: "Reverse Domain Name Notation" , href: "https://en.wikipedia.org/wiki/Reverse_domain_name_notation" } @@ -58,7 +58,7 @@

    - 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.

    @@ -368,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

    diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index ad2e862f..e7a3c6de 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -36,7 +36,7 @@ issueBase: "https://github.com/w3c/browser-payment-api/issues/", localBiblio: { - "PAYMENTARCH": { + "PAYMENT-ARCH": { title: "Payment Request Architecture" , href: "https://w3c.github.io/browser-payment-api/specs/architecture.html" , authors: [ @@ -47,7 +47,7 @@ ] , status: "ED" }, - "METHODIDENTIFIERS": { + "METHOD-IDENTIFIERS": { title: "Payment Method Identifiers" , href: "https://www.w3.org/TR/payment-method-id/" , authors: [ @@ -115,7 +115,7 @@

    Introduction

    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

    @@ -181,11 +181,11 @@

    Dependencies

    The terms Payment Method, Payment App, and Payment Transaction Message Specification are defined by the Payment Request Architecture document - [[PAYMENTARCH]].
    + [[PAYMENT-ARCH]].
    Payment Method Identifiers
    The term Payment Method Identifier is defined by the Payment Method Identifiers specification - [[!METHODIDENTIFIERS]].
    + [[!METHOD-IDENTIFIERS]].
    HTML5
    The terms global object, queue a task, browsing context, and From d3200c6c734ee2c9bf9f35c90655da2a16de3a4a Mon Sep 17 00:00:00 2001 From: rvm4 Date: Sun, 10 Apr 2016 16:01:41 -0400 Subject: [PATCH 5/5] provide shipping address in PaymentResponse --- specs/paymentrequest.html | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index e7a3c6de..85c2a2fd 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -770,8 +770,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.

    The fields of the ShippingAddress interface are @@ -820,6 +821,7 @@

    PaymentResponse interface

    interface PaymentResponse { readonly attribute DOMString methodName; readonly attribute object details; + readonly attribute ShippingAddress? shippingAddress; Promise<void> complete(boolean success); }; @@ -840,6 +842,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. +