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

Hi all,

Here is some additional thinking about billing address and third party payment handlers.

* Due to the nature of some payment methods (e.g., real-time financing, push payments), payment should not happen until after the "definitive" billing address is known to the payment handler.
* Today we do not have a way for the payment handler to tell the merchant "here is the definitive billing address". Indeed, by design we don't have a way for the payment handler to interact with the merchant directly for any data updates.
* Instead, updates happen in the sheet through user interaction. Events fire and the merchant can update the total, etc.
* One approach is to say that the "definitive billing address" is the one provided by the user, before the payment handler is selected. The user might choose a billing address from a list stored by the browser. This would cause an event to fire and the merchant could update the total. Then the user could select the payment handler and the payment handler could receive the user-asserted billing address.
* Once in the payment handler, if the billing address is correct, everybody is happy and payment can take place.
* However, if the billing address differs from one known within the payment handler, we have an issue. One option is to allow the payment handler to ask the user to confirm a new billing address. If the user agrees, then fire an event to tell the merchant, which can update the total which is given to the payment handler. One way to do this is through some sort of payment handler retry() mechanism, where the payment handler tells the browser (upon action by the user):

 - Close the payment handler window and return to the sheet
 - Ask the user to confirm the billing address (populated with the data from the payment handler)
 - If the user does, that triggers the onbillingaddresschange event and the merchant can update the total.
 - Then the user reselects the payment handler and starts again, this time with the proper billing address and total.

In other words: let's have all the data updates happen in the sheet so that the merchant can learn about them through events.

This would allow the payment handler to proceed to payment if it wants, or ask for a correction by the user (in the sheet) before proceeding to payment.

I realize this will be a non-pipeline user experience, and thus could potentially be confusing. I welcome suggestions for handling this in other ways, but I note that retry() from the merchant side is not likely to work in general because payment may have already happened (with a potentially incorrect total) by the time the merchant gets to do a retry().

There may also be some ways to simplify the user experience of getting the definitive billing address from the user:
 * If the merchant does not request billing address, there is no need to surface UX for it.
 * If the merchant does request billing address  the browser does not have to surface UX for it initially.
    a) If the user chooses a card stored in the browser (which has associated billing address), there is no need to surface UX for choosing billing address; the event can fire with the card's billing address. 
    b) If the user chooses a third party payment handler, the browser could (finally) surface UX to prompt the user to confirm or enter the billing address before launching the payment handler. There might be some options to make this smooth, such as choosing from among:
     * "Same as shipping address"
     * Choosing the most recently used billing address with that payment handler. 
     * The ability to choose from among billing addressed stored with instruments in the browser.
     * Other manually added billing addresses.

   Once the billing address has been selected, the browser then launches the payment handler.

My "hope" is that the billing address is correct most of the time, and thus the "payment handler retry()" UX is not necessary often.

By the way, it has been pointed out to me that billing address information for tax purposes may also become a more important consideration in the US [1].

Ian
[1] https://www.nytimes.com/2018/06/21/us/politics/supreme-court-sales-taxes-internet-merchants.html

-- 
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-410339707