Why does a Payment App need to see the line items?

[zkoch]

From PaymentAppRequest, why does a Payment App need the payee-provided line items?

[ianbjacobs]

So far we have heard:

• User experience. If the user can see what they are paying for (and to whom they are paying) that can increase confidence.
• For some scenarios, the actual payment happens later. Frank (Klarna) said "In our context, the payment does not happen at the time of purchase. We extend credit, and payment happens at a later stage, and the user needs to see that data when the payment has to happen (post purchase).
• Payment apps may also need that information in order to provide some services, e.g., "You can use this coupon for this purchase."

Ian

[ianbjacobs]

Closing this as there is no further input and we have answered the question by providing rationale.

[marcoscaceres]

This might be a duplicate #103 - but I don't think the above gives enough rationale for closing the issue. It doesn't seem to address the privacy concerns.

[marcoscaceres]

(at the very least, I think @zkoch should close the issue if he is satisfied with the response)

[ianbjacobs]

@marcoscaceres, I think that #103 is a duplicate. Would you mind closing it and moving the discussion here?

Personally I think the payment app api should allow for the line items. It might be that browsers offer users a feature where that information is not sent (on user configuration).

Ian

[marcoscaceres]

Repeating what I said in #103...

When making a purchase "in real life", it is uncommon to tell the payment processor exactly what is being purchased - instead, only the merchant's info and how much it costs is shared. Otherwise, the payment processor (e.g., my local bank) could gather an extensive list of things that I've purchased over time (which is fairly scary from a privacy perspective).

Thus, in the interest of privacy, perhaps we shouldn't send the displayItems to the payment handler's service worker? Alternatively, we could instead allow the user to not share display items, or allow them to send a generic "Goods or Services" item instead.

Rather, when the user goes to make a purchase, where the user chooses which PWA to use to fulfill the payment, the browser can display the items there instead.

Having said that, looking over PayPal invoices received over email, PayPal does get sent the display items during a purchase. 🤔

[msporny]

@marcoscaceres said:

It doesn't seem to address the privacy concerns.

