Re: [w3c/payment-request] remove matching .data text from .show() (#578)

marcoscaceres commented on this pull request.



> @@ -839,33 +841,33 @@
               <var>acceptPromise</var> with that error and terminate this
               algorithm.
               </li>
-              <li>Determine which <a>payment handlers</a> support
-              <var>identifier</var>. For each resulting payment handler, if
-              payment method specific capabilities supplied by the payment
-              handler match those provided by <var>data</var>, the payment
-              handler matches.
+              <li>Add each <a>payment handler</a> that supports

> BUT, it does ignore the case where the browser is able to fail fast because the handler allows it to.

There is no browser today that fails fast. If a browser in the future does decide to fail fast, we should amend the spec then.  

Again, I feel very strongly that we should only document how things work today for the purpose of CR: We can spin up a "V2" very easily in a few weeks, the day _AFTER_ CR, if we want to add any extended behavior. If we try to capture what future browser engines will do now, we will likely get it wrong - so let's do it right when the time comes (in a "V2" please!). 

> The argument that the payment sheet is still shown is correct BUT that is a side-effect of how the basic-card payment handler is implemented in those browsers. i.e. It claims that it supports all networks and card types so it always matches.

Actually, we are both wrong (I accidentally misled you, sorry!): When Chrome doesn't know the network, it restricts to the networks it knows about (Visa, MasterCard, etc.) - while allowing any type (I was surprised by this too! 😱). 

So, if a merchant requests "this-does-not-exists" and/or "voyager", they will likely get back a "visa" card (or something else Chrome supports and the end-user has on hand). If the user doesn't have any other card on hand, they have to abort the payment request. 

I've specified the above here:
https://github.com/w3c/payment-method-basic-card/pull/39/

However, my assertion above still holds. The `.data` doesn't play a role here in today's implementations. It may in the future, but again, please please please 🎶PLLeeaAAAASssseeEE🎶, let's not add aspirational things right before CR. We should be looking at reducing the spec right now, not growing its scope. 



-- 
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/pull/578#discussion_r132133079