- From: Marcos Cáceres <notifications@github.com>
- Date: Sun, 02 Apr 2017 19:15:20 -0700
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/browser-payment-api/pull/492/review/30423737@github.com>
marcoscaceres commented on this pull request.
> @@ -665,17 +679,22 @@
<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>Determine which <a>payment apps</a> support any of the
- <a>payment method identifiers</a> given by the first element of
- the <var>paymentMethod</var> tuple. For each resulting payment
- app, if payment method specific capabilities supplied by the
- payment app match those provided by the second element of the
- tuple, the payment app matches.
- </li>
- </ol>
+ <li><p><a>Extension point</a>: process any proprietary and/or other
+ supported algorithms, for determining the available methods of paying,
+ at this point in the algorithm.</p>
+ <p>Alternatively, the following generic algorithm may be applied:</p>
Consider also that the extension point might require particular inputs and might have outputs (probably exceptions, as above). I've not given a lot of thoughts to what those are. That extension interface is basically what we would want to standardize here.
A place to start for the above is to look at which spec needs this right now. Which spec is going to use this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/492#discussion_r109329637
Received on Monday, 3 April 2017 02:16:20 UTC