Add quantity prop to items

[felipenmoura]

User may want to buy 2 or more items of a same product and the best way to show that to the user is by showing a quantity column.

This is a very common attribute in bills and receipts and could help users feel more confident when finishing a purchase, making it more clear.
Also, unit price would be required as well.

Please let me know what do you think about it?

[marcoscaceres]

We generally discourage merchants from going into this level of granularity. This is generally best handled on the checkout page itself.

We used to have a best practice note in the spec about this, but seems to have vanished :/ I'll add it again.

[felipenmoura]

Got it.
Although, I do believe users see that "modal" as the last step to finish the payment process and that it is their last chance to verify everything is ok. If you have an e-commerce and users can buy many different products in different quantities, this could be of use.

Besides, that is the information people would see in the receipt.
It does not help much to see in the checkout page something like:

3x t-shirt for $30 = $90
2x mug for $15 = 30$
1x cap for $20 = $20
total = $140,00

and then, when selecting the credit card to actually pay for it, see:

t-shirt for $90
mug for $30
cap for $20
total = $140,00

You get my point? Even though the total is the same, it feels like there is a divergency.

But with that said. I do believe you have thought and discussed it through and, if this is the decision you all believe is the best practice, I will go along. Thanks.

[webpayments-specs]

Hi, may I just clarify my thoughts. There are three types of receipt. Delivery, sales and payment. In the fuel industry all three have specific attributes and rules (mainly fiscal and taxation). Take a fuel card being used to “pay” actually no real payment is involved. Customer can only be provide with a receipt for the delivery of the goods. The unit price and fiscal stuff like VAT and Sale taxes are charged on the invoice the fuel card operator sends to fleet owner. So no VAT or unit price is allowed on the delivery receipt. The sales receipt contains all the fiscal and unit price(incl quantity) by line items. The payment receipt is just the payment side and equates to the single line you see on your credit card or debit card statement. E.g. Tesco £95.35. No other details. Are you sure which receipt you are talking about. A payment receipt (in my model of the world) does not need to know anything about line items. Think of the PIN Pad at the end of the transaction it just says £95.35 to pay, please press IK to confirm” or something similar. The fuel and convenience needs to keep these three receipts quite distinct and separate. I know some retailers want a combined sales and payment receipt but logically they are different things. At least in my mind. Hope this makes sense.

…

Sent from my iPhone John Carrier IFSF projects manager On 29 May 2019, at 22:01, Felipe Nascimento de Moura <notifications@github.com<mailto:notifications@github.com>> wrote: Got it. Although, I do believe users see that "modal" as the last step to finish the payment process and that it is their last chance to verify everything is ok. If you have an e-commerce and users can buy many different products in different quantities, this could be of use. Besides, that is the information people would see in the receipt. It does not help much to see in the checkout page something like: 3x t-shirt for $30 = $90 2x mug for $15 = 30$ 1x cap for $20 = $20 total = $140,00 and then, when selecting the credit card to actually pay for it, see: t-shirt for $90 mug for $30 cap for $20 total = $140,00 You get my point? Even though the total is the same, it feels like there is a divergency. But with that said. I do believe you have thought and discussed it through and, if this is the decision you all believe is the best practice, I will go along. Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#861?email_source=notifications&email_token=AEHSJBV6MKB2SARBKA6G23DPX3VETA5CNFSM4HELXONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQUA4Q#issuecomment-497107058>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEHSJBTLTSZTUU6VELFNGMTPX3VETANCNFSM4HELXONA>.

[felipenmoura]

Sure it does make sense.

I just thought it could be useful as an option. Developers could add this extra information according to their needs. So far, it is just not possible.

In Brazil, for example, we have the "bank billet", which usually describes the items in some level of detail. Or if you go to a market/store/restaurant, the receipt also list all the items.
I remember the first time I used this API I thought it was an "obvious" option and was searching for it in documentation for a while before giving up.

But again, if it has been thought and discussed previously, I accept the decision hehe.
I just thought it could be an interesting "opt-in" feature that would cause no harm, if available :)

Thanks for your time.

[marcoscaceres]

Making as "Future Candidate Feature" - particularly as this is a regional difference/expectation and we might need to call that our (or actually add quantity) to deal with it.