Intent-to-prototype: optional total field in PaymentRequest

[Liquan (Max) Gu]

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]

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]

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]

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]

Ok

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK2Cwb4RHp-_DJCa0q2aWamucxqGLu7z1T5unOV-EK%2BhE%3D%2BP9w%40mail.gmail.com.