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.

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

Remove 'Origin and Instrument Display for Selection' sections #229

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
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
103 changes: 0 additions & 103 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -903,109 +903,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>
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="invocation">
<h2>
Invocation
Expand Down