search

w3c / payment-request

Payment Request API
https://www.w3.org/TR/payment-request/
Other
489 stars 135 forks source link

Proposal to make the amount field in PaymentShippingOption optional #901

Closed sahel-sh closed 4 years ago

sahel-sh commented 4 years ago

The amount in paymentshippingoption dictionary is not always needed. For example when there is only one shipping option and it is free, or when the merchant chooses to include the shipping price in the label (e.g. $5 express delivery, free standard shipping, etc)

ianbjacobs commented 4 years ago

Seems reasonable.

marcoscaceres commented 4 years ago

Changing this might break backwards compatibility, so we'd have to work out a reasonable upgrade strategy if we do this.

I'm also worried that excluding the amount on the shipping option might be confusing for users: if the merchant excludes the amount, but then the total changes based on the selected shipping option after the user hits Pay, then users will get confused (leading to loss of trust in both the merchant and the payment sheet)... as such, if shipping is free, then the total for shipping should be shown as $0.

sahel-sh commented 4 years ago

Thank you Marcos for your response

Changing this might break backwards compatibility, so we'd have to work out a reasonable upgrade strategy if we do this.

Would you please explain more about your backwards compatibility concern? Making this optional will not break merchant's using Payment Request APIs. It might break payment apps which support shipping delegation, but since delegation is a new feature, I am not aware of any apps which has implemented or are working on shipping delegation.

I'm also worried that excluding the amount on the shipping option might be confusing for users: if the merchant excludes the amount, but then the total changes based on the selected shipping option after the user hits Pay, then users will get confused (leading to loss of trust in both the merchant and the payment sheetChanging this might break backwards compatibility, so we'd have to work out a reasonable upgrade strategy if we do this.

I think it should be merchant's call to see if the field is needed or not, e.g. when the shipping option label already includes the price, explicitly passing amount is redundant. An example use case here is when the payment app's pay.js library (e.g. Gpay) is using Payment Request API on behalf of merchant's website and includes the price in shipping option label. Our current recommendation to them is to pass arbitrary values as amount that you know you are not gonna use. However bypassing a required field like this suggests that maybe the field should not be required to begin with.

marcoscaceres commented 4 years ago

Hi @sahel-sh! sorry, just coming back to this.

Would you please explain more about your backwards compatibility concern? Making this optional will not break merchant's using Payment Request APIs.

Right, my concern is breaking existing user agents: for example, right now, if Firefox or Safari or an outdated Chrome sees a shipping options without an amount, it would throw.

So we'd need some kind of upgrade strategy for "legacy browsers". You are correct that it wouldn't affect merchants, however.

I think it should be merchant's call to see if the field is needed or not, e.g. when the shipping option label already includes the price, explicitly passing amount is redundant.

Respectfully, including the price in the label might be considered bad practice. Consider, the reason we have structured data for amount is so browsers can accurately format, display, and/or announce the amount in an unambiguous way. For example, "$5 express delivery"... is that US dollars or Australian dollars? The formatting could also become ambiguous for larger numbers, allowing the browser to disambiguate the amount via internal localisation libraries (or via the OS's l10n preferences for how currencies should be displayed).

sahel-sh commented 4 years ago

Thanks @marcoscaceres for explaining. The PH asking for this is no longer interested; Given the browser compatibility risk explained in the above comment and no interest from PHs, I will close the issue.