Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detecting Payment Method Availability #316

Closed
wants to merge 9 commits into from
Closed

Detecting Payment Method Availability #316

Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
fb3c64d
Merge pull request #1 from w3c/gh-pages
maheshkk Sep 20, 2016
1b1c647
Merge pull request #2 from w3c/gh-pages
maheshkk Nov 16, 2016
3e40771
Adding canMakeActivePayment()
maheshkk Nov 17, 2016
645d85b
Fix markup and various things
Nov 17, 2016
e2ef999
Fix: re-dfn user agent
Nov 17, 2016
c5c90ea
fix: typo
Nov 17, 2016
fa2b67e
Fix typo
Nov 17, 2016
e0adb39
Fix: s/Boolean/boolean
Nov 18, 2016
b87613d
Update index.html
maheshkk Dec 1, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 79 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -174,6 +174,7 @@ <h2>
interface PaymentRequest : EventTarget {
Promise&lt;PaymentResponse&gt; show();
Promise&lt;void&gt; abort();
Promise&lt;boolean&gt; canMakePayment();

readonly attribute PaymentAddress? shippingAddress;
readonly attribute DOMString? shippingOption;
Expand Down Expand Up @@ -523,6 +524,84 @@ <h2>
</li>
</ol>
</section>
<section>
<h2>
<code>canMakePayment()</code> method
</h2>
<p>
The <dfn>canMakePayment</dfn> method can be called by the page to know
if user has a payment method available for payment before calling
<a data-lt="PaymentRequest.show">show</a>. The <a>canMakePayment</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>canMakePayment</a>
can only be called once per top-level domain. Multiple calls to <a>canMakePayment</a> will result in
rejection of the promise with QuotaExceededError. To reduce privacy risks, implementations MAY limit calls
to <a>canMakePayment</a> for a certain period of time before allowing top-level origin to call
<a>canMakePayment</a> again. However <a>canMakePayment</a> can be called multiple times with same
set of <a data-lt="PaymentMethodData.supportedMethods">supportedMethods</a> per top-level origin.
</p>
<p>
The <a>canMakePayment</a> method MUST act as follows:
</p>
<ol>
<li>
Let <var>this</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
reject <em>promise</em> with <a>InvalidStateError</a>.
</li>
<li>
Set the value of <em>request</em>@[[\state]] to "interactive".
</li>
<li>
Let <var>canMakePaymentPromise</var> be a new <a>Promise</a>.
</li>
<li>
Store <var>canMakePaymentPromise</var> in <em>request</em>@[[\canMakePaymentPromise]].
</li>
<li>
Return <var>canMakePaymentPromise</var> and asynchronously perform the remaining steps.
</li>
<li>
Let <var>topLevelOrigin</var> be the URL of the top level page.
Let <var>cachedSupportedMethods</var> be <a>supportedMethods</a> sequences from each <a>PaymentMethodData</a> from previous call to <a>PaymentRequest</a>.
Let <var>cachedResponse</var> be response from previous call to <a>canMakePayment</a>.
Let <var>canMakePaymentQuotaReached</var> be boolean value of previous call to <a>canMakePayment</a> for the <a>topLevelOrigin</a>.
</li>
<li>
Let <var>supportedMethods</var> be the union of all the <a>supportedMethods</a> sequences from each
<a>PaymentMethodData</a> in the <var>request</var>@[[\methodData]] sequence.
</li>
<li>
If <var>cachedSupportedMethods</var> is preset and matches <a>supportMethods</a>,
then resolve <var>canMakePaymentPromise</var> with <a>cachedResponse</a>. Else,
set <var>cachedSupportedMethods</var> to <var>supportedMethods</var>.
</li>
<li>
If <a>canMakePaymentQuotaReached</a> is set, then reject the <var>canMakePaymentPromise</var>
with QuotaExceededError.
</li>
<li>
Let <var>acceptedMethods</var> be <var>supportedMethods</var> with all identifiers removed that the
<a>user agent</a> does not support.
</li>
<li>
If the length of <var>acceptedMethods</var> is zero, then resolve <var>canMakePaymentPromise</var> with
<code>false</code>, otherwise resolve <var>acceptPromise</var> with <code>true</code>.
</li>
<li>
Cache the response in <var>cachedResponse</var> and set <var>canMakePaymentQuotaReached</var> to
to true.
</li>
<li>
In addition, implementations may choose to implement a timeout to reset
<var>canMakePaymentQuotaReached</var> for the <var>topLevelOrigin</var>.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't really work without a quota reset at some point. I think what we need to specify here is that implementations {should or must} reset the quota after a timeout, with the timeout selected by the implementation.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two points where quota reserts, .

  1. Quota resets after the session ends (window closed/navigate away from the page)
  2. Optional : reset after certain timeout.

I believe your concern is to remove the optional part from second option. Say if some implementors choose to set timeout to zero then it has same effect as keeping the check optional at the moment. Then I wonder why enforce the step with "Must" or "should"?

</li>
</ol>
</section>
<section>
<h2 id="state-transitions" class="informative">
State transitions
Expand Down