Re: [w3c/payment-request] Support for gift cards and discount codes (#145)

@Krystosterone, this is invaluable feedback! Thank you! 

> To start it off, Shopify uses the field for both discount codes and gift cards alike. Now the interesting part here is that we only ever allow the customer to apply one of each. I'll follow below with some user stories and scenarios that we found to work best for the user experience.

I wonder if we need to treat each differently, because each can have a different input modality. For instance, I can scan iTunes gift cards with my camera.

<img width="400" alt="screenshot 2018-05-08 18 14 59" src="https://user-images.githubusercontent.com/870154/39747909-f96e2fe4-52f1-11e8-85cb-e18e82bc661a.png">

(We don't need to get this fancy... just showing what user's expectations might be - at least, I'd want a comparable experience, because the iTunes OCR input is a real treat on many levels.)

> As a side note (and this might become more of a browser vendor implementation detail), we change the copy on the offer code field per merchant use case. For example:

Then we could have:

```JS
requestOfferCodes: true,
requestGiftCards: false,
```

That would also allow the browser to localize the copy in the way you demonstrated. 

> Finally, we allow discount codes to be applied through URL permalinks, to support email promotions for example.

I don't know what this means exactly. That the code is a URL? That's ok, I think.

> rather, offer code line items surface as removable receipt line items on our checkout.

Ah, so `PaymentItem` have an associated `offerCode`, and then we would need some kind of event for the removal (current proposed model might allow for this).

It might get tricky if you have multiple `displayItems` items with the same code applied. I guess the browser groups them together by code, and then allows trashing them all at once... yeah, that might be nice. 

> Is the requestOfferCodes attribute necessary? If we would consider Payment Request having a single offer code input field that is either there or not, with no possibility to edit offer codes (only to override them), is that attribute still necessary?
> I quite liked the idea of keeping it just as a boolean (as per the first draft)

In the case where you can trash offer codes from the `displayItem`, directly, then it could work.

> How does offerCodes being populated affect the UI? i.e. Does the integrator still have to add a display item themselves for an offer code line item?

My thinking was that they would show up in the UI, but the user would need to apply the ones they want (if any).

> This is to say, should the offer code input concept be seperated from the offer code line item? Could it be possible to make offerCodes part of the displayItems rather than a seperate entity?

Yeah, something like that could work. I'll need to rethink it all now :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/145#issuecomment-387335960