From e34975023a03ad1c5865b5abed5a363cfa5488ba Mon Sep 17 00:00:00 2001 From: Adrian Hope-Bailie Date: Thu, 31 Mar 2016 17:53:18 +0200 Subject: [PATCH 1/4] Add PaymentItem type to deal with transaction types The TransaactionType is a new property of the PaymentItem which helps the user agent infer appropriate display logic for the payment such as locale appropriate values display and button labels. Addresses: https://github.com/w3c/browser-payment-api/issues/56 https://github.com/w3c/browser-payment-api/issues/19 --- specs/paymentrequest.html | 69 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 2 deletions(-) diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index f0734b71..96b9d3b7 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -295,16 +295,19 @@

PaymentRequest constructor

{ "id": "basket", "label": "Sub-total", + "type" : "debit" "amount": { "currencyCode": "USD", "value" : "55.00" }, // US$55.00 }, { "id": "tax", "label": "Sales Tax", + "type" : "debit" "amount": { "currencyCode": "USD", "value" : "5.00" }, // US$5.00 }, { "id": "total", "label": "Total due", + "type" : "capture" "amount": { "currencyCode": "USD", "value" : "60.00" }, // US$60.00 } ] @@ -684,18 +687,77 @@

PaymentOptions dictionary

+
+

Transaction Types

+ 
+
+        enum TransactionType {
+          "debit",
+          "credit",
+          "auth",
+          "capture",
+          "repeat-debit",
+          "repeat-credit"
+        };
+
+
+ Defining a fixed list will allow user agents to manage the user interface for each transaction type + appropriately however it is possible that new payment methods may wish to define new types that are not + currently widely known. +
+

+ The type attribute of a PaymentItem provides hints to the user agent + and payment app about how to display and process the request. +

+

+ All but the last PaymentItem should have a type of either debit or + credit indicating if the payer is being debited or credited as a result of this item. + For example, a sub-total for a goods purchase would be a debit whereas a discount would be a credit. +

+

+ The type of the final PaymentItem indicates to the user agent and Payment App + the type of transaction that the payee is requesting. +

+

The following types MUST be supported:

+
+
debit
+
A standard payment/debit against the payer's account.
+
credit
+
A refund/credit against the payer's account.
+
authorization
+
A request to authorize a payment that may be settled between the payer and payee at some + time in the future. The specifics of an authorization will depend on the payment method that is used + to process the payment.
+
capture
+
A request to capture the details of the payer (and possibly the payment itself) for future use.
+
repeat-debit
+
A request to peform repeated future debits against the payer's account. This may be for any recurring + payment such as a subscription. The details of the recurring payment should be handled by the payment + method.
+
repeat-credit
+
A request to peform repeated future credits against the payer's account. This may be for any recurring + credit such as a wage payment or proceeds of a sale. The details of the recurring payment should be + handled by the payment method.
+
+
+

PaymentItem dictionary

         dictionary PaymentItem {
           required DOMString id;
           required DOMString label;
+          required TransactionType type;
           required CurrencyAmount amount;
         };

A sequence of one or more PaymentItem dictionaries is included in the PaymentDetails - dictionary to indicate the what the payment request is for and the value asked for. + dictionary to indicate what the payment request is for and the value asked for. +

+

+ The user agent MAY use the provided PaymentItem dictionaries to infer appropriate user interface details + to be displayed to the user.

The following fields MUST be included in a PaymentItem for it to be valid: @@ -706,7 +768,10 @@

PaymentItem dictionary

unique for a given PaymentRequest.
label
This is a human-readable description of the item. The user agent may display - this to the user.
+ this to the user. +
type (Defaults to debit.)
+
The type of transaction that should be performed for this line item. The value for all but the + last line item SHOULD be either debit or credit.
amount
A CurrencyAmount containing the monetary amount for the item. From 9a815682503bbbf8e366536fa5b7fe12cf865c65 Mon Sep 17 00:00:00 2001 From: Adrian Hope-Bailie Date: Fri, 1 Apr 2016 11:39:09 +0200 Subject: [PATCH 2/4] Add issue markers for #19 and #112 Issue markers for extensibility of the tran type list and the discussion on the initial list --- specs/paymentrequest.html | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index 96b9d3b7..293de61a 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -689,6 +689,7 @@

PaymentOptions dictionary

Transaction Types

+ 
 
         enum TransactionType {
@@ -700,11 +701,15 @@ 
Transaction Types

           "repeat-credit"
         };
-
+
Defining a fixed list will allow user agents to manage the user interface for each transaction type appropriately however it is possible that new payment methods may wish to define new types that are not currently widely known.
+
+ There is currently a discussion around the approriate set of transaction types that should be defined in this + specification. This list is just the initial proposal. +

The type attribute of a PaymentItem provides hints to the user agent and payment app about how to display and process the request. From 14781522b476999283aae1041183fda70f7114d4 Mon Sep 17 00:00:00 2001 From: Adrian Hope-Bailie Date: Mon, 4 Apr 2016 10:14:12 +0100 Subject: [PATCH 3/4] Moved total out of items sequence --- specs/paymentrequest.html | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index c6011976..cf6d8afb 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -641,7 +641,8 @@

CurrencyAmount

PaymentDetails dictionary

 dictionary PaymentDetails {
-  sequence<PaymentItem> items;
+  PaymentItem total;
+  sequence<PaymentItem>? items;
   sequence<ShippingOption> shippingOptions;
 };
@@ -655,17 +656,22 @@

PaymentDetails dictionary

The following fields are part of the PaymentDetails dictionary:

-
items
+
total
- This sequence of PaymentItem dictionaries indicates what the payment - request is for. The sequence must contain at least one PaymentItem. The last - PaymentItem in the sequence represents the total amount of the payment + A PaymentItem dictionary that represents the total amount of the payment request. It is the responsibility of the calling code to ensure that the total amount is - the sum of the preceding items. The user agent MAY not validate that this is true. + the sum of PaymentItem dictionaries in items. The user agent + MAY not validate that this is true. +
+
items
+
+ This optional sequence of PaymentItem dictionaries indicates what the payment + request is for. It may be used to enumerate the basket of goods or additional costs and discounts such + as shipping costs or discounts as a result of a voucher or coupon.
shippingOptions
- A sequence containing the different shipping options that the use may choose from. + A sequence containing the different shipping options that the user may choose from.

If the sequence is empty, then this indicates that the merchant cannot ship to the current shippingAddress.

If the sequence only contains one item, then this is the shipping option that @@ -736,13 +742,14 @@

Transaction Types

and payment app about how to display and process the request.

- All but the last PaymentItem should have a type of either debit or - credit indicating if the payer is being debited or credited as a result of this item. - For example, a sub-total for a goods purchase would be a debit whereas a discount would be a credit. + All PaymentItem dictionaries in the items sequence of PaymentDetails + must have a type of either debit or credit indicating if the payer + is being debited or credited as a result of this item. For example, a sub-total for a goods purchase would + be a debit whereas a discount would be a credit.

- The type of the final PaymentItem indicates to the user agent and Payment App - the type of transaction that the payee is requesting. + The type of the PaymentItem that is the total element of PaymentDetails + indicates to the Payment App the type of transaction that the payee is requesting.

The following types MUST be supported:

From e5ceaa1c36791231e4caae5d59ff1076a257ceda Mon Sep 17 00:00:00 2001 From: Adrian Hope-Bailie Date: Mon, 4 Apr 2016 10:16:10 +0100 Subject: [PATCH 4/4] Update .gitignore --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 3f096ef9..df309478 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,2 @@ -.idea/workspace.xml +.idea/