Intent-to-prototype: optional total field in PaymentRequest

41 views
Skip to first unread message

Liquan (Max) Gu

unread,
May 4, 2020, 3:08:10 PM5/4/20
to blink-dev, paymen...@chromium.org

Intent to Prototype: optional total field in PaymentRequest


Contact emails

ma...@chromium.org 


Explainer

The w3c explainer lives here.


Design doc/Spec

TAG review: https://github.com/w3ctag/design-reviews/issues/512


Summary

Given that when Digital Product Management (DPM) 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.


Motivation

When Digital Product Management (DPM) API is used with PaymentRequest API, it allows developers to specify product Id instead of the total amount when users are buying digital goods from digital stores. In this use case of PaymentRequest API, the total amount becomes redundant (total can be calculated from product Id) or even unknown (app stores may not inform the merchants of the unit price). By making “total” optional, we can improve the developer ergonomics in these cases. Below demonstrates how developer ergonomics are improved.


Without the proposed feature, developers would be forced to put a redundant (if unit prices is known) or a fake (if unit price is unknown) “total” object:

new PaymentRequest([{supportedMethods: methodName, data: {productId: abc’}], {total: {amount: “1”, currency: “USD”}});


With the proposed feature, developers could simply write:

new PaymentRequest([{supportedMethods: methodName, data: {productId: abc’}]);


Risks

Interoperability and Compatibility

Interoperability risk: low

  • The feature is simple enough for other browsers to adopt it.


Compatibility risk: low

  • In the old API, the total field is mandatory; in the new API, the total field is optional. For the web contents that does not specify total, they would get a type error at the constructor in the old API but would be error-free in the new API. In spite of the difference, we assess the compatibility risk as low because the old web contents were supposed to provide the total as it was mandatory.

  • In the old API, the error of missing total field is thrown at the constructor; in the new API, the error is thrown at canMakePayment(), hasEnrolledInstrument() and show(). In spite of the difference, we assess the compatibility risk as low because the old web contents were supposed to provide the total as it was mandatory.


Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: No signals


Ergonomics

This proposal would change the error handling behaviour of “total”. Before the proposal, missing the required “total” would cause a synchronous exception when constructing the PaymentRequest. After the proposal, missing “total” when it is required would cause an asynchronous exception in canMakePayment(), hasEnrolledInstrument() and show().


We deem the ergonomics impact as low. This is because this error is supposed to be corrected before the merchant site goes into production.


Activation

Activation would not be challenging. Developers would activate this feature by simply not providing the total field on the PaymentRequest API.


Debuggability

This feature does not need DevTools support.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, because PaymentRequest is not supported on Android WebView.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5226111782879232


Requesting approval to ship?

No, this feature would be implemented behind a runtime flag.


Tom Jones

unread,
May 4, 2020, 3:37:29 PM5/4/20
to Liquan (Max) Gu, blink-dev, paymen...@chromium.org
I find the entire concept of authorization of a payment with out seeing the amount to be a huge risk exposure that I, for one, would feel to be unacceptable.

thx ..Tom (mobile)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALKRbLa5vq2OzVECwG%3DBcJJeWP4qeKfR%2B3NhCDvRfoVtQPbk3A%40mail.gmail.com.

Rouslan Solomakhin

unread,
May 4, 2020, 3:43:41 PM5/4/20
to Tom Jones, Liquan (Max) Gu, blink-dev, paymen...@chromium.org
Hi Tom,

Thank you for the comment. Please keep in mind that the user would see the total amount in the payment app, which maps the product identifier to a price. Although the website itself does not specify the total amount, it is assumed that the web developer manages an account with the payment app and it's the web developer who defines the product prices for the payment app. Does that help to alleviate your concern?

Cheers,
Rouslan

You received this message because you are subscribed to the Google Groups "payments-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to payments-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAK2Cwb7X3Kop2ZRPn_dNULPRFJFMTsDKPJEKoXYa6QpmJbmiEw%40mail.gmail.com.

Tom Jones

unread,
May 5, 2020, 7:03:34 PM5/5/20
to Rouslan Solomakhin, Liquan (Max) Gu, blink-dev, paymen...@chromium.org
That is certainly not the message i heard on the w3c list. They just want to minimize the time that the user spends on the process. Someone needs to take the case of the user.
Peace ..tom

Iwan Lesmana Riza

unread,
May 5, 2020, 7:30:20 PM5/5/20
to Tom Jones, Rouslan Solomakhin, Liquan (Max) Gu, blink-dev, paymen...@chromium.org
440px-Booking_Holdings_Inc._Logo.svg.png
alert2.wav
alert.wav
email.wav
request.wav
Candi-Borobudur.jpg
news.wav
connect.wav
220px-Logo_of_Booking_Holdings_Inc,(lock_up,_stacked_with_Brands,_full_color).png
ok.wav
expert.wav
OpenID_Certified.png
Math 3D.ico
disconnect.wav
1280px-Booking_Holdings_Inc._Logo.svg.png
stops.wav
Reply all
Reply to author
Forward
0 new messages