making the "total" field optional in PaymentRequest API

[maxlgu]

Hello TAG!

I'm requesting a TAG review of making the "total" field optional in PaymentRequest API.

Given that when Digital Goods API is used with PaymentRequest API, the total amount is unnecessary, we propose to make the “total” field optional in PaymentRequest API spec, along with a few consequent changes.

• Explainer¹ (minimally containing user needs and example code): Make "total" and "details" optional w3c/payment-request#912
• Security and Privacy self-review²: N/A (this proposal has no security and privacy consequence)
• Primary contacts (and their relationship to the specification):
  • Liquan (Max)Gu (@maxlgu), Chromium
• Organization/project driving the design: Chromium
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/5226111782879232

[kenchris]

This looks very sensible to me. No further comments from my side

[cynthia]

LGTM2.

[hober]

This statement seems wrong:

Payment Request by itself is inadequate for making in-app purchases in existing digital stores, because that API simply asks the user to make a payment of a certain amount

But in Payment Request they can describe the item being purchased and have that description shown alongside the price. Certainly, users want to see both product names and prices. “Please authorize the purchase of SHINY_SWORD” without saying how much SHINY_SWORD costs seems wrong to me.

[maxlgu]

Hi @hober ,

Note that whether the total is optional or not, it's up to the payment apps to decide whether to show the total price - this proposal doesn't change this behaviour. Whether before or after the proposal, if the payment apps would like to over-charge the users (more than the requested total amount), they can do that. After all, it's the payment apps who have the access to the users' wallets. Also because of that, they would need to show the final charge to the users before the transaction so as to maintain the users' trust.

[aestes]

Rather than making total optional, can the existing pending boolean on PaymentItem be used to support this use case?

For cases like ride sharing, where the total amount is unknown at the time of payment authorization, the total item can be marked as pending. In Apple Pay, for instance, the payment sheet will not display pending amounts.

Seems like if we support both pending totals and optional totals, it becomes more difficult for authors to understand which mechanism is appropriate for a given scenario.

[hober]

@maxlgu, any thoughts on @aestes' comment above?

[rsolomakhin]

Let's loop in @danyao and @mgiuca who have been having similar conversations in such places as w3c/payment-request#912.

[rsolomakhin]

And WICG/digital-goods#5.

[maxlgu]

@aestes : pending total makes sense only for the use case where the final price charged will be determined at some point in the future, like authorizing a payment for a service such as Uber.
Optional total makes sense when the total is already known to the payment app, which has just provided it to the merchant through the digital goods API.

[mgiuca]

I agree @maxlgu . It sounds like "pending" has very different semantics to when total would be omitted because it is already known to the server.

[maxlgu]

Since the main argument of this feature is for the digital good api, this tag review should merge into that one once it exists. Set this tag review as blocked.

[kenchris]

Hi there, any update on this and the Digital Goods API? Will that be send to TAG review anytime soon?

[maxlgu]

This was blocked on @mgiuca 's work on the Digital Goods API.

@mgiuca , what's the status of the Digital Goods API?

[mgiuca]

Apologies for leaving this one. I thought we had already discussed Digital Goods in TAG, but it seems it was only in the context of this one issue.

We will open a TAG review for DG.

[phoglenix]

TAG review opened for Digital Goods API: #571

[kenchris]

@hober did you have any issues with this review issue? It has a dep on Digital Goods, but it would be good to close, if you don't

[kenchris]

@hober this seems to be depending on you? :-) Can you have a look so that we can potentially close this

[cynthia]

We apologize this took so long - we think this has past it's due date, and the other reviewers were happy with this. We are going to close this in the rollups of our VF2F today.