Re: [w3c/browser-payment-api] Change the way we request user data (#65)

@adrianba  said:

> Whether you change an enum or add a field you have to change the spec. Or write an extension spec. This is a feature not a bug - it is necessary for interoperability should it become "very common to collect some new piece of data as part of a checkout process".

In issue #145 Shopify have surfaced another very real requirement that I believe would prevent them from using this API if it was not supported. Note comment from @andrewpaliga:

> we have experienced better cart conversation rates by making the option [of collecting giftcard or coupon codes] available throughout our checkout experience.

This suggest to me that a minor change to my proposal would solve this issue:

```
enum DataType {
  "date",
  "number",
  "address",
  "email",
  "telephone",
  "url"
  "string",
  ...
};

dictionary DataDescriptor {
  required DOMString label;
  required DataType type;
  required boolean optional = false;
};

dictionary ShippingAddressDataDescriptor : DataDescriptor {
  sequence<ShippingOption> shippingOptions = false;
};

dictionary PaymentOptions {
  sequence<DataDescriptor> requestData;
  ...
};
```

Example website code:

```javascript
{
  requestData: [
    {
      label: "Shipping Address",
      type: "address",
      shippingOptions: [...]
    }, 
    {
      label: "Email Address",
      type: "email",
      optional: true
    }, 
    {
      label: "Voucher Code",
      type: "string",
      optional: true
    }
  ] 
}

```
It would be very unlikely that we would ever need to change the `DataType` enum as this is simply a way of hinting to the UA what input control(s) to use and for any new data requirement merchants could simply use the string or number data type.

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/65#issuecomment-212488768

Received on Wednesday, 20 April 2016 15:58:05 UTC