--- a/latest/charters/payments-wg-charter.html Mon Jul 20 13:52:21 2015 -0500
+++ b/latest/charters/payments-wg-charter.html Mon Jul 20 14:15:12 2015 -0500
@@ -105,7 +105,7 @@
</li>
<li>Increased customer satisfaction due to additional payment options available to users (achieved by decoupling the payer's user agents, digital wallets, and payment instruments).</li>
<li>Improved transparency and confidence in digital payments for consumers as a result of increased choice and
- standardised flows and experiences.
+ standardized flows and experiences.
</li>
<li>Improved security and privacy by providing information only to those parties that require it to complete a
transaction.
@@ -139,30 +139,32 @@
of standardization in areas such as:</p>
<ul>
<li>the high level flow of a Web payment;</li>
- <li>the interfaces between the
+ <li>the programming interfaces between the
various parties (such as between user agent and Web application);</li>
<li>the messages exchanged between these
parties over the Web.</li>
</ul>
<p>The result is that users are led through entirely different flows every time they make a payment on the Web.</p>
- <p>To reduce this fragmentation, this Working Group will create open Web standards for the interfaces in and out of the Web context. This
+ <p>To reduce this fragmentation, this Working Group will create open Web standards for the programming interfaces in and out of the Web context. This
will increase
interoperability between payer and payee systems (for existing and future payment schemes), and encourage
- greater automation of the steps in a typical payment. The interfaces between the payment schemes and the Web
+ greater automation of the steps in a typical payment. The programming interfaces between the payment schemes and the Web
are usually at the user agent and the Web application, therefore the scope of the initial charter is focused
on the interactions between these two components and the external actors that will interface directly with
them. <strong>Note:</strong> These standards may also prove useful in a "native" application context, but this group is not focused on that use case.</p>
- <p>The group will focus primarily on standardisation of a set of messages and a message flow for the initiation,
+ <p>The group will focus primarily on standardization of a set of messages and a message flow for the initiation,
confirmation and completion of a payment. By focusing on the message format and flow, the group leaves open
- the standardisation of the delivery mechanism for these messages as this will vary depending on the use case
+ the standardization of the delivery mechanism for these messages as this will vary depending on the use case
and technology stack. To support use cases where messages are proxied between payer and payee using
different technologies, the group will standardize delivery mechanisms for common scenarios. This
will include WebIDL APIs for the use cases where the messages are proxied between payer and payee via a Web
browser or Web APIs where the messages are exchanged directly over the Web between two online entities in
the classic REST pattern.</p>
+ <p><strong>Note:</strong> This group is chartered to standardize programming interfaces; not user interfaces.</p>
+
<p>For more information about Web Payments activities beyond the scope of this charter, see the <a href="#wpig">Web Payments Interest Group</a> description below.</p>
<h3 id="payment_flow">Payment Flow</h3>
@@ -229,7 +231,8 @@
</figure>
<p>The group will also address exceptions that may occur during these steps, including payment authorization
- failure.</p>
+ failure.</p>
+
<h3 id="security">Security and Privacy Considerations</h3>
@@ -404,7 +407,7 @@
<td class="REC" rowspan="1" colspan="1">June 2017</td>
</tr>
<tr>
- <th rowspan="1" colspan="1">Web Transactions 1.0</th>
+ <th rowspan="1" colspan="1">Web Payments 1.0</th>
<td class="WD1" rowspan="1" colspan="1">April 2016</td>
<td class="CR" rowspan="1" colspan="1">September 2016</td>
<td class="PR" rowspan="1" colspan="1">September 2017</td>