Skip to content
This repository has been archived by the owner on Aug 27, 2021. It is now read-only.

User changes payment method #53

Merged
merged 9 commits into from
Sep 20, 2018
141 changes: 135 additions & 6 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -250,8 +250,8 @@ <h3>
<li>If <var>cards</var> <a data-cite="infra#list-is-empty">is
empty</a>, return false.
</li>
<li>Let <var>networks</var> be an empty <code><a data-cite=
"!WEBIDL#idl-DOMString">DOMString</a></code> sequence.
<li>Let <var>networks</var> be an empty <a data-cite=
"!WEBIDL#idl-DOMString"><code>DOMString</code></a> sequence.
</li>
<li>Let <var>types</var> be an empty <a>BasicCardType</a> sequence.
</li>
Expand Down Expand Up @@ -403,6 +403,112 @@ <h3>
</li>
</ol>
</section>
<section>
<h3>
Steps for when a user changes payment method
</h3>
<p class="note" data-lt="BasicCardRequest">
When the end user explicitly switches from one card to another, these
steps cause an event to fire in the <cite data-cite=
"!payment-request">Payment Request API</cite>. The algorithm
presupposes that the user agent is only presenting <a>supported
cards</a> to the end user, by having filtered out unsupported cards
based on the initiating payment request's <a>BasicCardRequest</a>'s
<a>supportedNetworks</a> and <a>supportedTypes</a> values.
</p>
<p>
The <dfn>steps for when a user changes payment method</dfn> are as
follows. The steps take <a>PaymentRequest</a> <var>request</var> as
input. To mitigate fingerprinting concerns, the user agent MUST NOT
run these steps unless the a user explicitly switches to a different
card by performing some user action (e.g., by selecting a different
card explicitly from a list of cards). For cards that are preselected
by default by the user agent, any matching <a data-cite=
"payment-request#dom-paymentdetailsmodifier"><code>PaymentDetailsModifier</code></a>s
apply instead (without the need to run these steps).
</p>
<ol>
<li>Let <var>methodDetails</var> be a newly created
<a>BasicCardChangeDetails</a> dictionary.
</li>
<li>From the <a>supported cards</a> presented to the end user, let
<var>card</var> be the <a>card</a> the user selected.
</li>
<li>Let <var>billingAddress</var> be null.
</li>
<li>If <var>request</var>.<a data-cite=
"payment-request#dfn-options">[[\options]]</a>["<a data-cite=
"payment-request#dom-paymentoptions-requestbillingaddress"><code>requestBillingAddress</code></a>"]
is true:
<ol>
<li>
<div class="note" title="Privacy of recipient information">
<p>
The <var>redactList</var> optionally gives user agents the
possibility to limit the amount of personal information
about the recipient that the API shares with the merchant.
</p>
<p>
For merchants, the resulting <a>PaymentAddress</a> object
provides enough information to, for example, calculate tax,
but, in most cases, not enough information to physically
locate and uniquely identify the payer.
</p>
<p>
Unfortunately, even with the <var>redactList</var>,
recipient anonymity cannot be assured. This is because in
some countries postal codes are so fine-grained that they
can uniquely identify a recipient.
</p>
</div>Let <var>redactList</var> be the empty list. Optionally,
set <var>redactList</var> to « "organization", "phone",
"recipient", "addressLine" ».
</li>
<li>Set <var>address</var> to the result of running the steps to
<a data-cite=
"payment-request#creating-a-paymentaddress-from-user-provided-input">
create a <code>PaymentAddress</code> from user-provided
input</a> with <var>redactList</var>.
</li>
<li>Optionally, redact <var>address</var>.<a data-cite=
"payment-request#dom-paymentaddress-postalcode"><code>postalCode</code></a>
to make it more privacy preserving, but providing enough detail
so that, for example, it can still be used to calculate tax.
</li>
</ol>
</li>
<li data-link-for="BasicCardChangeDetails">Set
<var>methodDetails</var>["<a>billingAddress</a>"] to
<var>billingAddress</var>.
</li>
<li>Run <var>request</var>'s <a data-cite=
"!payment-request#dfn-payment-method-changed-algorithm">payment
method changed algorithm</a> with <var>methodDetails</var> and
"basic-card".
</li>
</ol>
<section data-dfn-for="BasicCardChangeDetails">
<h4>
<dfn>BasicCardChangeDetails</dfn> dictionary
</h4>
<pre class="idl">
dictionary BasicCardChangeDetails {
PaymentAddress? billingAddress;
};
</pre>
<dl>
<dt>
<dfn>billingAddress</dfn> member
</dt>
<dd>
If the merchant requested the billing address, a redacted
<a>PaymentAddress</a> that represents the <a>billing address</a>
associated with the <a>card</a>. If the merchant does not request
the billing address, it's null.
</dd>
</dl>
</section>
</section>
</section>
<section data-dfn-for="BasicCardType" data-link-for="BasicCardType">
<h2>
Expand Down Expand Up @@ -486,10 +592,33 @@ <h2>
<dfn>billingAddress</dfn> member
</dt>
<dd>
A <code><dfn data-cite=
"!payment-request#dom-paymentaddress">PaymentAddress</dfn></code>
that represents the <a>billing address</a> associated with the
<a>card</a>, or null.
A <a>PaymentAddress</a> that represents the <a>billing address</a>
associated with the <a>card</a>, or null.
</dd>
</dl>
</section>
<section>
<h2>
Dependencies
</h2>
<p>
This specification relies on WebIDL definitions defined in other
specifications.
</p>
<dl>
<dt>
Payment Request
</dt>
<dd>
The <code><dfn data-cite=
"payment-request#dom-paymentaddress">PaymentAddress</dfn></code>
interface, <code><dfn data-cite=
"payment-request#dom-paymentaddress">PaymentRequest</dfn></code>
interface, <code><dfn data-cite=
"payment-request#dom-paymentmethodchangeevent">PaymentMethodChangeEvent</dfn></code>
interface and its <code><dfn data-cite=
"payment-request#dom-paymentmethodchangeevent-methoddetails">methodDetails</dfn></code>
attribute, are defined in [[!payment-request]].
</dd>
</dl>
</section>
Expand Down