8000 Add PaymentRequest.prototype.hasEnrolledInstrument() by danyao · Pull Request #833 · w3c/payment-request · GitHub
[go: up one dir, main page]
Skip to content

Add PaymentRequest.prototype.hasEnrolledInstrument() #833

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

Merged
marcoscaceres merged 28 commits into from
May 3, 2019
Merged

Add PaymentRequest.prototype.hasEnrolledInstrument() #833

Changes from 11 commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
2f6bb15
Add hasEnrolledInstrument()
danyao Feb 8, 2019
78b9bb6
Add hasEnrolledInstrument() to PaymentRequest API
danyao Feb 8, 2019
bf13afe
Incorporate reviewer feedback.
ianbjacobs Feb 8, 2019
b926976
Incorporate reviewer feedback.
ianbjacobs Feb 8, 2019
ded4b4a
Incorporate reviewer feedback.
ianbjacobs Feb 8, 2019
b664b3c
Incorporate reviewer feedback.
marcoscaceres Feb 11, 2019
c408c42
Incorporate reviewer feedback.
marcoscaceres Feb 11, 2019
d38c6df
Incorporate reviewer feedback.
marcoscaceres Feb 11, 2019
a2cc4b9
reword canMakePayment note
danyao Feb 11, 2019
1f95549
Dedup canMakePayment() and hasEnrolledInstrument() algorithms
danyao Feb 11, 2019
6815ed5
Remove canMakePayment() language from Privacy Considerations because …
danyao Feb 11, 2019
7252b56
Update index.html
marcoscaceres Feb 15, 2019
c885809
Update index.html
marcoscaceres Feb 15, 2019
0f8b74c
Update index.html
marcoscaceres Feb 15, 2019
c9822c7
Update index.html
marcoscaceres Feb 15, 2019
f3f5120
Update index.html
marcoscaceres Feb 15, 2019
38174d1
Add privacy note for canMakePayment
danyao Feb 15, 2019
5d8147c
Fix early exit bug in can make payment algorithm
danyao Feb 15, 2019
7dc08ec
Update index.html
marcoscaceres Feb 15, 2019
8ad4554
Update index.html
marcoscaceres Feb 15, 2019
61260d3
Simply language per review feedback
danyao Feb 15, 2019
ca25168
Merge branch 'hasEnrolledInstrument' of https://github.com/danyao/pay…
danyao Feb 15, 2019
644ed0c
Nit: autogenerate link to section.
marcoscaceres Feb 18, 2019
25ef9c0
Update index.html
aestes Mar 4, 2019
83818dd
Merge branch 'gh-pages' into hasEnrolledInstrument
marcoscaceres Mar 22, 2019
9db2c7d
Merge with upstream/gh-pages
danyao May 2, 2019
7e28ff4
git pull origin hasEnrolledInstrument
danyao May 2, 2019
6faac81
Fix broken link
danyao May 2, 2019
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
199 changes: 136 additions & 63 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -566,6 +566,8 @@ <h2>
Promise&lt;void&gt; abort();
[NewObject]
Promise&lt;boolean&gt; canMakePayment();
[NewObject]
Promise&lt;boolean&gt; hasEnrolledInstrument();

