Re: [w3c/payment-request] Editorial: change around payment handler language (closes #532) (#574)

marcoscaceres commented on this pull request.



> @@ -841,9 +841,9 @@
               </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.
+              <var>data</var> contains filters that exclude the payment

What is being stated in the spec, and the new proposed text doesn't match implementations. If the merchant says:

> I support "basic-card", but only type "debit" of the "mastercard" network. 

consider: 

1. Firstly, `.canMakePayment()` returns "false" in Chrome and Edge. But it returns "true" in Firefox because, theoretically, the user "can make the payment" by later adding a Mastercard debit card (it's also privacy preserving in the Firefox case, because I might not want you to know if I have a card of this type). 
1. Now for `.show()`, the payment sheet will still be shown to the user because basic card still gives the user the possibility to add a card manually. So the whole thing above about matching here, sets up false expectations for developers, and the user agent just ignores it at this point: the payment sheet is still shown and `.data` *is not taken into consideration*.  

Please try it yourself in Chrome or Edge (and the behavior will be the same in Firefox irrespective of what the spec says - so let's make the spec match reality!):

```JS
const pr = new PaymentRequest(
  [
    {
      supportedMethods: ["basic-card"],
      data: {
        supportedTypes: ["debit"],
        supportedNetworks: ["mastercard"]
      }
    },
  ],
  {
    total: {
      label: "The cake is a lie",
      amount: { currency: "USD", value: "1.2" },
    },
  }
)
pr.canMakePayment().then(r => {
  console.log("can make payment?", r);
   return pr.show(); // ALL IMPLEMENTATIONS ALLOW THIS!
}).then(console.log("done", pr)).catch(err => console.log(err))
``` 

Thus, it's up to the "basic-card" or other PMI specs to define how things work (or not!). The `.data`'s `supportedNetwork` and `supportedTypes` are merely a hint (e.g., "visa" can be greyed out as a icon in the UI). In Edge, it doesn't seem to prevent the end-user from returning a Visa credit card number at all. 

In Chrome, the user is prevented from returning a card that is not "mastercard" and "debit". But this is a quality of implementation concern. Chrome *STILL SHOWS THE PAYMENT SHEET* (no filtering or matching happened, even tho `.canMakePayment()` returned false) ... and the merchant still needs to validate the resulting `details`.

My suggestion is we drop the text around `.data` entirely, and then define in each PMI spec how it's supposed to work (because, in the case of "basic-card" it's still waaaaAAAaaaay underspecified). 

-- 
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/574#discussion_r131801838