- 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