Skip to content

Commit 461dbab

Browse files
marcoscaceresmarcoscaceres
authored
editorial: better payment handler integration (w3c#700)
1 parent 89b0e91 commit 461dbab

File tree

1 file changed

+62
-20
lines changed

1 file changed

+62
-20
lines changed

‎index.html

Lines changed: 62 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -165,11 +165,34 @@ <h2>
165165
</ul>
166166
<p>
167167
The details of how to fulfill a payment request for a given <a>payment
168-
method</a> are handled by <dfn data-lt="payment handler">payment
169-
handlers</dfn>. In this specification, these details are left up to the
170-
<a>user agent</a>, but future specifications may expand on the
171-
processing model in more detail.
168+
method</a> is an implementation detail of a <dfn data-lt=
169+
"payment handlers">payment handler</dfn>. Concretely, each payment
170+
handler defines:
172171
</p>
172+
<dl>
173+
<dt>
174+
A <dfn>can make payment</dfn> algorithm:
175+
</dt>
176+
<dd>
177+
How a payment handler determines whether it, or the user, can
178+
potentially "make a payment" is also an implementation detail of a
179+
payment handler. For an example, see the <a data-cite=
180+
"payment-method-basic-card#can-makepayment">can make payment</a>
181+
algorithm of [[payment-method-basic-card]].
182+
</dd>
183+
<dt>
184+
<dfn>Steps to respond to a payment request</dfn>:
185+
</dt>
186+
<dd>
187+
An algorithm that returns an object or <a data-cite=
188+
"!WEBIDL#idl-dictionary">dictionary</a> that a merchant uses to
189+
process or validate the transaction. The structure of this object is
190+
specific to each <a>payment method</a>. For an example of such an
191+
object, see the <code><a data-cite=
192+
"payment-method-basic-card#dom-basiccardresponse">BasicCardResponse</a></code>
193+
dictionary of [[payment-method-basic-card]].
194+
</dd>
195+
</dl>
173196
<p>
174197
This API also enables web sites to take advantage of more secure
175198
payment schemes (e.g., tokenization and system-level authentication)
@@ -910,7 +933,7 @@ <h2>
910933
<li>Return <var>acceptPromise</var> and perform the remaining steps
911934
<a>in parallel</a>.
912935
</li>
913-
<li>Let <var>handlers</var> be an empty unordered set.
936+
<li>Let <var>handlers</var> be an empty <a>list</a>.
914937
</li>
915938
<li>For each <var>paymentMethod</var> tuple in
916939
<var>request</var>.<a>[[\serializedMethodData]]</a>:
@@ -933,11 +956,20 @@ <h2>
933956
<var>acceptPromise</var> with that error and terminate this
934957
algorithm.
935958
</li>
936-
<li>If the user agent has a registered <a>payment handler</a>
937-
that supports <var>identifier</var>, then check if the payment
938-
handler is authorized and capable of handling the payment request
939-
with <var>data</var>. If the check returns in the affirmative,
940-
then add payment handler to <var>handlers</var>.
959+
<li>Let <var>registeredHandlers</var> be a <a>list</a> of
960+
registered payment handlers for the payment method
961+
<var>identifier</var>.
962+
</li>
963+
<li>For each <var>handler</var> in <var>registeredHandlers</var>:
964+
<ol>
965+
<li>Let <var>canMakePayment</var> be the result of running
966+
<var>handler</var>'s <a>can make payment</a> algorithm with
967+
<var>data</var>.
968+
</li>
969+
<li>If <var>canMakePayment</var> is true, then append
970+
<var>handler</var> to <var>handlers</var>.
971+
</li>
972+
</ol>
941973
</li>
942974
</ol>
943975
</li>
@@ -1148,12 +1180,20 @@ <h2>
11481180
<li>If conversion results in an error, reject <var>promise</var>
11491181
with that error and terminate this algorithm.
11501182
</li>
1151-
<li>If the user agent has a registered <a>payment handler</a>
1152-
that supports <var>identifier</var>, then check if the payment
1153-
handler is authorized and capable of handling the payment request
1154-
with <var>data</var>. If the check returns in the affirmative,
1155-
then resolve <var>promise</var> with true, and abort this
1156-
algorithm.
1183+
<li>Let <var>handlers</var> be a <a>list</a> of registered
1184+
<a>payment handlers</a> that are authorized and can handle
1185+
payment request for <var>identifier</var>.
1186+
</li>
1187+
<li>For each <var>handler</var> in <var>handlers</var>:
1188+
<ol>
1189+
<li>Let <var>canMakePayment</var> be the result of running
1190+
<var>handler</var>'s <a>can make payment</a> algorithm with
1191+
<var>data</var>.
1192+
</li>
1193+
<li>If <var>canMakePayment</var> is true, resolve
1194+
<var>promise</var> with true, and return.
1195+
</li>
1196+
</ol>
11571197
</li>
11581198
</ol>
11591199
</li>
@@ -3401,11 +3441,13 @@ <h2>
34013441
identifier</a> for the <a>payment method</a> that the user selected
34023442
to accept the payment.
34033443
</li>
3444+
<li>Let <var>handler</var> be the <a>payment handler</a> selected by
3445+
the user.
3446+
</li>
34043447
<li>Set the <a data-lt="PaymentResponse.details">details</a>
3405-
attribute value of <var>response</var> to an object containing the
3406-
<a>payment method</a> specific object that will be used by the
3407-
merchant to process or validate the transaction. The format of this
3408-
response will be defined for each <a>payment method</a>.
3448+
attribute value of <var>response</var> to an object resulting from
3449+
running the <var>handler</var>'s <a>steps to respond to a payment
3450+
request</a>.
34093451
</li>
34103452
<li>If the <a data-lt=
34113453
"PaymentOptions.requestShipping">requestShipping</a> value of

0 commit comments

Comments
 (0)