Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316)

mkruisselbrink commented on this pull request.



> @@ -523,6 +524,60 @@
           </li>
         </ol>
       </section>
+      <section>  
+        <h2>
+          <code>canMakeActivePayment()</code> method
+        </h2>
+        <p>
+          The <dfn>canMakeActivePayment</dfn> method is called when the page wants to know if the user has a payment method available to use for payment before calling <a data-lt="PaymentRequest.show">show</a>. The <a>canMakeActivePayment</a> method returns a <a>Promise</a> that will be resolved when the <a>user agent</a> has determined if at least one method is available from <a>supportedMethods</a> data. In order to prevent the page from probing different payment methods supported by user, <a>canMakeActivePayment</a> can only be called once per top-level domain. Multiple calls to <a>canMakeActivePayment</a> will result in cached response from previous call. To reduce privacy risks, user agents MAY limit calls to <a>canMakeActivePayment</a> for a certain time before invalidating the cached response per top-level domain. Developers can call <a>canMakeActivePayment</a> multiple times with same set of <a>supportedMethods</a> per top-level domain.  
+        </p>
+        <p>
+          The <a>canMakeActivePayment</a> method MUST act as follows:
+        </p>
+        <ol>
+          <li>
+            Let <var>request</var> be the <a>PaymentRequest</a> object on which the method is called.
+          </li>
+          <li>If the value of <var>request</var>@[[\state]] is not "created", then

To be fair WebIDL takes care of converting any exceptions that are thrown in the steps describing a method returning a promise into a rejected promise. But of course still clearer to not rely and that part of WebIDL and just explicitly return a rejected promise.

-- 
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/browser-payment-api/pull/316

Received on Thursday, 17 November 2016 17:48:43 UTC