Should the payment request contain line item details? about webpayments

[msporny]

What is the expected use case for the payment details object?

I expect that the use case is to show a line-item summary in the best case, or in the worst case, a subtotal, tax, and total.

A line-item summary being passed outside of the retailer environment is a non-starter for retailers. They do not want to share this data with anyone that is not their customer.

This means that the default usage behavior might be for subtotal, tax, and total. I'd argue that the retailer could just as easily display this on a page before the payment request is made.

Adding the Payment Details functionality over-complicates the API when a simple HTML display would work just as well.

If the goal is to provide a line-item receipt to the customer, that should be provided through a receipt API (and we have a number of designs to accomplish that while ensuring that retailers are protected if such an interface were to appear in the browser).

[zkoch]

...because small and large retailers have stated that they do not want that information forwarded on to payment service processors

I don't believe there is any mention in the spec of providing this information to payment apps. Please correct me if I am wrong.

While we're not standardizing UI, it's good to give both merchants and user agents control over how they want final amounts to be displayed and visualized. This includes list items.

A line-item summary being passed outside of the retailer environment is a non-starter for retailers. They do not want to share this data with anyone that is not their customer.

Again, this data isn't being shared with anyone. It's for visual purposes. It is also what Apple Pay has done, and I don't think that has been a non-starter for apps that take advantage of it.

[adrianhopebailie]

This closely resembles the pattern in use for the various mobile payments systems like ApplePay and since it is the retailers who build the request (and can therefor choose to provide as much or as little detail as possible) I'm not sure if this is an issue?

[mountainhippo]

Actually shipping address and line-item summary are passed not infrequently to the PSP and thence to the acquirer and it is supported in many PSP's APIs. The line item detail is also a good example of ancillary data that flows through the card networks. There's a whole spec (Visa Global Invoicing Specification) for a special product category of cards. Other examples of this include flight itinerary data

[msporny]

I don't believe there is any mention in the spec of providing this information to payment apps.

It's not clear in the description of the payment details object that this object is strictly for display purposes only. There should be clarifying text to note that Payment Details MUST NOT be forwarded on to the payment app due to data privacy issues ("Oh, you're buying porn? Google Android Pay finds that very interesting").

This raises two other concerns:

1. Why aren't we just depending on HTML to display the itemized list?
2. How are we going to deal w/ Nick's point that sometimes line item data flows through to the PSPs? What format is this in? What about flight data?

[zkoch]

Why aren't we just depending on HTML to display the itemized list?

Not sure what you mean. You mean why aren't we relying on the merchant to display this themselves? Or why don't we embed HTML into whatever payment sheet the UserAgent shows?

How are we going to deal w/ Nick's point that sometimes line item data flows through to the PSPs?

We have no plan to. If that's important, then the merchant can send that to the PSP when they request final payment.

[adrianhopebailie]

At this point I believe we have different mental models about what happens when the payment mediator (in this case the UA) receives the payment request, what UI is then displayed, what component controls that UI (the merchant application, payment mediator or payment app) and what information is then passed on to the payment app.

At worst we need more info on what the details object is used for and which components have access to it and at best a wire-frame of what the UI might look like and examples of the data passed to the payment app (if different from that passed to the UA).

[mountainhippo]

@zkoch I'm not sure how the payee (merchant) would do that if the payment application has communicated directly with a PSP. The extra payload is captured in the auth request, not the clearing record, I think. There's a helpful list of different "level 2/level 3" data here on this Visa page: https://usa.visa.com/run-your-business/commercial-solutions/solutions/intellilink.html#2

Today this stuff all flows merchant -> merchant PSP

[zkoch]

@mountainhippo In our flow, the expectation is that payment apps do not communicate with PSPs. I mean, technically there is nothing stopping them, but it's not expected. The expected flow is the merchant still submits the payment credentials that came back from the payment app to their PSP for processing. At that time, if it's required, they could send item information in with that request. That said, I agree with Manu that this is not something we should be encouraging.

[dlongley]

@zkoch,

In our flow, the expectation is that payment apps do not communicate with PSPs.

Perhaps this is off-topic, but what about push payment flows?

[mattsaxon]

In our flow, the expectation is that payment apps do not communicate with PSPs.

The CG proposal specifically suggests direct communication with the Merchant PSP rather than via the Merchant.

Today this stuff all flows merchant -> merchant PSP

Today there are many cases where the merchant PSP acts as a delegate for the merchant, so the merchant never sees the payment details

[webpayments]

On Wed, Dec 23, 2015 at 4:58 AM, mattsaxon [email protected] wrote:

In our flow, the expectation is that payment apps do not communicate with
PSPs.

The CG proposal specifically suggests direct communication with the
Merchant PSP rather than via the Merchant.

Today this stuff all flows merchant -> merchant PSP

Today there are many cases where the merchant PSP acts as a delegate for
the merchant, so the merchant never sees the payment details

Moreover, this is critical functionality. One of the benefits to using
this technology for merchants is that they are OUT of that loop. If they
never have the information, even in passing, then they have less
liability. Also, frankly, it's easier to implement. And ultimately
probably less expensive per transaction.

-Shane

[vkuntz]

Should the payment request contain line item details? I am not sure this is the correct question. The question should be: What remittance information should be present in the payment request - line items is only one aspect of the problem, there are many other alternatives possible, like:

• the stuctured communication (used by the merchant for reconciliation purposes - frenquently used in many countries - BE, FIN, NL, JP, ...) for which an ISO standard has been created a couple of year ago
• underlying document type, which can have multiple forms
• line items (of an invoice),
• detailed tax information is another example (important when the payment falls under specific tax exemption legislation)......
  I would actually suggest that the payment request contains a remittance container, which could potentially be forwarded to all parties in the payment chain.

[adrianhopebailie]

I would actually suggest that the payment request contains a remittance container, which could potentially be forwarded to all parties in the payment chain.

This seems like a good idea to consider however we should ensure we are not over-complicating the issue here.

Unless the payment is being completed by the Payment App (i.e. out of band of the comms with the merchant or their PSP - likely some push payment) it seems likely that a lot of this data does not need to be sent to the Payment App in the request. The merchant will put this data into the message it sends to it's PSP after it receives a response from the Payment App authorizing the payment.

i.e. In many use cases the exchange of data via the browser API is simply a request for authorization from the merchant to the user (replacing the traditional card details form submission).

[msporny]

Migrating to w3c/payment-request#49.