Should the payment request contain line item details?

[msporny]

Migrating from https://github.com/w3c/webpayments/issues/38:

The paymentRequest API currently includes a Payment Details object in a payment request:

http://wicg.github.io/paymentrequest/specs/paymentrequest.html#paymentdetails-dictionary http://wicg.github.io/paymentrequest/specs/paymentrequest.html#paymentrequest-interface

The Web Payments CG's Browser API specifically does not provide such an interface because small and large retailers have stated that they do not want that information leaked outside of their customer-merchant environment.

Does introducing this line-item list create an issue w/ the "private" customer-merchant environment? Will most merchants opt to not include line item data?

[adrianba]

Line items are entirely optional so merchants can provide what they want. At most you need to provide one item with the total amount.

[halindrome]

Note that I continue to object to having one of the line items be the total. The total should be a separate entry in the data structure.(see issue #18)

[adrianba]

Note that I continue to object to having one of the line items be the total. The total should be a separate entry in the data structure.(see issue #18)

I wasn't taking a view on that here. The current proposal is modeled on an existing (non-web) API. Issue #18 is called out in the spec in section 6.

[msporny]

Walmart and Target, for example, have specifically stated that they do not want to include line item data. Will most merchants opt to not include line item data once they find out that the browser vendors could mine that data? If so, that would be a strong signal to not include line item data in the API.

[adrianhopebailie]

I think this is a red herring.

The list items are not intended for showing a basket of goods (although I guess there is nothing stopping a merchant doing that) but rather the set of final "sub-totals" that constitute the final total. i.e. Things like shipping, discounts, etc

[halindrome]

I disagree with your conclusion @adrianhopebailie - that list of items is 1) called items, and 2) the examples include the information about what is the basket.

[adrianhopebailie]

Which examples are you referring to @halindrome ?

This one from the spec has no details of the basket of goods:

{
  "items": [
    {
      "id": "basket",
      "label": "Sub-total",
      "amount": { "currencyCode": "USD", "value" : "55.00" }, // US$55.00
    },
    {
      "id": "tax",
      "label": "Sales Tax",
      "amount": { "currencyCode": "USD", "value" : "5.00" }, // US$5.00
    },
    {
      "id": "total",
      "label": "Total due",
      "amount": { "currencyCode": "USD", "value" : "60.00" }, // US$60.00
    }
  ]
}

[halindrome]

Wow. And LOL. I actually thought "basket" in this instance was, you know, a basket someone was buying. Not a "Basket" of goods. Never even occurred.to me. Now I really don't like having total in here as per #18. This is not a list of "items". It is a list of.... I have no idea what. Not items I have ordered. Not line items of an invoice. My question for the author of this section is "what sort of items are supposed to be in this list?" The spec says:

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.

Which is fine and generic, but as a user gives me no guidance.

[adrianhopebailie]

PR #133 proposes moving total to the details (passed to the app) and putting these line items (which are for display purposes only) in the options.

If we are happy with #133 can I close this and also PR #83?

[corwinAmbre]

Hello, being able to provide the list of items bought by the user to the payment platform is usefull for refund / chargeback processes, especially for physical goods and pre-purchases as well. When user wants to partically cancel an order, having such details directly in payment back-office (if supported by payment) is really usefull for merchant.

[adrianhopebailie]

@corwinAmbre that is not what we have heard to date. In contrast we have heard that merchants are concerned about third-party PSPs having access to this data.

I think it's out of scope of this API to be gathering the full details of the basket of goods. This can be exchanged via an out of band channel using electronic invoices or similar. The APi rpovides everythign that is required to pass the invoice number or reference in the payment data to ensure that they can be effectively matched on the back-end.

[corwinAmbre]

Hello, thanks for your quick feedback. I raised this concern because our monetization team openned this topic recently for multi-product cart. As I said before anyway, it also depends on PSPs since the support of details is not widely available (at least for the ones I'm working with).

[adrianba]

Other payment APIs allow for the optional display of line items (e.g., sometimes it is necessary to call out tax as a separate value). The API currently makes showing more than one item optional. I recommend closing this issue.