There are cases (such as with digital goods), where an address is needed, but there is no notion of shipping. I would prefer to be more bold in this edit by changing the name of this enum to PaymentAddressType and changing requestShipping to requestAddress, but I wanted to be on the safe side to start. Please let me know if the renaming would be agreeable as well.

Billing address requirement depends on payment methods. So, bitcoin, for example, would not need it, but credit cards do need it. Therefore, I'd prefer that we keep billing address in method-specific data. I suggest that you send a patch to "Basic Card" spec, which has billing address in https://w3c.github.io/webpayments-methods-card/#basiccardresponse. I'm in support of something like this:

new PaymentRequest([{
    supportedMethods: ['basic-card'],
    data: {requiredFields: ['billingAddress']}
  }], shoppingCart);

I disagree with your premise, the merchant will often need an address in order to compute the taxes owed. If I accept your premise, I don't understand how this would work. When would the browser surface an address selection?

I believe we discussed billing address in issue 27:
#27

(which may not have concluded cleanly)

Ian

I would prefer that merchants estimate the tax and indicate that to the user by placing a pending: true on the tax in displayItems. The merchant is also able to confirm the updated price after they receive the PaymentResponse.

If we must calculate the tax precisely during the PaymentRequest flow, user agent needs to provide billing address to the website before the user clicks "Pay" in browser UI. Is the country enough for tax purposes? A user agent generally should require a user action for this to happen in a privacy-preserving manner. Therefore, we need:

1. New option "requestBillingAddress" (or "requestBillingCountry"). This is similar to existing option "requestShipping".
2. New user interface in implementing user agents to prompt the user to send their billing address or country to the website.
3. A new event on PaymentRequest object: "billingAddressChange" or "billingAddressChange", for example. This would work similarly to "shippingAddressChange".

This is a fairly involved addition to the API. Therefore, I prefer the estimation workaround. How strong is the preference for this?

In the US (for states with sales taxes that are destination-based), the tax applies to the shipping address not the billing address. That would apply even for digital goods; the tax is calculated based on where the customer "takes possession" of the product, not whatever their billing address is. This would seem to mean that a "shipping address" should be gathered for digital goods that need to be taxed, not a "billing address", at least for tax purposes. Taxes are fun.

So, making this a shipping type as @rvm4 suggested probably makes sense, however, perhaps the name should be something like "tax" or "taxation" or "usage" rather than "billing" so as to avoid confusing it with a "billing address" which has to do with payment methods, as @rsolomakhin noted.

The canonical example here is for digital goods. Shipping address doesn't quite fit because nothing is shipping.

Why would you have to send a merchant the address prior to Pay being clicked? You could be given a list of items that does not include tax, but specify in the options that I need a billing/taxation address and when that event is received, append another item to the list that captures the applicable tax.

I think this is actually one of our oldest issues, see #27.

We didn't have a good solution to this for a while, but I agree that this is probably the right place to build this in. There are a few things to consider, though:

• VAT rules vary per country. Some are billing, some are where the good is being shipped, and others are the home address of the purchaser, which is independent of where the good is being shipped or the billing address used. Fun.

• As such, perhaps just calling this "vat" or something similar might be simpler. It gives some flexibility to implementors about how they want to handle the tricky situation.

• We would need to spec out a behavior change here. Presumably a type of "vat" doesn't require shipping options, so that should probably be spec'd out.

@zkoch,

Could the editors discuss this at their next meeting and suggest something on this thread?

Ian

I think our suggestion is similar to what I mentioned above:

• We should figure out if "billingAddress" is the right label for this, or if we should make more generic as "vat"

• We need to spec out the behavior change, since this probably won't require shipping options

Do we need to hold up this PR for figuring out the label? The enum name is immaterial to what gets rendered in the browser, is it not? Let's hash this out in the F2F if need be.

I don't think we can merge until we clarify what happens with shipping options when this is selected.

Remarks from the 03/02 call:

• User agent being able to properly differentiate and store billing addresses from shipping addresses is important to the user experience, but I'm a bit worried that this PR incentivize user agents to not do that
• From a developer experience perspective, using billing_address feels really wonky, if the goal really is vat calculation for digital goods, I think we should call it vat_address instead of billing_address. The goal is also to clearly separate billing address tied to payment instrument and the address that have influence on the total amount.

We discussed on today's WPWG call:
https://www.w3.org/2017/03/02-wpwg-minutes#item03

The group supports support for VAT info collection in v1 of the spec. We ask the
editors to evaluate how to do so and the cost of doing so.

Thanks!

Ian

Closing this to continue discussion in #27. We've agreed we would like this, but needs a bit more work to figure out interactions with shippingOptions, etc