Open Bug 1432909 Opened 6 years ago Updated 2 years ago

Show the shipping option on the summary of the payment request items

Categories

(Firefox :: WebPayments UI, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: MattN, Unassigned)

References

()

Details

Attachments

(1 file)

Since it's part of the cost that will be paid by the consumer, the shipping option should be listed on the item view along with the subtotal, taxes, etc.
Hmm… I'm confused now about how we expect merchants to use the API with respect to displaying shipping costs to users. My assumption was  that since the UA already has the shipping options provided in the request with their associated costs, the UA would be responsible for showing the shipping option like a display item rather than have the merchant duplicate their effort in maintaining the shipping option plus a shipping display item. The latter seems error prone and will be another case where the UA may look bad because of merchant inconsistencies (e.g. if they don't keep the price of the two synchronized).

From Google's Payment Request samples it seems like they are expecting merchants to duplicate the effort and take care of the shipping display item:

* https://googlechrome.github.io/samples/paymentrequest/dynamic-shipping/
* https://googlechrome.github.io/samples/paymentrequest/shipping-options/

From the spec at https://w3c.github.io/payment-request/#the-details-argument it seems like the merchant shouldn't include their own shipping display item and it should be included in the total the merchant calculates.

We should decide with other implementers on what is correct here and make sure the spec and demos align.

Rouslan & Marcos, attachment 8947676 [details] is what we would like to show for UI, it's a pretty standard UI for online shipping, but it's not clear whether the shipping line should be pulled from the selected shipping option or whether it will be duplicated as a displayItem that we would need to pull out to the bottom section?
Flags: needinfo?(rouslan.solomakhin)
Flags: needinfo?(mcaceres)
We've been operating under the assumption that the merchants have a choice of whether they want to specify the shipping price explicitly in the displayItems. If they wish, they can list out all shopping cart contents and break down the subtotal, tax, and shipping costs. Alternatively, the merchant can specify only the total and not break it down into its components. From my experience in writing sample code, duplicating the shipping option in both displayItems and shippingOptions is not a lot of effort.


I do see your point: we had merchants in the past that expected the browser to do more. For example, we've seen merchants that do not update the total based on the changing shipping price, but expected the browser to do that for them. This was easy to correct, however, after notifying the merchants about it. Perhaps we should call this out more prominently in the documentation.

Given the number of merchants that have integrated PaymentRequest and are now including the shipping option in the displayItems, I am leaning toward fixing the example in the spec and asking any new merchants to duplicate the shipping option in displayItems.
Flags: needinfo?(rouslan.solomakhin)
> From the spec ... it seems like the merchant shouldn't include their own shipping display item and it should be included in the total the merchant calculates.

That's how I've aways assumed it would work, because including it twice is redundant (and error prone, as you mentioned). 

> Given the number of merchants that have integrated PaymentRequest and are now including the shipping option in the displayItems, I am leaning toward fixing the example in the spec and asking any new merchants to duplicate the shipping option in displayItems.

Hmmm... I was hoping it would be the other way around, tbh (because of the reasons above). 

We might need to raise this back at the w3c.
Flags: needinfo?(mcaceres)
Filed bug https://github.com/w3c/payment-request/issues/680 ... but I think it will be settled by whatever developers do in the wild. However, if we find developers are doing things like:

```
if (isChrome || isIE)
  options.displayItems.push(selectedShippingOption)
```

Then we obviously will have a problem (and we might need to adapt our UI :/).
Priority: P3 → P2
Whiteboard: [webpayments]
Product: Toolkit → Firefox
Priority: P2 → P3
Whiteboard: [webpayments] → [webpayments-reserve]
Not part of MVP
Whiteboard: [webpayments-reserve]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: