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

Jump to bottom

Add CanMakePaymentEvent. #170

Merged
merged 6 commits into from Mar 28, 2018
Merged

Add CanMakePaymentEvent. #170

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
8b6561f
Add CanMakePaymentEvent.
rsolomakhin Jun 6, 2017
950cd55
Merge remote-tracking branch 'upstream/gh-pages' into gh-pages
rsolomakhin Mar 12, 2018
0b6badd
Mention supported-origins-star, add an issue pointer for filtering, a…
rsolomakhin Mar 12, 2018
b5387a6
Fix merge.
rsolomakhin Mar 12, 2018
a8a27a6
Restore the section on filtering of payment instruments and the issue…
rsolomakhin Mar 13, 2018
65e5ec4
Add a link to the wiki page.
rsolomakhin Mar 26, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
188 changes: 0 additions & 188 deletions index.html
View file
Open in desktop
Expand Up @@ -852,194 +852,6 @@ <h2>
</section>
</section>
</section>
<section id="instrument-display-ordering">
<h2>
Origin and Instrument Display for Selection
</h2>
<p>
After applying the matching algorithm defined in Payment Request API,
the user agent displays a list of instruments from matching payment
apps for the user to make a selection. This specification includes a
limited number of display requirements; most user experience details
are left to implementers.
</p>
<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>
<h2>
Ordering of Payment Handlers
</h2>
<ul>
<li>The user agent <span class='rfc2119'>MUST</span> favor user-side
order preferences (based on user configuration or behavior) over
payee-side order preferences.
</li>
<li>The user agent <span class='rfc2119'>MUST</span> display matching
payment handlers in an order that corresponds to the order of
supported payment methods provided by the payee, except where
overridden by user-side order preferences.
</li>
<li>The user agent <span class='rfc2119'>SHOULD</span> allow the user
to configure the display of matching payment handlers to control the
ordering and define preselected defaults.
</li>
</ul>
<p class="issue" title=
"PR API payment method ordering and relation to this spec."
data-number="116">
The second bullet above may be amended to remove explicit mention of
ordering defined by the payee.
</p>
<p>
The following are examples of payment handler ordering:
</p>
<ul>
<li>For a given Web site, display payment handlers in an order that
reflects usage patterns for the site (e.g., a frequently used payment
handler at the top, or the most recently used payment handler at the
top).
</li>
<li>Enable the user to set a preferred order for a given site or for
all sites.
</li>
<li>If the origin of the site being visited by the user matches the
origin of a payment handler, show the payment handler at the top of
the list.
</li>
</ul>
<p class="issue" title="Merchant Preferences" data-number="74">
The Working Group has discussed two types of merchant preferences
related to payment apps: (1) highlighting merchant-preferred payment
apps already registered by the user and (2) recommending payment apps
not yet registered by the user. The current draft of the
specification does not address either point, and the Working Group is
seeking feedback on the importance of these use cases. Note that for
the second capability, merchants can recommend payment apps through
other mechanisms such as links from their web sites.
</p>
</section>
<section>
<h2>
Display of Instruments
</h2>
<p>
The user agent <span class='rfc2119'>MUST</span> enable the user to
select any displayed instrument.
</p>
<ul>
<li>At a minimum, we expect user agents to display an icon and label
for each matching origin to help the user make a selection.
</li>
<li>In some contexts (e.g., a desktop browser) it may be possible to
improve the user experience by offering additional detail to the
user. For example, if the user's "bank.com" origin knows about two
credit cards (thus, two potential responses to the same payment
method "basic-card"), the user agent could display each credit card's
brand and the last four digits of the card to remind the user which
cards the origin knows about.
</li>
</ul>
<p class="issue" title="Display" data-number="173">
The Working Group is discussing how default payment instrument
display could further streamline the user experience.
</p>
</section>
<section>
<h2>
Selection of Instruments
</h2>
<p>
Users agents may wish to enable the user to select individual
displayed Instruments. The payment handler would receive information
about the selected Instrument and could take action, potentially
eliminating an extra click (first open the payment app then select
the Instrument).
</p>
</section>
</section>
<section id="canmakepayment">
<h2>
Can make payment
Expand Down