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

As we’ve been interviewing developers who are integrating with the Payment Request API, we’ve realized that collecting billing address is critical to some of their businesses.

There are multiple use cases we’ve uncovered, but the primary use case that makes us believe that billing address should be a core consideration of the Payment Request API (rather than handled by individual payment method specs) is allowing merchants to recalculate the line items based on the payer’s location (e.g. for VAT).

Because billing info is not part of the Payment Request API, the current state is that payment methods will likely specify their own billing address APIs. This is sufficient[0] for simply collecting billing address information, but because it’s not a part of the top-level API, developers cannot hook into billing address changes and update the `total` and `displayItems` that they want to (and in order to be compliant[1], need to) display. This is our primary concern.

Secondarily, there’s nothing in the spec today that requires that payment method APIs build in billing address considerations like basic-card does today. Even the basic-card spec itself is a ticking time bomb. At the moment, Chrome’s implementation of basic-card requires and will always return a billing address. However, there’s nothing in the spec that requires this or allows the developer to request this, so as soon as there is another payment handler for basic-card that does not supply billing address, the developer’s integration may break.

Strawman proposal, similar to how shipping addresses are handled:
- Expose `requestPayerAddress` as a Payment Request option.
- Expose `payerAddress` on the Payment Request.
- Expose a `payeraddresschange` event that is emitted when the user selects a payment method.
  - The `total` may be updated depending on the billing address at this point.

Unfortunately, unlike the shipping address, billing addresses are collected with the payment method, so this seems like a payment handler spec addition, too. On the other hand, the Payment Request API already specifies parameters like `payerEmail`, `payerPhone`, and `payerName` — perhaps it wouldn’t be too bad to base a billing address API off of this precedent.

[0] Sufficient, but not great, because each payment handler may return a different billing address format, for instance.
[1] For the VAT case specifically, the tax is usually included in the `total`, but in order to be compliant you need to show the VAT breakdown, which varies by country, in the line items.

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