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

Define payment option filtering algorithm. #420

Closed
wants to merge 1 commit into from
Closed

Define payment option filtering algorithm. #420

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
75 changes: 55 additions & 20 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -628,30 +628,21 @@ <h2>
<li>Return <var>acceptPromise</var> and perform the remaining steps
<a>in parallel</a>.
</li>
<li>For each <var>paymentMethod</var> in
<var>request</var>.<a>[[\serializedMethodData]]</a>:
<ol>
<li>Consult the appropriate <a>payment apps</a> to see if they
support any of the <a>payment method identifiers</a> given by the
first element of the <var>paymentMethod</var> tuple, passing
along the data string given by the second element of the tuple in
order to help them determine their support.
</li>
</ol>
</li>
<li>If this consultation produced no supported method of paying, then
reject <var>acceptPromise</var> with a "<a>NotSupportedError</a>" <a>
DOMException</a>, and abort this algorithm.
<li>Let <var>matchingOptions</var> be the result of running the
Copy link
Contributor

Choose a reason for hiding this comment

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

You're removing the part of the current document that deals with paymentMethod matching. The algorithm I thumbnailed in issue 96 was intended to supplement paymentMethod matching rather than replace it. Basically, you need to put the filter payments options algorithm into a loop that evaluates it once for each paymentMethod in the request, and only those options that match the paymentMethod should be evaluated on each iteration.

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's a little unclear to me what the result of this algorithm is, i.e. what a "matching option" is. The algorithm steps seem to only add option to the return value, and option is a payment app. So is matchingOptions a list of payment apps? But then the subsequent sentence

show a user interface to allow the user to interact with the payment request process, using those payment apps, matchingOptions, and payment methods which the above step identified as feasible

is confusing, since the above step only identified payment apps = matchingOptions, whereas this seems to be saying that there are three different lists determined by the above step: the payment apps, matchingOptions, and payment methods.

<a>filter payment options algorithm</a>.
</li>
<li>If <var>matchingOptions</var> is empty, then reject
<var>acceptPromise</var> with a "<a>NotSupportedError</a>" <a>
DOMException</a>, and abort this algorithm. </li>
<li>
<p>
Otherwise, show a user interface to allow the user to interact
with the payment request process, using those <a>payment apps</a>
and <a>payment methods</a> which the above step identified as
feasible. The user agent MAY show payment methods in the order
given by <var>supportedMethods</var>, but SHOULD prioritize the
preference of the user when presenting payment methods and
applications.
with the payment request process, using those <a>payment apps</a>,
<var>matchingOptions</var>, and <a>payment methods</a> which the
above step identified as feasible. The user agent MAY show payment
methods in the order given by <var>supportedMethods</var>, but
SHOULD prioritize the preference of the user when presenting
payment methods and applications.
</p>
<p>
The <a>payment app</a> should be sent the appropriate data from
Expand Down Expand Up @@ -2342,6 +2333,50 @@ <h2>
</li>
</ol>
</section>
<section>
<h2>
Filter payment options algorithm
</h2>
<p>
The <dfn data-lt="filter payment options">filter payment options
algorithm</dfn> runs when user agent presents the user with the
collection of payment options available for selection. It MUST run the
following steps:
</p>
<ol>
<li>Let <var>matchingOptions</var> be an empty list.</li>
<li>Let <var>request</var> be the <a>PaymentRequest</a> object that
the user is interacting with.
<li>For each <var>requestMethod</var> in
<var>request</var>.<a>[[\serializedMethodData]]</a>:
<ol type="I">
<li>Let <var>filters</var> be <var>requestMethod.data</var>
Copy link
Collaborator

Choose a reason for hiding this comment

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

This step doesn't make sense to me. requestMethod is a tuple containing supportedMethods, a sequence<DOMString>, and data, a string of serialized JSON. So requestMethod.data does not have any members.

members whose values are lists of strings.</li>
Copy link
Contributor

Choose a reason for hiding this comment

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

Hrm. I thought, after our last discussion on this point, we had reached agreement that this was problematic, in that it precluded payment methods from defining data parameters whose values were a list of strings, but which were not filters.

<li>For each <var>option</var> of the installed
<a>payment apps</a>:
<ol type="i">
<li>Let <var>optionMatch</var> be true.</li>
<li>For <var>filterName</var> in the keys of
<var>requestMethod</var>:
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this be in the keys of filters rather than keys of requestMethod?

<ol type="a">
<li>If <var>option.capabilities</var> does not have key
Copy link
Collaborator

Choose a reason for hiding this comment

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

Where is option.capabilities defined? I thought a payment app was an abstract concept, not an object which had properties.

<var>filterName</var>, set <var>optionMatch</var> to
false.</li>
<li>Otherwise, if the intersection of
<var>filters[filterName]</var> and
<var>option.capabilities[filterName]</var> is empty, set
<var>optionMatch</var> to false.</li>
</ol>
</li>
<li>If <var>optionMatch</var> is true, add <var>option</var>
to <var>matchingOptions</var>.</li>
</ol>
</li>
</ol>
</li>
<li>Return <var>matchingOptions</var>.</li>
</ol>
</section>
</section>
<section class='informative'>
<h2>
Expand Down