Re: [w3c/browser-payment-api] Should API support billing address capture (for tax computation)? (#27)

The more things we keep trying to add the more I tend to think that a better design would be to provide new elements/components that merchants can put in their website to simply customize their checkout page. For example:

```html
<shipping-address on-change="callme(event)"></shipping-address>

<billing-address on-change="callme(event)"></billing-address>
```

This component could be provided by the browser (or a polyfill), it could refuse to give access to the choices shown to the user unless selected, fire an "on address change" event when the user changes their address -- and let the merchant site customize their checkout experience around it. This would be a low-level component-based approach to providing a better checkout experience whilst also leveraging the browser's ability to provide this kind of information.

The idea that we're going to be able to specify every checkout flow (or "at least" the common ones) and do so in a sensible way I think is perhaps not as achievable as we'd like to think. When the checkout flow doesn't work for the merchant, they have to abandon the whole API and start from scratch. Wouldn't it be better to build out some components (that could also be polyfilled) that a merchant can use to assemble their own checkout experience?

With this approach they can configure it however they like -- update address/shipping options as they please and so forth, and still leverage the information that the user agent can provide to them. Then, once the final price has been calculated, they can call the payment request API with all of the requisite information they've collected to cause the user to select a payment app to complete the payment.

---
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/27#issuecomment-218786016