Skip to content

Commit 974d879

Browse files
marcoscaceresmarcoscaceres
authored
Support requesting billing address (#749)
1 parent 614fa2a commit 974d879

File tree

1 file changed

+55
-14
lines changed

1 file changed

+55
-14
lines changed

‎index.html‎

Lines changed: 55 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1051,8 +1051,8 @@ <h2>
10511051
If <var>detailsPromise</var> was passed, then:
10521052
<ol>
10531053
<li>Run the <a>update a <code>PaymentRequest</code>'s details
1054-
algorithm</a> with <var>detailsPromise</var> and
1055-
<var>request</var>.
1054+
algorithm</a> with <var>detailsPromise</var>, <var>request</var>,
1055+
and null.
10561056
</li>
10571057
<li>Wait for the <var>detailsPromise</var> to settle.
10581058
<p class="note">
@@ -1972,6 +1972,7 @@ <h2>
19721972
<pre class="idl">
19731973
dictionary PaymentOptions {
19741974
boolean requestPayerName = false;
1975+
boolean requestBillingAddress = false;
19751976
boolean requestPayerEmail = false;
19761977
boolean requestPayerPhone = false;
19771978
boolean requestShipping = false;
@@ -1984,6 +1985,19 @@ <h2>
19841985
options desired for the payment request.
19851986
</p>
19861987
<dl>
1988+
<dt>
1989+
<dfn>requestBillingAddress</dfn> member
1990+
</dt>
1991+
<dd data-link-for="PaymentMethodChangeEvent">
1992+
A boolean that instructs the <a>user agent</a> to get the billing
1993+
address associated with a <a>payment method</a> (e.g., the billing
1994+
address associated with a credit card). Typically, the user agent
1995+
will return the billing address as part of the
1996+
<a>PaymentMethodChangeEvent</a>'s <a>methodDetails</a>, albeit
1997+
possibly with parts of the address redacted for privacy reasons. A
1998+
merchant can use this information to, for example, calculate tax in
1999+
certain jurisdictions.
2000+
</dd>
19872001
<dt>
19882002
<dfn>requestPayerName</dfn> member
19892003
</dt>
@@ -4034,9 +4048,16 @@ <h2>
40344048
</li>
40354049
<li>Set <var>event</var>.<a>[[\waitForUpdate]]</a> to true.
40364050
</li>
4051+
<li>Let <var>pmi</var> be null.
4052+
</li>
4053+
<li>If <var>event</var> has a <a data-link-for=
4054+
"PaymentMethodChangeEvent">methodName</a> attribute, set
4055+
<var>pmi</var> to the <a data-link-for="PaymentMethodChangeEvent">
4056+
methodName</a> attribute's value.
4057+
</li>
40374058
<li>Run the <a>update a <code>PaymentRequest</code>'s details
4038-
algorithm</a> with <var>detailsPromise</var> and
4039-
<var>request</var>.
4059+
algorithm</a> with <var>detailsPromise</var>, <var>request</var>,
4060+
and <var>pmi</var>.
40404061
</li>
40414062
</ol>
40424063
</section>
@@ -4589,16 +4610,18 @@ <h2>
45894610
<p>
45904611
The <dfn>update a <code>PaymentRequest</code>'s details
45914612
algorithm</dfn> takes a <a>PaymentDetailsUpdate</a>
4592-
<var>detailsPromise</var> and a <a>PaymentRequest</a>
4593-
<var>request</var>. The steps are conditional on the
4594-
<var>detailsPromise</var> settling. If <var>detailsPromise</var>
4595-
never settles then the payment request is blocked. The user agent
4596-
SHOULD provide the user with a means to abort a payment request.
4597-
Implementations MAY choose to implement a timeout for pending updates
4598-
if <var>detailsPromise</var> doesn't settle in a reasonable amount of
4599-
time. If an implementation chooses to implement a timeout, they MUST
4600-
execute the steps listed below in the "upon rejection" path. Such a
4601-
timeout is a fatal error for the payment request.
4613+
<var>detailsPromise</var>, a <a>PaymentRequest</a>
4614+
<var>request</var>, and <var>pmi</var> that is either a DOMString or
4615+
null (a <a>payment method identifier</a>). The steps are conditional
4616+
on the <var>detailsPromise</var> settling. If
4617+
<var>detailsPromise</var> never settles then the payment request is
4618+
blocked. The user agent SHOULD provide the user with a means to abort
4619+
a payment request. Implementations MAY choose to implement a timeout
4620+
for pending updates if <var>detailsPromise</var> doesn't settle in a
4621+
reasonable amount of time. If an implementation chooses to implement
4622+
a timeout, they MUST execute the steps listed below in the "upon
4623+
rejection" path. Such a timeout is a fatal error for the payment
4624+
request.
46024625
</p>
46034626
<ol class="algorithm">
46044627
<li>Set <var>request</var>.<a>[[\updating]]</a> to true.
@@ -4780,6 +4803,24 @@ <h2>
47804803
</li>
47814804
</ol>
47824805
</li>
4806+
<li data-link-for="PaymentDetailsUpdate">If the
4807+
<a>paymentMethodErrors</a> member is present and
4808+
<var>identifier</var> is not null:
4809+
<ol>
4810+
<li>If required by the specification that defines the
4811+
<var>pmi</var>, then <a data-cite=
4812+
"!WEBIDL#dfn-convert-ecmascript-to-idl-value">convert</a> <a>
4813+
paymentMethodErrors</a> to an IDL value.
4814+
</li>
4815+
<li>If conversion results in a <a data-cite=
4816+
"!WEBIDL#dfn-exception">exception</a> <var>error</var>,
4817+
<a>abort the update</a> with <var>error</var>.
4818+
</li>
4819+
<li>The <a>payment handler</a> SHOULD display an error for
4820+
each relevant erroneous field of <a>paymentMethodErrors</a>.
4821+
</li>
4822+
</ol>
4823+
</li>
47834824
<li>Update the <a>PaymentRequest</a> using the new details:
47844825
<ol>
47854826
<li data-link-for="PaymentDetailsUpdate">If the <a>total</a>

0 commit comments

Comments
 (0)