readonly attribute DOMString id;
readonly attribute PaymentAddress? shippingAddress;
Expand Down Expand Up @@ -1300,65 +1302,43 @@ <h2>
<h2>
<dfn>canMakePayment()</dfn> method
</h2>
<div class="note" title="canMakePayment() vs hasEnrolledInstrument()">
<p>
The <a>canMakePayment()</a> method returns a <a>Promise</a>
that is fulfilled with true if the <a>user agent</a> supports
any of the <a data-link-for="PaymentMethodData">supportedMethods</a>
supplied to the <a>PaymentRequest</a>
<a data-lt="PaymentRequest.PaymentRequest()">constructor</a>, or
false if none are supported.
</p>
<p>
A true result from <a>canMakePayment()</a> does not imply that the
user has an provisioned instrument ready for payment. For that, use
<a>hasEnrolledInstrument()</a> instead.
</p>
</div>
<p data-tests="payment-request-canmakepayment-method.https.html">
The <a>canMakePayment()</a> method MUST run the <a>can make payment
algorithm</a> with <var>checkForInstruments</var> set to false.
</p>
</section>
<section data-dfn-for="PaymentRequest" data-link-for="PaymentRequest">
<h2>
<dfn>hasEnrolledInstrument()</dfn> method
</h2>
<p class="note">
The <a>canMakePayment()</a> method can be used by the developer to
determine if the <a>PaymentRequest</a> object can be used to make a
payment, before they call <a>show()</a>. It returns a <a>Promise</a>
that will be fulfilled with true if the <a>user agent</a> supports
any of the desired <a>payment methods</a> supplied to the
<a>PaymentRequest</a> constructor, and false if none are supported.
If the method is called too often, the user agent might instead
return <a>a promise rejected with</a> a "<a>NotAllowedError</a>"
<a>DOMException</a>, at its discretion.
The <a>hasEnrolledInstrument()</a> method can be used by the developer
to determine if the <a>user agent</a> not only has support for one of
the desired <a>payment methods</a> but is also "ready for payment" (
e.g., when showing a "buy now" button). If the method is called too
often, the user agent may return <a>a promise rejected
with </a> a "<a>NotAllowedError</a>" <a>DOMException</a> at its
discretion.
</p>
<p data-tests="payment-request-canmakepayment-method.https.html">
The <a>canMakePayment()</a> method MUST act as follows:
<p data-tests="payment-request-hasenrolledinstrument-method.https.html">
The <a>hasEnrolledInstrument()</a> method MUST run the <a>can make
payment algorithm</a> with <var>checkForInstruments</var> set to true.
</p>
<ol class="algorithm">
<li>Let <var>request</var> be the <a>PaymentRequest</a> object on
which the method was called.
</li>
<li>If <var>request</var>.<a>[[\state]]</a> is not "<a>created</a>",
then return <a>a promise rejected with</a> an
"<a>InvalidStateError</a>" <a>DOMException</a>.
</li>
<li data-tests=
"payment-request/payment-request-canmakepayment-method-protection.https.html">
Optionally, at the <a>top-level browsing context</a>'s discretion,
return <a>a promise rejected with</a> a "<a>NotAllowedError</a>" <a>
DOMException</a>.
<p class="note" data-link-for="PaymentRequest">
This allows user agents to apply heuristics to detect and prevent
abuse of the <a>canMakePayment()</a> method for fingerprinting
purposes, such as creating <a>PaymentRequest</a> objects with a
variety of supported <a>payment methods</a> and calling
<a>canMakePayment()</a> on them one after the other. For example,
a user agent may restrict the number of successful calls that can
be made based on the <a>top-level browsing context</a> or the
time period in which those calls were made.
</p>
</li>
<li>Let <var>hasHandlerPromise</var> be <a>a new promise</a>.
</li>
<li>Return <var>hasHandlerPromise</var>, and perform the remaining
steps <a>in parallel</a>.
</li>
<li>For each <var>paymentMethod</var> tuple in
<var>request</var>.<a>[[\serializedMethodData]]</a>:
<ol>
<li>Let <var>identifier</var> be the first element in the
<var>paymentMethod</var> tuple.
</li>
<li>If there user agent has a <a>payment handler</a> that support
handling payment requests for <var>identifier</var>, resolve
<var>hasHandlerPromise</var> with true and terminate this
algorithm.
</li>
</ol>
</li>
<li>Resolve <var>hasHandlerPromise</var> with false.
</li>
</ol>
</section>
<section data-dfn-for="PaymentRequest" data-link-for="PaymentRequest">
<h2>
Expand Down Expand Up @@ -4259,6 +4239,99 @@ <h2>
</li>
</ol>
</section>
<section>
<h2>
Can make payment algorithm
</h2>
<p>
The <dfn>can make payment algorithm</dfn> checks if the <a>user
agent</a> supports making payment with a <a>PaymentRequest</a>. It
takes a boolean argument, <var>checkForInstruments</var>, that
specifies whether the algorithm should check for existence of enrolled
instruments in addition to basic support of a <a>payment method</a>.
</p>
<ol class="algorithm">
<li>Let <var>request</var> be the <a>PaymentRequest</a> object on
which the method was called.
</li>
<li>If <var>request</var>.<a>[[\state]]</a> is not "<a>created</a>",
then return <a>a promise rejected with</a> an
"<a>InvalidStateError</a>" <a>DOMException</a>.
</li>
<li data-tests=
"payment-request/payment-request-hasenrolledinstrument-method-protection.https.html">
If <var>checkForInstruments</var> is true, optionally, at the
<a>top-level browsing context</a>'s discretion, return <a>a promise
rejected with</a> a "<a>NotAllowedError</a>" <a> DOMException</a>.
<p class="note" data-link-for="PaymentRequest">
This allows user agents to apply heuristics to detect and prevent
abuse of the <a>hasEnrolledInstrument()</a> method for
fingerprinting purposes, such as creating <a>PaymentRequest</a>
objects with a variety of supported <a>payment methods</a> and
calling <a>hasEnrolledInstrument()</a> on them one after the
other. For example, a user agent may restrict the number of
successful calls that can be made based on the <a>top-level
browsing context</a> or the time period in which those calls were
made.
</p>
</li>
<li>Let <var>promise</var> be <a>a new promise</a>.
</li>
<li>Return <var>promise</var>, and perform the remaining
steps <a>in parallel</a>.
</li>
<li>For each <var>paymentMethod</var> tuple in
<var>request</var>.<a>[[\serializedMethodData]]</a>:
<ol>
<li>Let <var>identifier</var> be the first element in the
<var>paymentMethod</var> tuple.
</li>
<li>If <var>checkForInstruments</var> is false, resolve <var>
promise</var> with true and terminate this algorithm if either the
user agent has a <a>payment handler</a> that supports handling
payment requests for <var>identifier</var>, or if it can perform
just-in-time installation of a suitable payment handler.
</li>
<li>If <var>checkForInstruments</var> is true:
<ol>
<li>Let <var>data</var> be the result of <a data-cite=
"ECMASCRIPT#sec-json.parse">JSON-parsing</a> the second element
in the <var>paymentMethod</var> tuple.
</li>
<li>If required by the specification that defines the
<var>identifier</var>, then <a data-cite=
"WEBIDL#dfn-convert-ecmascript-to-idl-value">convert</a>
<var>data</var> to an IDL value. Otherwise, <a data-cite=
"WEBIDL#dfn-convert-ecmascript-to-idl-value">convert</a> to
<a data-cite="WEBIDL#idl-object">object</a>.
</li>
<li>If conversion results in an <a data-cite=
"WEBIDL#dfn-exception">exception</a> <var>error</var>, reject
<var>promise</var> with <var>error</var> and terminate this
algorithm.
</li>
<li>Let <var>handlers</var> be a <a>list</a> of registered
<a>payment handlers</a> that are authorized and can handle
payment request for <var>identifier</var>.
</li>
<li>For each <var>handler</var> in <var>handlers</var>:
<ol>
<li>Let <var>hasEnrolledInstrument</var> be the result of
running <var>handler</var>'s <a>steps to check if a payment
can be made</a> with <var>data</var>.
</li>
<li>If <var>hasEnrolledInstrument</var> is true, resolve
<var>promise</var> with true and terminate this algorithm.
</li>
</ol>
</li>
</ol>
</ol>
</li>
<li>Resolve <var>promise</var> with false.
</li>
</ol>
</section>
<section>
<h2>
Shipping address changed algorithm
Expand Down Expand Up @@ -5260,15 +5333,15 @@ <h2>
</section>
<section>
<h2>
canMakePayment() protections
hasEnrolledInstrument() protections
</h2>
<p data-link-for="PaymentRequest">
The <a>canMakePayment()</a> method enables the payee to call
<a>show()</a> if the user is ready to take advantage of the API, or
to fall back to a legacy checkout experience if not. Because this
method shares some information with the payee, user agents are
expected to protect the user from abuse of the method, for example,
by restricting the number or frequency of calls.
The <a>hasEnrolledInstrument()</a> method enables the payee to check
if the user is ready to take advantage of the API before calling
<a>show()</a> so that it can fall back to a legacy checkout experience
if not. Because this method shares some information with the payee,
user agents are expected to protect the user from abuse of the method,
for example, by restricting the number or frequency of calls.
</p>
</section>
</section>
Expand Down
0