Right, not to mention the competitive issues. In one of our very first Web Payments IG meetings, one of the largest retailers in the world said (and I'm paraphrasing) "We are not interested in sending what our customers are buying to companies that are going to mine that data, sell it, or use it to take our customers away."

The "payee-provided line items" list that we have today enables the largest browser vendors to capture and filter that data to their data mining operations. When this was raised, it was mentioned that payees could just put in vague line items.

... which raises the question if line items in the browser are going to end up being useful, or if most large retailers will opt to not include those items.

There is another set of proposals that is being discussed in the Web Payments IG around digital receipts, which would most likely be delivered to payment apps if the system was implemented. Yes, this raises a number of privacy concerns as well. Some of us are exploring ways to mitigate these privacy concerns (like supporting a "DO NOT RESELL / DATA MINE" flag.

All this re-raises the question of the usefulness of having line items displayed to the buyer when some of the largest retailers may opt to not use those line items at all. Especially if those line items don't get sent to the payment app. That means that only the browser is privy to those line items and then only for building a display to show the user.

The original proposal we had made with the Community Group proposals, which agrees far more with your more recent submission @marcoscaceres, was to simplify PaymentRequest so it was just about a payment (and not also about line items, billing address, shipping address, etc.). While we see the benefit of collecting billing address and shipping address, we are not convinced that the retailer will choose to not use PaymentRequest because line items aren't displayed to the individual (and therefore, they will have to provide a shopping cart list before payment is made, which they do anyway).

[adrianhopebailie]

This was discussed in the Payment Apps Taskforce call today.

Proposal

1. Add a flag to PaymentMethodData that allows a merchant to explicitly request that line items are shared with the payment app if that payment method is selected.
2. Default this to false (do not share) if not provided

Example

const methodData = [{
  supportedMethods: ["basic-card"],
  filters: {
    supportedNetworks: ['aFamousBrand', 'aDebitNetwork'],
    supportedTypes: ['debit']
  },
  data: {}
}, {
  supportedMethods: ["bobpay.com"],
  shareLineItems: true,
  data: {
    merchantIdentifier: "XXXX",
    bobPaySpecificField: true
  }
}];
const request = new PaymentRequest(methodData, details, options);

Discussion

There was not consensus that this address user privacy concern but it does appear (as has been stated in this thread and was pointed out by @Alyver on the call) that many payment methods REQUIRE this data.

We did not discuss how browsers might handle this or if they would prompt users to allow this data to be shared.

[zkoch]

I'm not super wild about this compromise. I'd prefer we just make a decision: share or don't. My preference is don't, but if the group collectively feels otherwise, I can live with that.

I am curious though about examples where lines items are required.

[marcoscaceres]

@adrianhopebailie,

many payment methods REQUIRE this data

Would be really helpful to have a list of those, so we can investigate the validity of why, and what they are doing with the line items.

[frank-hoffmann]

@zkoch
We (Klarna) offer financing for online purchases and take the full risk toward the merchant. We make a real time risk assessment to approve/deny the purchase, the customer then makes the actual payment(s) at a later point in time.

For us the order lines are important for two things:

1. Risk assessment. In order to make the real time assessment of whether we will offer credit or not the items being purchased is important. E.g. a purchase of a couch is less "risky" than a purchase of two iPhones.
2. Customer experience. There are multiple use cases. The main one is that when the customer makes the actual payment it is important that they see what they are paying for.

@marcoscaceres
I do not know how many payment providers that require this but I assume others with similar offerings as us would. Paypal Invoicing as you mentioned also require this.

I understand the user privacy concerns and agree that the user should be able to opt-in to not have this information sent to the Payment App.

[zkoch]

Thanks, @frank-hoffmann. One thing to consider, at least at Google, we recommend merchants use the line items only for high-level line items (e.g. subtotal, tax, shipping, etc). We don't recommend product-level information. I suspect that if this kind of data was really necessary, the only safe way to rely on it would be to require that it gets passed into the data blob associated with Klarna. For my own curiosity, do you take raw strings and try to figure out what they are? Or is there some process a merchant goes through to better inform you about what a given item being purchased is?

[msporny]

For my own curiosity, do you take raw strings and try to figure out what they are? Or is there some process a merchant goes through to better inform you about what a given item being purchased is?

Related to this discussion. Google's schema.org enables the machine-readable markup of products and their prices:

http://schema.org/Product
https://schema.org/Offer
https://schema.org/PriceSpecification

[frank-hoffmann]

@zkoch thank you for the clarification. Given that the line items are "high-level" they are of little use for us. Regarding your question we do a little bit of both, can explain more f2f if you are interested

[ianbjacobs]

Payment Request API says about displayItems:

"For example, it might include details of products or breakdown of tax and shipping. It is optional to provide this information. "

Some Merchants may provide details of products. So I think we still need to decide whether to not share, to share, to share with user permission, to share with merchant permission, or something else.

Ian

[adrianhopebailie]

I'd recommend that we proactively discourage using this for shopping cart lists. As soon as this list goes beyond 5 - 10 items the UI challenges, especially on mobile, will become nasty.

As @msporny has already pointed out elsewhere there are already good standards for marking up a product list.

[adrianhopebailie]

The WG resolved to close this with no change to the specification. The scope of this resolution is specifically Line Item data (not other data that the browser has collected during the Payment Request processing such as shipping address).

This does not resolve the following proposal: https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0032.html

[ianbjacobs]

Just to add one comment to @adrianhopebailie's summary: the resolution was that user agents do not give line items to payment apps when constructing the payment app request blob.

[rsolomakhin]

We've heard feedback from 3rd party payment apps that they would like to display a limited number of display items:

• Sub-total
• Tax
• Shipping

This will be even more beneficial for apps that fire the paymentmethodchange event, which can affect the tax calculations. As we discussed at the face-to-face in Foster City, some payment handlers may be able to provide shipping addresses, too, which means firing shippingaddresschange events. The individual line items are fine to leave out. What do folks think? Is this worth revisiting at the next conference call?

[ianbjacobs]

Hi @rsolomakhin,

Do you think it would help achieve this goal if we were to give merchants specializations of PaymentItem [1]. Maybe this has already been suggested; I don't recall. What if we offered specializations for sub-total, tax, and shipping. This would allow the browser to pass through those specializations, but not instance of the parent class.

Ian

[1] https://w3c.github.io/payment-request/#dom-paymentitem

[rsolomakhin]

Yes, Ian, specializations of PaymentItem would give merchants the power to explicitly opt-in to passing some display items to the payment apps, if they so desire. Our specs and docs would need to be very explicit that specialized PaymenItems go to the payment app.

…

--Rouslan

On Thu, May 2, 2019 at 2:07 PM ianbjacobs ***@***.***> wrote: Hi @rsolomakhin <https://github.com/rsolomakhin>, Do you think it would help achieve this goal if we were to give merchants specializations of PaymentItem [1]. Maybe this has already been suggested; I don't recall. What if we offered specializations for sub-total, tax, and shipping. This would allow the browser to pass through those specializations, but not instance of the parent class. Ian [1] https://w3c.github.io/payment-request/#dom-paymentitem — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH3EGO5ZJFGNBE2XOXSCZTPTMUV5ANCNFSM4C4ZY6GQ> .

[ianbjacobs]

I like your idea better:

dictionary PaymentItem {
required DOMString label;
required PaymentCurrencyAmount amount;
boolean pending = false;
boolean share = false;
};

For any payment item the merchant can express that it is shareable.

Ian

[marcoscaceres]

Previously, Mozilla has proposed tagging a line item as "tax". We could do the same with sub-total. That would help prevent information leakage.

[danyao]

Should we add an "other" category to PaymentItemCategory?

@adrianhopebailie mentioned in IRC re: Klarna use case:

The general label for the use cases is 'dynamic credit' which is niot unique to Klarna
MobiCred in South Africa, PayLater in Australia etc all assess credit based on what is being bought
Imprtant use case for economies where credit card penetration is low

I understand that the latest proposal is geared to address a different problem, i.e. allow payment handlers to provide a better user experience by more clearly delineate the different types of high level components of the Total.

It seems to me that the latest proposal can still support the "dynamic credit" use case if merchant chooses to share per-item details with the payment app using the shareWithPaymentApp flag and an appropriate label. The only hiccup is what PaymentItemCategory would this use? The "other" options would solve this problem.

[rsolomakhin]

@danyao , could we use the JavaScript value of undefined for the "other" category? This would be the default value for the PaymentItem.category field and would not need to be added as a separate category to the PaymenItemCategory enum.

[danyao]

Technically yes, but doesn't seem to me to align with typical expectation of enums being an enumeration of all use cases. But I don't feel strongly so I'm OK if we wait and see how merchant / payment apps actually choose to use this field, especially if any "dynamic credit" use cases pick this up.

[ianbjacobs]

@rsolomakhin and @danyao, can the category be optional?

I am not fluent in JS programming, so don't know which would be preferred between:

• Required category with "undefined", "other", or whatever
• Optional category.

I propose that we treat it as an error if the merchant provides an undefined enum value.

Ian

[marcoscaceres]

What do you think of the slightly more generic proposal where the merchant can simply authorize sharing of whatever line items they want with the user?

This shifts the burden of responsibility to the user, which is unfair because they won't understand that they payment handler could then take their purchase information and sell it to insurers, marketeers, law enforcement, and other unauthorized third parties.

Would semantic tagging have any other impact (e.g., UX) than influencing the decision to share data with a payment handler?

Hopefully not. But it would limit things to share that are in the domain of the payment handlers... things related to the payment. The payment handler has no business knowing what items a user purchased (or at least, we shouldn't make it their business as it's ripe for abuse from a privacy perspective).

[marcoscaceres]

In #91 (comment) @rsolomakhin mentioned limiting these to four things:

• "subtotal",
• "tax",
• "shipping",
• "other"

That seems reasonable (though I still hold shipping is redundant, as we have shippingOptions) - but those are privacy preserving and don't require sharing any personal data about what is being purchased.

[marcoscaceres]

I propose that we treat it as an error if the merchant provides an undefined enum value.

WebIDL throws on unknown emum types, so thankfully we get that for free.

[marcoscaceres]

So, an updated proposal would be:

dictionary PaymentItem {
  required DOMString label;
  required PaymentCurrencyAmount amount;
  boolean pending = false;
  PaymentItemCategory category = "other";
};

enum PaymentItemCategory {
  "subtotal",
  "tax",
  "shipping", /* still redundant, imo*/
  "other",
};
`

[rsolomakhin]

@marcoscaceres : Did you leave out boolean share = false intentionally?

[ianbjacobs]

@marcoscaceres, @danyao, and @rsolomakhin,

Given the concern raised about sharing arbitrary payment items with the payment handler, I propose we scale back to address the immediate use case that Rouslan talked about:
#91 (comment)

Seem ok?

Ian

[rsolomakhin]

@ianbjacobs : What are you proposing concretely? :-)

[ianbjacobs]

I think Marcos' updated proposal is the scaled back version.

[rsolomakhin]

@ianbjacobs , @marcoscaceres : Just so I understand you completely, is the scaled back proposal to share with the payment handler only those PaymentItem objects that have a PaymentItemCategory that's either "tax", "shipping", or "subtotal"?

[ianbjacobs]

Yes.

[marcoscaceres]

We might just be able to resurrect the original text for the type attributes we originally had in the PR spec (and add the new types). Need to check if that used a DOMString or enum. We also had tests for that, so also might save us a bit of time.

[marcoscaceres]

This is the PR I was referring to:
https://github.com/w3c/payment-request/pull/794/files

We can revert that, add "subtotal", and reuse it (and just remove the "at risk"). WDYT?

[rsolomakhin]

@marcoscaceres : Reverting that CL sounds good.

I still would love to add ashare boolean to the PaymentItem struct, because I suspect that merchants will want to experiment with what items they share with the payment app to see whether there's any uplift when they display a "type" of PaymentItem that we have not thought of yet, e.g., a coupon discount, loyalty discount, a service fee, or a late payment penalty.

[marcoscaceres]

any uplift when they display a "type" of PaymentItem that we have not thought of yet,

Not sure what you mean by “up lift”? Could you please clarify?

Just want to go back to first principles here though: when we originally started this work, we’d promised as a community that we would never ever share the PaymentItems outside the browser because of the significant privacy implications (hence way up the top we even suggested dropping them entirely, which I really now wish we had).

The problem is that what people buy is not up to the merchant to share - it’s for the user to share: but most users won’t understand how dangerous and ripe for abuse that is. Likewise, merchants probably won’t ever want to share that information either. As was mentioned at the last F2F, the last thing Big Merchant A wants to do is share purchase history with Big Merchant B (who may be acting as a payment handler, by being the credit card provider).

The question is really: does the payment handler need to know anything apart from the total and who the merchant is? The user needs to see the tax, sub-total, etc. which the browser can show them - but tax, shipping cost, and sub-total are none of the payment handler’s business (in a very literal sense). 🧐

[rsolomakhin]

@marcoscaceres wrote:

Not sure what you mean by “up lift”? Could you please clarify?

Increase in conversion rate.

A merchant might say: "Huh, sharing this payment item with the payment app makes the user at ease and fewer users abandon the transaction, so I'm willing the share this piece of information with the payment app, because it's beneficial to me."

The problem is that what people buy is not up to the merchant to share - it’s for the user to share: but most users won’t understand how dangerous and ripe for abuse that is. Likewise, merchants probably won’t ever want to share that information either.

The intent here is for the merchant to explain the price to the user without revealing the shopping cart contents to the payment app. Let's say you're shopping for a $9.99 sweater, click on checkout, and the payment app is showing $15.99. Where did that $6.00 addition came from? The user is very likely to abondong the transaction if the merchant does not break it down into $9.99 subtotal, $3.00 tax, $2.00 tax, and $1.00 donation to charity, or what have you. The payment app does not find out what exactly the user is buying, but the user is at ease in knowing that the price difference is not a bug.

The user needs to see the tax, sub-total, etc. which the browser can show them - but tax, shipping cost, and sub-total are none of the payment handler’s business (in a very literal sense).

In some cases, the payment handler and the browser are the same entity, so sharing with one is equivalent with sharing with the other.

In the case of 3rd party payment handlers, the browser cannot necessarily show these items to the user. Let's take tax as an example. If the user changes the billing address inside of the payment handler, the "paymentmethodchange" event will be fired for the merchant, the merchant will calculate the updated tax, and send that back to the payment handler. The user is already inside of the payment handler at this point, so it would be the payment handler that's displaying the tax.

[marcoscaceres]

I'm all for the breakdown structure of the display items as long as the display items never end up being shared with the payment handler then I'm happy. I'm really REALLY worried that now that we have the displayItems in the PR API at all they will get passed on to third party payment handlers... that MUST never happen.

so it would be the payment handler that's displaying the tax.

Perhaps... but it could be the browser. I guess it's a UI decision.

[rsolomakhin]

@marcoscaceres : Merchants can pass arbitrary data to payment handlers via the payment method specific data, including line items, if they wish. Do you think your proposed restriction would be enforceable?

[rsolomakhin]

@marcoscaceres : Could you provide some reasoning / motivation for never passing displayItems to the payment handlers? (Or point me to your existing arguments that have slipped my mind.)

[marcoscaceres]

the following image is fake, but was passed around recently... it illustrates what could happen:

[marcoscaceres]

@marcoscaceres : Merchants can pass arbitrary data to payment handlers via the payment method specific data, including line items, if they wish. Do you think your proposed restriction would be enforceable?

It depends if they are enforceable by dictionary type. Probably why we want to restrict arbitrary data being passed by doing an IDL conversion to some dictionary structure we trust (like we did with Basic-Card). I guess these are details we need to work out as we go forth...

[webpayments-specs]

Do you think that requiring the browser to provide a global kill-switch setting for the user would alleviate your concerns? E.g., "Only share the total amount with payment apps."

…

On Thu, Jun 27, 2019 at 9:30 AM Marcos Cáceres ***@***.***> wrote: @marcoscaceres <https://github.com/marcoscaceres> : Merchants can pass arbitrary data to payment handlers via the payment method specific data, including line items, if they wish. Do you think your proposed restriction would be enforceable? It depends if they are enforceable by dictionary type. Probably why we want to restrict arbitrary data being passed by doing an IDL conversion to some dictionary structure we trust (like we did with Basic-Card). I guess these are details we need to work out as we go forth... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#91?email_source=notifications&email_token=AEHSJBXP5DAFRK5FYYP2NVLP4S6GFA5CNFSM4C4ZY6G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYXDYFA#issuecomment-506346516>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEHSJBXE5L2RARUTKMDNNKTP4S6GFANCNFSM4C4ZY6GQ> .

[rsolomakhin]

Interesting idea that came up on the call today: The share field should be a list of origins or "*" string to give the merchant precise control with whom they'd be willing to share any one display item.

[marcoscaceres]

But again, are these not the users' display items (i.e., not the merchant's)? It's not up to the merchant to share them, it's up to the user. If this was in the spec, we would need to add a lot of friction to warn the user that their cart's contents is being shared with a third party, and that this can have unfortunate privacy implication (and give the user the choice to not share them).

If anything, I feel like we should be looking at ways of entirely deprecating displayItems. They are taking us down a bad path... sites should provide a proper breakdown of what they are charging people, and the browser/payment handler should only really handle final totals.

[rsolomakhin]

@marcoscaceres wrote:

The browser/payment handler should only really handle final totals.

Are you suggesting the the browser should not see the display items aside from the total either?

[marcoscaceres]

Are you suggesting the the browser should not see the display items aside from the total either?

I was... but I guess that's going a bit overboard. So maybe going down the types route might be better. Ideally, the breakdown we would want to show is just:

So: a "subtotal", "tax", "shipping" (derived from selected shipping option), and the "total", but not what is being actually purchased.

[rsolomakhin]

Sounds reasonable, @marcoscaceres . Let's ship it! :-D