A distinct invoice address should be supported

[GSPP]

It is common to be billed at one address and receive the shipment at another. PaymentResponse should have a field for the invoice address (and null if not chosen differently from the shipping address which is most common).

See https://w3c.github.io/browser-payment-api/#shippingaddress-attribute-1.

[ianbjacobs]

Hi @GSPP,

Thank you for the comment. I have a couple of observations about past discussions:

• This was one of our earliest issues:
  Should API support billing address capture (for tax computation)? #27

• We discussed it most recently face-to-face in March [1] . There is agreement that it's important for the use case of billing address affecting price for digital goodes. However at this time we do not plan to add the feature into the specification. This could well be a "v2" feature based on experience gained through the API.

@rvm4, I have not checked in lately to see whether there are any proposals in the works around this feature.

It seems to me that the WG needs to do a better job of documenting this in our FAQ [2], so I have just started an entry [3]. It would also be good to show some good practice [4] for gathering the necessary data through some other means than Payment Request API.

I am pinging @rsolomakhin and @andrelyver in particular to see if they have any good practice code to share.

Thanks again for the feedback,

Ian

[1] https://www.w3.org/2017/03/23-wpwg-minutes#vat
[2] https://github.com/w3c/payment-request-info/wiki/FAQ
[3] https://github.com/w3c/payment-request-info/wiki/FAQ#does-payment-request-api-enable-merchants-to-request-a-separate-billing-address
[4] https://github.com/w3c/payment-request-info/wiki/CodeExamples

[repalogic]

In my point of view (we develop ecommerce systems), postponing this request is quite difficult as it might be an important requirement in some ecommerce use cases. Not supporting separate invoice addresses would make the API not usable at all and thus is quite critical.

[ianbjacobs]

Hi @repalogic,

Basic Card now includes billingAddress:
https://w3c.github.io/payment-method-basic-card/

It seems that the group's preference at this time is to include billing address in the payment method (if needed there) rather than elevate it to the payment request API.

Let me know if this helps.

Ian

[GSPP]

OK, thanks for that detailed information.

Clearly, I have missed a lot of prior discussion. But it seems to me that the billing address logically is not a property of the payment method. A billing address is a property of any purchase and be it only for tax reasons. It helps you prove to the tax office that the purchase was indeed made in the name of your business and was not some private purchase repurposed for tax evasion.

So regardless of whether this is a CC payment, a wire transfer (very common in Germany), cash by mail, or even a cryptocurrency payment, there must be a billing address.

You state that this might become a v2 feature... OK, but it will be hard to find a use case for this standard if this is missing. In all the online purchases that I made and that I recall the website always let me pick a separate address. This seems to be important (it was to me many times).

On the one hand you can query a separate address from the user outside of the browser provided UI. On the other hand that's confusing to the user and might give them anxiety that they will not be able to pick a separate address at all. Not good for conversion rates. The user might just leave and order elsewhere.

[mattsaxon]

Today at the working group is was further agreed that this would not be elevated into the PaymentRequest API.

It was however agreed that the Address definition in https://www.w3.org/TR/payment-request/#paymentaddress-interface could be reused in any payment method.

This allows a consistent definition to be used across all payment methods.

A further thought that occurred to me post this discussion was that if there were a base type for payment method response that included billingAddress, that all payment method responses MUST inherit from, then this would meet the need to force every payment method and (by implication) every payment instrument to have a billing address. This approach would remove the need to change PR API and be consistent with all known implementations that are currently deployed.

I note that this 'mistake' is easy to make as neither tokenised card nor credit transfer has included a billing address in their draft specifications, despite the authors (I'm one of them) being aware of this requirement.

Furthermore w3c/webpayments-methods-tokenization#17 discusses the reuse of data dictionary items between specifications which is as yet unresolved.

I propose that we discuss the merits of duplication vs inheritance further at the slot on tomorrow's agenda at 15:30 https://github.com/w3c/webpayments/wiki/FTF-April2018 (should there be time)

[mnoorenberghe]

then this would meet the need to force every payment method and (by implication) every payment instrument to have a billing address.

If we go down this route then we should definitely have a requestBillingAddress (or similar) flag on PaymentOptions so UAs will know when the billing address is actually required by the merchant and therefore this can be communicated to the user.

[ianbjacobs]

@marcoscaceres, do you have a pointer to the discussion/work on a reusable address object?

[marcoscaceres]

It's threaded through:
#654

For this particular use case, we would need to specify something like @mnoorenberghe suggests in #550 (comment) (add .requestBillingAddress: true to options).

No changes to the the PaymentAddress sections would be needed.

[ianbjacobs]

@mattsaxon, I've raised an issue about billing address on the tokenization spec:
w3c/webpayments-methods-tokenization#40

[ianbjacobs]

I am closing this issue because PR API now supports billing addresses.