Re: [w3c/browser-payment-api] Should the merchant be able to request your email and recipient phone number (#1)

> the mechanism for doing this should be more generic and extensible to accommodate new items in future

While I disagree that we should be creating a generalized customer information request API, it looks like a few in the group are determined to do it anyway, so we might as well do it right.

+0.5 for @adrianhopebailie's proposal. The Web Payments Community Group's Checkout API spec had a mechanism that I found easier to parse (as a developer reading the code) than @adrianhopebailie's proposal above via the .send() and .request() customer info calls:

http://wicg.github.io/web-payments-browser-api/checkout-api.html#the-checkout-interface

which would look something like this in practice:

```javascript
var paymentRequest = ...;
paymentRequest
  .send('paymentItem', paymentItems)  // send line item estimate to UA
  .request('shippingAddress')               // request shippingAddress from UA
  .request('email')                                 // request email from UA
  .request('phoneNumber')                   // request shippingAddress from UA
  .addEventListener('shippingAddressChange', shippingAddressChanged)
  .start()                                               // start the UI
  .then(finishRequest);                      // UI has collected the info
```

you could even reduce it to:

```javascript
paymentRequest
  .request(['shippingAddress', 'email', 'phoneNumber')
```

The benefit here over what @adrianhopebailie is proposing is that we don't make the payment request hold stuff that's not really about the payment request. That is, requesting an email address doesn't really have anything to do w/ the request for payment. It's just information that you'd like to gather from the customer. It feels like the payment request object is turning into a huge grab bag of payment UI configuration data.

I'd also like to underscore that we're falling into the trap of designing high-level APIs (checkout experience) instead of focusing on the low-level ones (simple request for payment) first, which @jakearchibald warned us against (as have many other folks that have designed browser APIs in the past).

---
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/browser-payment-api/issues/1#issuecomment-207464821