Re: [w3c/payment-method-basic-card] Support for fine-grained request for billing information (#72)

**NB:** This relates to Billing Address NOT Shipping Address so let's keep the scope limited to that.  

This is a critical aspect of the discussion because Billing Address is dealt with at the level of **Payment Methods** whereas Shipping Address is a function of the core PR API.

As it stands, Billing Address is only defined in the Basic Card payment method specification.

However, what we have observed is that the need to get a Billing Address is a common requirement (it's used in Google Pay and ApplePay for example) so we should consider carefully how this could be incorporated into the core PR API and design this **properly** for v1.1.

Another thing we have observed is that a Billing Address is always tied to a **payment instrument** (irrespective of payment method) so it makes sense for this data collection to be something that is only possible after the user has selected a **payment instrument**.

**NB:** The user may not yet have selected a **payment instrument** when they select a **payment handler**. It's possible that they still need to select a payment instrument AFTER selecting a payment handler before the browser can accurately reflect that a specific **payment method** has been selected.

I.e. the general flow embodied by the specs is as follows, with possible optimisations in specific scenarios:

1. Merchant requests payment and specifies accepted **methods**.
2. Browsers calculates the intersection of **methods** requested and **methods** supported by registered **handlers**
3. Browser prompts the user to select a **handler**
4. User selects a **handler** which is invoked
5. User selects an **instrument**
6. The browser notifies the website that the **method** has changed (raises the onPaymentMethodChanged event).

Note: The merchant, at this point, only knows which **method** the user has selected not details about the handler or instrument.

Note: With Basic Card the UX is slightly different. The browser presents the user with **instruments** to select so as soon as these are selected we go straight to 6.

I recap this to indicate that we should look at updating the design of the `onPaymentMethodChange` event to be more aware of these distinctions and not simply update Basic Card which is somewhat exceptional.

Currently @aestes proposal and the way that GooglePay interacts with the website regarding Billing Address (if I recall how @rsolomakhin explained it to me) is a bit of a "hack" to get around the fact that Billing Address is hidden behind payment methods which have no common standard for the data they require or return. 

So concretely, I propose that we look at updating the `PaymentMethodChanged` event to include methods that allow for the interactions/negotiation suggested by the Privacy IG review.

Something like this:

```
const basicCardRequest = {
    supportedMethods: 'basic-card',
    data: {
        supportedNetworks: [...],
    },
};

const details = ...;

const request = new PaymentRequest([basicCardRequest], details);
request.onpaymentmethodchange = async (event) => {
    const [country] = await event.requestBillingAddress(["country"])
    // assume that the merchant detects the country as 'US' and would now like to request the state.
    const [state] = await event.requestBillingAddress(["region"])
};
```

This would be a significant change to the API so I suggest we aim to do this in v1.1 and for now we accept that the proposed changes to Basic Card may be sufficient.

-- 
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-method-basic-card/issues/72#issuecomment-481275334