Add CanMakePaymentEvent.

index.html

@@ -1008,6 +1008,91 @@ <h2>
           });
         </pre>
       </section>
+      <section>
+        <h2>
+          Filtering of Payment Instruments
+        </h2>
+        <p>
+          Given a <a>PaymentMethodData</a> and a <a>PaymentInstrument</a> that
+          match on <a>payment method identifier</a>, this algorithm returns
+          <code>true</code> if this instrument can be used for payment:
+        </p>
+        <ol class="algorithm">
+          <li>Let <var>instrument</var> be the given <a>PaymentInstrument</a>.
+          </li>
+          <li>Let <var>methodName</var> be the <a>payment method identifier</a>
+          string specified in the <a>PaymentMethodData</a>.
+          </li>
+          <li>Let <var>methodData</var> be the payment method specific data of
+          <a>PaymentMethodData</a>.
+          </li>
+          <li>If <var>methodName</var> is a <a>standardized payment method
+          identifier</a> or is a <a>URL-based payment method identifier</a>
+          with <code>"supported_origins": "*"</code> in its payment method
+          manifest, filter based on <a data-lt=
+          "PaymentInstrument.capabilities">capabilities</a>:
+            <ol>
+              <li>For each <var>key</var> in <var>methodData</var>:
+                <ol>
+                  <li>If the intersection of <var>methodData[key]</var> and
+                  <var>instrument.capabilities[key]</var> is empty, return
+                  <code>false</code>.
+                  </li>
+                </ol>
+              </li>
+              <li>Otherwise, return <code>true</code>.
+              </li>
+            </ol>
+          </li>
+          <li>Otherwise, fire the <a>CanMakePaymentEvent</a> in the payment
+          handler and return the result.
+          </li>
+        </ol>
+        <div class="issue" data-number="157">
+          This is the current thinking about filtering of payment instruments.
+          As we continue to experiment with implementations, we are soliciting
+          feedback on this approach.
+        </div>
+        <section id="capabilities-example" class="informative">
+          <h2>
+            How to specify capabilities
+          </h2>
+          <p>
+            Example of how a payment handler should provide the list of all its
+            active cards to the browser.
+          </p>
+          <pre class="example js" title="Specifying capabilities">
+          await navigator.serviceWorker.register('/pw/app.js');
+          const registration = await navigator.serviceWorker.ready;
+          registration.paymentManager.userHint = '(Visa ****1111)';
+          await registration.paymentManager.instruments.set(
+            '12345',
+            {
+              name: "Visa ****1111",
+              icons: [{
+                src: '/pay/visa.png',
+                sizes: '32x32',
+                type: 'image/png',
+              }],
+              enabledMethods: ['basic-card'],
+              capabilities: {
+                supportedNetworks: ['visa'],
+                supportedTypes: ['credit'],
+              },
+            });
+          </pre>
+          <p>
+            In this case, <code>new PaymentRequest([{supportedMethods:
+            'basic-card'}], shoppingCart).canMakePayment()</code> should return
+            <code>true</code> because there's an active card in the payment
+            handler. Note that <code>new PaymentRequest([{supportedMethods:
+            'basic-card', data: {supportedTypes: ['debit']}}],
+            shoppingCart).canMakePayment()</code> would return
+            <code>false</code> because of mismatch in
+            <code>supportedTypes</code> in this example.
+          </p>
+        </section>
+      </section>
     </section>
     <section id="invocation">
       <h2>