Skip to content

Change the way we request user data #65

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Change the way we request user data #65

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 20 additions & 11 deletions specs/paymentrequest.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -311,7 +311,7 @@ <h2>PaymentRequest constructor</h2>

<pre class="example highlight">
{
"requestShipping": true
"requestedData": ['shipping-address']
}
</pre>

Expand Down Expand Up @@ -648,7 +648,7 @@ <h2>PaymentDetails dictionary</h2>
<h2>PaymentOptions dictionary</h2>
<pre class="idl">
dictionary PaymentOptions {
boolean requestShipping = false;
sequence&lt;RequestedData&gt; requestedData;
};
</pre>

Expand All @@ -660,17 +660,26 @@ <h2>PaymentOptions dictionary</h2>
The following fields MAY be passed to the <a><code>PaymentRequest</code></a> constructor:
</p>
<dl>
<dt><code><dfn>requestShipping</dfn></code></dt>
<dt><code>requestedData</code></dt>
<dd>
This <em>boolean</em> value indicates whether the <a>user agent</a> should collect and return
a shipping address as part of the payment request. For example, this would be set to
<code>true</code> when physical goods need to be shipped by the merchant to the user.
This would be set to <code>false</code> for an online-only electronic purchase transaction.
If this value is not supplied then the the <a><code>PaymentRequest</code></a> behaves as
if a value of <code>false</code> had been supplied.
A sequence containing one or more <code>RequestedData</code> values that the user agent should collect and return as part of the payment request. For example, if a merchant needs to collect shipping address and email, they can request both <code>shipping-address</code> and <code>email</code>
</dd>
</dl>
</section>

<section>
<h2>RequestedData Registry</h2>
<pre class="idl">
enum RequestedData {
"shipping-address",
"email",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we had consensus to support collection of email address at the face-to-face.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, this is a proposal to include the collection of email and phone as part of the API.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'm used to this sort of stuff being hashed out in an issue before there is a PR. Not sure what this group's process is...

"phone-number"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we had consensus to support collection of phone number at the face-to-face.
Add a line note

};
</pre>
<p>
The <code><dfn>RequestedData</dfn></code> enum defines the list of known values that can be requested as part of the payment request.
</p>
</section>

<section>
<h2>PaymentItem dictionary</h2>
Expand Down Expand Up @@ -722,7 +731,7 @@ <h2>ShippingAddress interface</h2>
};
</pre>
<p>
If the <a>requestShipping</a> flag was set to <code>true</code> in the <a>PaymentOptions</a>
If shipping was requested as part of <a>RequestedData</a> in the <a>PaymentOptions</a>
passed to the <a>PaymentRequest</a> constructor, then the <a>user agent</a> will populate the
<code>shippingAddress</code> field of the <a><code>PaymentRequest</code></a> object with
the user's selected shipping address.
Expand Down Expand Up @@ -1105,7 +1114,7 @@ <h2>User accepts the payment request algorithm</h2>
The <a>user agent</a> user interface should ensure that this never occurs.
</li>
<li>
If the <code>requestShipping</code> value of <em>request</em>@[[\options]]
If <code>requestedData</code> contains <code>shipping-address</code> in <em>request</em>@[[\options]]
is <code>true</code>, then if the <code>shippingAddress</code> attribute of <em>request</em>
is <code>null</code> or if the <code>shippingOption</code> attribute of <em>request</em>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line 1118 should probably change from
is <code>true</code>, then if the <code>shippingAddress</code> attribute of <em>request</em>
to
then if the <code>shippingAddress</code> attribute of <em>request</em>
or something like that...

is <code>null</code>, then terminate this algorithm and take no further action. This should
Expand Down