Add an excludedFields BasicCardRequest parameter

[ianbjacobs]

I am starting this new issue based on previous comments from @mattsaxon in issue #26 and issue #5, and inspired by his previous proposal:
w3c/payment-request#143 (comment)

Here's a proposal:

• Add a field for BasicCardRequest: "excludedFields". This list is the merchant preference for the user agent NOT returning a those fields in the BasicCardResponse.
• At least for version 1, user agents SHOULD NOT return the excludedField in the BasicCardResponse.
• Any excludedFields values that do not correspond to field names in section 5.1 of the spec are ignored by user agents.

I'd like to hear from implementers.

[marcoscaceres]

Reminder, to +1 use the GH provided buttons for reactions:

(Marcos deletes all "+1" comments from the issue tracker)

[zkoch]

I think there is value in this, but given that we already have two implementations out in the wild that rely on this spec, I don't think now is the appropriate time to add. I would propose that we consider this for the next version after we get to CR.

[mattsaxon]

Happy for it to be postponed, but let's not close.

[marcoscaceres]

Now might be a good time to return to this. From the members of BasicCardResponse, what's the use case for the merchant excluding any of the members?

[rsolomakhin]

@marcoscaceres The use case is some merchants that don't require CVC or billing address to charge your card. Some merchants make this tradeoff to increase conversions at the cost of higher fraud risk.

[ianbjacobs]

@mattsaxon, do you want to weigh in as well now that we are returning to this?

Ian

[marcoscaceres]

@rsolomakhin, I see. The problem now is that shipping implementations will return all the values (even if we added support for this tomorrow).

Why couldn't a merchant just pretend the values are not there in the response and simply not use them?

[ianbjacobs]

Hi @marcoscaceres,

The merchant wants to say to the browser: "I don't want this, so please don't show UI to the user because that will reduce the chances the transaction will be completed." Right now merchants
can't say that.

Ian

[rsolomakhin]

Personally I'm against giving too many options to the merchant in this case, because I don't want PaymentRequest to become a glorified form builder. If there's demand for such customization, custom payment methods should provide it, e.g., "https://credit-cards.com/no-cvc-or-billing-address".

[marcoscaceres]

I agree with @rsolomakhin. Remember that the Payment Sheet is not a form for the merchant... it's kinda like a "wallet", where users can see all their cards, make modifications/updates to those cards (even if the cards shown have been filtered by type), etc. so it might become confusing if we start arbitrarily taking away things that users expect to be there.

[marcoscaceres]

Just one more point: the assumption should really be that the user has already filled out the information in the basic card storage... there is a good chance of that, specially as time goes on (because the autofill DB will likely have this information) and because the chances of the user previously having used the API on some other site goes up over time.

Thus, the notion of "that will reduce the chances the transaction will be completed" becomes irrelevant and not a concern. In fact, we actually really want users to add as much info as possible, as they only have to do it once and then the whole ecosystem benefits as a result.

[marcoscaceres]

Closing as duplicate of #5.