From 81b3240a046ce70004ef3f0f2ba6e45734c583c8 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Mon, 14 Mar 2016 15:39:00 -0400 Subject: [PATCH 1/3] Remove trailing whitespace. --- specs/paymentrequest.html | 76 +++++++++++++++++++-------------------- 1 file changed, 38 insertions(+), 38 deletions(-) diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index d5160f90..837cc43e 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -89,7 +89,7 @@ Web Platform Incubator Community Group.

- +

Introduction

Buying things on the @@ -133,50 +133,50 @@

Non-goals

- +

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

-

- This specification defines one class of products: -

-
-
Conforming user agent
-
-

- A user agent MUST behave as described in this specification +

+ This specification defines one class of products: +

+
+
Conforming user agent
+
+

+ A user agent MUST behave as described in this specification in order to be considered conformant. In this specification, user agent means a Web browser or other interactive user agent as defined in [[!HTML5]]. -

-

- User agents MAY implement algorithms given in this - specification in any way desired, so long as the end result is - indistinguishable from the result that would be obtained by the - specification's algorithms. -

-

- A conforming Payment Request API user agent MUST also be a - conforming implementation of the IDL fragments - of this specification, as described in the - “Web IDL” specification. [[!WEBIDL]]

- - +

+ User agents MAY implement algorithms given in this + specification in any way desired, so long as the end result is + indistinguishable from the result that would be obtained by the + specification's algorithms. +

+

+ A conforming Payment Request API user agent MUST also be a + conforming implementation of the IDL fragments + of this specification, as described in the + “Web IDL” specification. [[!WEBIDL]] +

+ +
-
-

Dependencies

-

- This specification relies on several other underlying specifications. -

-
+
+

Dependencies

+

+ This specification relies on several other underlying specifications. +

+
Payment Request Document Architecture
The terms Payment Method, Payment App, and Payment Transaction @@ -200,7 +200,7 @@

Dependencies

be serialized to a string using JSON.stringify and later deserialized back to an object using JSON.parse with no loss of data.

-
DOM4
+
DOM4
The Event type and the terms fire an event, dispatch flag, stop propagation flag, and stop immediate propagation flag are defined by [[!DOM4]]. @@ -249,7 +249,7 @@

PaymentRequest interface

user agent while the user is providing input before approving or denying a payment request.

-

The following example shows how to construct a PaymentRequest and begin the +

The following example shows how to construct a PaymentRequest and begin the user interaction:

@@ -408,7 +408,7 @@ 
PaymentRequest constructor

             Set the value of the shippingOption attribute on request to null.
           
           
  • 
-            If details contains a shippingOptions sequence with a 
+            If details contains a shippingOptions sequence with a
             length of 1, then set shippingOption to the id of
             the only ShippingOption in the sequence.
           
    • 
@@ -938,7 +938,7 @@ 
    PaymentRequestUpdateEvent
    
               
               
  • Let newOption be null.
    • 
               
  • 
-                If details contains a shippingOptions sequence with a 
+                If details contains a shippingOptions sequence with a
                 length of 1, then set newOption to the id of the only
                 ShippingOption in the sequence.
               
    • 
@@ -1013,7 +1013,7 @@ 
    PaymentRequest updated algorithm
    
           The PaymentRequest updated algorithm is run by other algorithms above to fire
           an event to indicate that a user has made a change to a PaymentRequest
           called request with an event name of name.
    
-        
    It MUST run the following steps:
     
+        
    It MUST run the following steps:
    
         
      
           
    1. 
             If the request@[[\updating]] is true, then terminate

From c00692815bf3c229fefd2899a5a07595feab749a Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Wed, 16 Mar 2016 14:53:09 -0400
Subject: [PATCH 2/3] Add reference to issue #48.

---
 specs/paymentrequest.html | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html
index 837cc43e..7b791bc6 100644
--- a/specs/paymentrequest.html
+++ b/specs/paymentrequest.html
@@ -282,6 +282,39 @@ 
      PaymentRequest constructor
      
             ["visa", "bitcoin", "bobpay.com"]
    + +
    +

    + Should the list of acceptable payment methods be listed as simple + strings or complex objects? If simple strings, as proposed above, + then how can price vary based on the payment method? The following + example shows an alternative way of providing acceptable payment + methods that allows for price variation based on payment method. +

    + + 
    +  acceptedScheme: [{
+    scheme: [
+      'https://w3id.org/payment-schemes#Visa',
+      'https://w3id.org/payment-schemes#Mastercard',
+      'https://w3id.org/payment-schemes#Discover'
+    ],
+    transfer: {
+      amount: '4.35',
+      currency: 'USD'
+    },
+    paymentRequestService: 'https://merchant-psp.example.com/services/getPaymentInfo'
+  }, {
+    scheme: 'https://w3id.org/payment-schemes#Bitcoin',
+    transfer: {
+      amount: '0.0177',
+      currency: 'BTC'
+    },
+    destination: '3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC'
+  }
+
    +
    +

    The details object contains information about the transaction that the user is being asked to complete such as the line items in an order.

    
From 06a2444ca6769dcfc8e804c684cf791462a7d8f2 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Tue, 29 Mar 2016 17:30:18 -0400
Subject: [PATCH 3/3] Update reference to issue #48.

---
 specs/paymentrequest.html | 39 ++++++---------------------------------
 1 file changed, 6 insertions(+), 33 deletions(-)

diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html
index 7b791bc6..b68c4032 100644
--- a/specs/paymentrequest.html
+++ b/specs/paymentrequest.html
@@ -282,39 +282,6 @@ 
    PaymentRequest constructor
    
             ["visa", "bitcoin", "bobpay.com"]
    - -
    -

    - Should the list of acceptable payment methods be listed as simple - strings or complex objects? If simple strings, as proposed above, - then how can price vary based on the payment method? The following - example shows an alternative way of providing acceptable payment - methods that allows for price variation based on payment method. -

    - - 
    -  acceptedScheme: [{
-    scheme: [
-      'https://w3id.org/payment-schemes#Visa',
-      'https://w3id.org/payment-schemes#Mastercard',
-      'https://w3id.org/payment-schemes#Discover'
-    ],
-    transfer: {
-      amount: '4.35',
-      currency: 'USD'
-    },
-    paymentRequestService: 'https://merchant-psp.example.com/services/getPaymentInfo'
-  }, {
-    scheme: 'https://w3id.org/payment-schemes#Bitcoin',
-    transfer: {
-      amount: '0.0177',
-      currency: 'BTC'
-    },
-    destination: '3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC'
-  }
-
    -
    -

    The details object contains information about the transaction that the user is being asked to complete such as the line items in an order.

    @@ -386,6 +353,12 @@ 
    PaymentRequest constructor
    
           a preference and allow users to express a preference that overrides merchant preferences.
         
 
+        
    
+          There is an open issue about whether the list of supported payment
+          methods should be passed to the user agent as a simple sequence of
+          strings or as a more complex and flexible object structure.
+        
    
+
         
    
           The PaymentRequest constructor MUST act as follows: