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

I am a little skeptical that we really need to encompass every payment flow, like coupon codes, in the browser's built-in payment sheet. This seems like something that can easily be applied in the "shopping cart" phase, before clicking the "checkout" button. But I guess I'll leave questions of "should we" to the experts/working group, and instead help with the "how do we" questions...

> ```webidl
> partial dictionary PaymentOptions {
>  // 255 max, 0 means no offer codes accepted
>  octet requestOfferCodes = 0;
> }
```

Don't use octet in this way, or impose arbitrary computer-ese limits like 255 in scenarios where they aren't domain-appropriate. Note that in this design passing 257 will be the same as passing 1.

See https://w3ctag.github.io/design-principles/#numeric-types for the general guidance in this area.

```js
ev.updateWith({
  offerCodeErrors: [
    { offerCode: "SPRING-SALE", error: "Code already used." },
    // Duplicate, oops
    { offerCode: "SUMMER-SALE", error: "This is ignored." },
    { offerCode: "SUMMER-SALE", error: "Invalid code! Try again." },
  ],
});
```

To avoid the duplicate problem, you could use `record<DOMString, DOMString>`, so that the above becomes

```js
ev.updateWith({
  offerCodeErrors: {
    "SPRING-SALE": "Code already used.",
    "SUMMER-SALE": "Invalid code! Try again."
  }
});
```

Maybe this is inconsistent with other error-providing plans though.

-- 
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-387435095