-
Notifications
You must be signed in to change notification settings - Fork 20
Add an excludedFields BasicCardRequest parameter #29
Comments
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. |
Happy for it to be postponed, but let's not close. |
Now might be a good time to return to this. From the members of |
@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. |
@mattsaxon, do you want to weigh in as well now that we are returning to this? Ian |
@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? |
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 Ian |
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". |
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. |
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. |
Closing as duplicate of #5. |
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:
I'd like to hear from implementers.
The text was updated successfully, but these errors were encountered: