Add new timestamped use cases WD for 2015-07-30 publication.
authorManu Sporny <msporny@digitalbazaar.com>
Tue, 28 Jul 2015 10:34:20 -0400
changeset 927 7cdc07d4c6cf
parent 926 3bcdaff144d2
child 928 f816921757a5
Add new timestamped use cases WD for 2015-07-30 publication.
WD/use-cases/2015-07-30/Overview.html
WD/use-cases/2015-07-30/diff-20150416.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/WD/use-cases/2015-07-30/Overview.html	Tue Jul 28 10:34:20 2015 -0400
@@ -0,0 +1,3407 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document w3p:WD" prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#">
+<head><meta lang="" property="dc:language" content="en">
+    <title>Web Payments Use Cases 1.0</title>
+    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+
+
+
+
+
+    <style type="text/css">
+body {
+  line-height: 1.4em;
+}
+h4 {
+  color: #005A9C;
+}
+dl {
+  margin-top: 20px;
+  margin-bottom: 20px;
+}
+dt,
+dd {
+  line-height: 1.42857143;
+}
+dl > dt:first-of-type {
+  font-weight: bold;
+}
+@media (min-width: 768px), print {
+  .dl-horizontal {
+    margin-bottom: 4em;
+  }
+  .dl-horizontal dt {
+    font-weight: normal;
+    float: left;
+    width: 160px;
+    clear: left;
+    overflow: hidden;
+    text-align: right;
+    text-overflow: ellipsis;
+    white-space: nowrap;
+  }
+  .dl-horizontal dd {
+    margin-left: 180px;
+  }
+  .dl-horizontal dd > ul {
+    padding-left: 20px;
+    margin: 0px;
+  }
+}
+    </style>
+  <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 {
+    text-transform:     lowercase;
+    font-variant:       small-caps;
+    font-style:         normal;
+    color:              #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+    border: none;
+}
+
+dfn {
+    font-weight:    bold;
+}
+
+a.internalDFN {
+    color:  inherit;
+    border-bottom:  1px solid #99c;
+    text-decoration:    none;
+}
+
+a.externalDFN {
+    color:  inherit;
+    border-bottom:  1px dotted #ccc;
+    text-decoration:    none;
+}
+
+a.bibref {
+    text-decoration:    none;
+}
+
+cite .bibref {
+    font-style: normal;
+}
+
+code {
+    color:  #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+    text-decoration:    none;
+}
+
+a .secno, a .figno {
+    color:  #000;
+}
+
+ul.tof, ol.tof {
+    list-style: none outside none;
+}
+
+.caption {
+    margin-top: 0.5em;
+    font-style:   italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+    border-spacing: 0;
+    border-collapse:    collapse;
+    border-bottom:  3px solid #005a9c;
+}
+
+.simple th {
+    background: #005a9c;
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+}
+
+.simple th[scope="row"] {
+    background: inherit;
+    color:  inherit;
+    border-top: 1px solid #ddd;
+}
+
+.simple td {
+    padding:    3px 10px;
+    border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+    background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+    margin-top: 0;
+}
+
+.section dd > p:last-child {
+    margin-bottom: 0;
+}
+
+.section dd {
+    margin-bottom:  1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+    margin-bottom:  0;
+}
+
+@media print {
+    .removeOnSave {
+        display: none;
+    }
+}
+</style><style>/* --- ISSUES/NOTES --- */
+div.issue-title, div.note-title , div.warning-title {
+    padding-right:  1em;
+    min-width: 7.5em;
+    color: #b9ab2d;
+}
+div.issue-title { color: #e05252; }
+div.note-title { color: #2b2; }
+div.warning-title { color: #f22; }
+div.issue-title span, div.note-title span, div.warning-title span {
+    text-transform: uppercase;
+}
+div.note, div.issue, div.warning {
+    margin-top: 1em;
+    margin-bottom: 1em;
+}
+.note > p:first-child, .issue > p:first-child, .warning > p:first-child { margin-top: 0 }
+.issue, .note, .warning {
+    padding: .5em;
+    border-left-width: .5em;
+    border-left-style: solid;
+}
+div.issue, div.note , div.warning {
+    padding: 1em 1.2em 0.5em;
+    margin: 1em 0;
+    position: relative;
+    clear: both;
+}
+span.note, span.issue, span.warning { padding: .1em .5em .15em; }
+
+.issue {
+    border-color: #e05252;
+    background: #fbe9e9;
+}
+.note {
+    border-color: #52e052;
+    background: #e9fbe9;
+}
+
+.warning {
+    border-color: #f11;
+    border-right-width: .2em;
+    border-top-width: .2em;
+    border-bottom-width: .2em;
+    border-style: solid;
+    background: #fbe9e9;
+}
+
+.warning-title:before{
+    content: "⚠"; /*U+26A0 WARNING SIGN*/
+    font-size: 3em;
+    float: left;
+    height: 100%;
+    padding-right: .3em;
+    vertical-align: top;
+    margin-top: -0.5em;
+}
+</style><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+<body class="h-entry" id="respecDocument"><div class="head" role="contentinfo" id="respecHeader">
+  <p>
+
+
+            <a href="http://www.w3.org/"><img width="72" height="48" src="https://www.w3.org/Icons/w3c_home" alt="W3C"></a>
+
+
+  </p>
+  <h1 class="title p-name" id="title" property="dcterms:title">Web Payments Use Cases 1.0</h1>
+
+  <h2 id="w3c-working-draft-30-july-2015"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft <time property="dcterms:issued" class="dt-published" datetime="2015-07-30">30 July 2015</time></h2>
+  <dl>
+
+      <dt>This version:</dt>
+      <dd><a class="u-url" href="http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150730/">http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150730/</a></dd>
+      <dt>Latest published version:</dt>
+      <dd><a href="http://www.w3.org/TR/web-payments-use-cases/">http://www.w3.org/TR/web-payments-use-cases/</a></dd>
+
+
+      <dt>Latest editor's draft:</dt>
+      <dd><a href="https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html">https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html</a></dd>
+
+
+
+
+
+
+      <dt>Previous version:</dt>
+      <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/">http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/</a></dd>
+
+
+    <dt>Editors:</dt>
+    <dd class="p-author h-card vcard" property="bibo:editor" resource="_:editor0"><span property="rdf:first" typeof="foaf:Person"><meta property="foaf:name" content="Manu Sporny"><a class="u-url url p-name fn" property="foaf:homepage" href="https://manu.sporny.org/">Manu Sporny</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://digitalbazaar.com/">Digital Bazaar</a></span>
+<span property="rdf:rest" resource="_:editor1"></span>
+</dd>
+<dd class="p-author h-card vcard" resource="_:editor1"><span property="rdf:first" typeof="foaf:Person"><meta property="foaf:name" content="Ian Jacobs"><a class="u-url url p-name fn" property="foaf:homepage" href="http://www.w3.org/People/Jacobs/">Ian Jacobs</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a></span>
+<span property="rdf:rest" resource="rdf:nil"></span>
+</dd>
+
+
+      <dt>Authors:</dt>
+      <dd class="p-author h-card vcard"><span property="dc:contributor" typeof="foaf:Person"><meta property="foaf:name" content="Ian Jacobs"><a class="u-url url p-name fn" property="foaf:homepage" href="http://www.w3.org/People/Jacobs/">Ian Jacobs</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a></span>
+</dd>
+<dd class="p-author h-card vcard"><span property="dc:contributor" typeof="foaf:Person"><meta property="foaf:name" content="Manu Sporny"><a class="u-url url p-name fn" property="foaf:homepage" href="https://manu.sporny.org/">Manu Sporny</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://digitalbazaar.com/">Digital Bazaar</a></span>
+</dd>
+<dd class="p-author h-card vcard"><span property="dc:contributor" typeof="foaf:Person"><span property="foaf:name" class="p-name fn">Qian Sun</span>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.alibabagroup.com/">Alibaba</a></span>
+</dd>
+<dd class="p-author h-card vcard"><span property="dc:contributor" typeof="foaf:Person"><meta property="foaf:name" content="Cyril Vignet"><a class="u-url url p-name fn" property="foaf:homepage" href="https://www.linkedin.com/pub/cyril-vignet/bb/704/423">Cyril Vignet</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.bpce.fr/">Groupe BPCE</a></span>
+</dd>
+<dd class="p-author h-card vcard"><span property="dc:contributor" typeof="foaf:Person"><meta property="foaf:name" content="David Ezell"><a class="u-url url p-name fn" property="foaf:homepage" href="http://example.org/">David Ezell</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.nacsonline.com/">NACS</a></span>
+</dd>
+<dd class="p-author h-card vcard"><span property="dc:contributor" typeof="foaf:Person"><meta property="foaf:name" content="David Jackson"><a class="u-url url p-name fn" property="foaf:homepage" href="https://www.linkedin.com/in/davidjjackson">David Jackson</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">Oracle</a></span>
+</dd>
+
+
+
+
+
+          <dt>Version control:</dt>
+
+
+
+                  <dd>
+                    <a href="https://github.com/w3c/webpayments-ig">
+                      Github Repository
+                    </a>
+                  </dd>
+
+
+
+                  <dd>
+                    <a href="http://www.w3.org/Payments/IG/track/products/2">
+                      Issues
+                    </a>
+                  </dd>
+
+
+
+
+
+
+  </dl>
+
+
+    <p>
+
+        This document is also available in this non-normative format:
+
+      <a rel="alternate" href="diff-20150416.html">diff to previous version</a>
+    </p>
+
+
+
+
+      <p class="copyright">
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+        2015
+
+        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>).
+
+        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+
+          <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+
+        rules apply.
+      </p>
+
+
+  <hr>
+</div>
+
+  <section id="abstract" class="introductory" property="dc:abstract"><h2 id="h-abstract" resource="#h-abstract"><span property="xhv:role" resource="xhv:heading">Abstract</span></h2>
+    <p>
+This document is a prioritized list of Web payments use cases.
+Guided by these use cases, the <abbr title="World Wide Web Consortium">W3C</abbr> Web Payments Interest Group
+plans to derive architecture and associated technology
+requirements to integrate payments into the Open Web
+Platform. That work will form the basis of conversations with <abbr title="World Wide Web Consortium">W3C</abbr>
+groups and the broader payments industry about what standards
+(from <abbr title="World Wide Web Consortium">W3C</abbr> or other organizations) will be necessary to fulfill the
+use cases and make payments over the Web easier and more secure.
+    </p>
+  </section><section id="sotd" class="introductory"><h2 id="h-sotd" resource="#h-sotd"><span property="xhv:role" resource="xhv:heading">Status of This Document</span></h2>
+
+
+
+        <p>
+          <em>This section describes the status of this document at the time of its publication.
+          Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
+          latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+          http://www.w3.org/TR/.</em>
+        </p>
+
+
+    <p>
+This document is a work in progress and is being released early and often
+using an agile process; it is incomplete.
+    </p>
+    <p>
+The Web Payments IG has only had the opportunity to review a handful of the
+40+ use cases, 120+ requirements, hundreds of pages of
+payments research submitted to the group via various other standards group
+output such as ISO20022, research documents from X9 and the US Federal Reserve,
+documents from the Web Payments Community Group, and input from the
+general public. Our desire is to align with the larger payments industry
+when it's possible to do so. Expect this document to be rapidly iterated upon
+with that desire in mind.
+    </p>
+    <p>
+The following changes have been made since the last version of this document:
+    </p>
+    <ul>
+      <li>
+Reorganization of use cases by phases approved by the Web Payments IG.
+      </li>
+      <li>
+Removal of the "Goals" for each use case as they were repetitive and did not
+greatly aid understanding of the use case.
+      </li>
+      <li>
+Addition of Regulatory concerns to a number of the use cases.
+      </li>
+      <li>
+Addition of two more scenarios related to Direct Debit and Credit Transfer.
+      </li>
+      <li>
+Addition of "Relationship to Other Documents" section.
+      </li>
+      <li>
+Integration of a unified Web Payments Activity glossary.
+      </li>
+      <li>
+Addition of Escrow, Biometric, Know Your Customer (KYC), and
+Anti-Money Laundering (AML) use cases.
+      </li>
+      <li>
+Integration of feedback from the public, Web Payments Community Group, and
+Web Payments Interest Group.
+      </li>
+    </ul>
+
+
+        <p>
+          This document was published by the <a href="http://www.w3.org/Payments/IG/">Web Payments Interest Group</a> as a Working Draft.
+
+            The group does not expect this document to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
+
+            If you wish to make comments regarding this document, please send them to
+            <a href="mailto:public-webpayments-comments@w3.org">public-webpayments-comments@w3.org</a>
+            (<a href="mailto:public-webpayments-comments-request@w3.org?subject=subscribe">subscribe</a>,
+            <a href="http://lists.w3.org/Archives/Public/public-webpayments-comments/">archives</a>).
+
+
+
+
+
+
+            All comments are welcome.
+
+
+        </p>
+
+
+
+          <p>
+            Publication as a Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
+            Membership. This is a draft document and may be updated, replaced or obsoleted by other
+            documents at any time. It is inappropriate to cite this document as other than work in
+            progress.
+          </p>
+
+
+
+        <p>
+
+            This document was produced by a group operating under the
+            <a id="sotd_patent" property="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
+            Policy</a>.
+
+
+
+
+              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/73816/status" rel="disclosure">public list of any patent
+              disclosures</a>
+
+            made in connection with the deliverables of the group; that page also includes
+            instructions for disclosing a patent. An individual who has actual knowledge of a patent
+            which the individual believes contains
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+            Claim(s)</a> must disclose the information in accordance with
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+        </p>
+
+          <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+          </p>
+
+
+
+
+
+</section><section id="toc"><h2 class="introductory" id="h-toc" resource="#h-toc"><span property="xhv:role" resource="xhv:heading">Table of Contents</span></h2><ul class="toc" role="directory" id="respecContents"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#why-this-work-is-important" class="tocxref"><span class="secno">1.1 </span>Why This Work is Important</a></li><li class="tocline"><a href="#relationships" class="tocxref"><span class="secno">1.2 </span>Relationship to Other Documents</a></li><li class="tocline"><a href="#how-this-document-is-organized" class="tocxref"><span class="secno">1.3 </span>How this Document is Organized</a></li></ul></li><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">2. </span>Terminology</a></li><li class="tocline"><a href="#an-overview-of-the-payment-phases" class="tocxref"><span class="secno">3. </span>An Overview of the Payment Phases</a><ul class="toc"><li class="tocline"><a href="#negotiation-of-payment-terms" class="tocxref"><span class="secno">3.1 </span>Negotiation of Payment Terms</a></li><li class="tocline"><a href="#negotiation-of-payment-instruments" class="tocxref"><span class="secno">3.2 </span>Negotiation of Payment Instruments</a></li><li class="tocline"><a href="#payment-processing" class="tocxref"><span class="secno">3.3 </span>Payment Processing</a></li><li class="tocline"><a href="#delivery-of-product-receipt-and-refunds" class="tocxref"><span class="secno">3.4 </span>Delivery of Product/Receipt and Refunds</a></li></ul></li><li class="tocline"><a href="#a-simple-example-of-the-payment-phases" class="tocxref"><span class="secno">4. </span>A Simple Example of the Payment Phases</a><ul class="toc"><li class="tocline"><a href="#negotiation-of-purchase-terms" class="tocxref"><span class="secno">4.1 </span>Negotiation of Purchase Terms</a></li><li class="tocline"><a href="#negotiation-of-payment-instruments-1" class="tocxref"><span class="secno">4.2 </span>Negotiation of Payment Instruments</a></li><li class="tocline"><a href="#payment-processing-1" class="tocxref"><span class="secno">4.3 </span>Payment Processing</a></li><li class="tocline"><a href="#delivery-of-product-receipt-and-refunds-1" class="tocxref"><span class="secno">4.4 </span>Delivery of Product/Receipt and Refunds</a></li></ul></li><li class="tocline"><a href="#assumptions" class="tocxref"><span class="secno">5. </span>Assumptions</a></li><li class="tocline"><a href="#use-cases-1" class="tocxref"><span class="secno">6. </span>Use Cases</a><ul class="toc"><li class="tocline"><a href="#negotiation-of-payment-terms-1" class="tocxref"><span class="secno">6.1 </span>Negotiation of Payment Terms</a><ul class="toc"><li class="tocline"><a href="#discovery-of-offer" class="tocxref"><span class="secno">6.1.1 </span>Discovery of Offer</a></li><li class="tocline"><a href="#agreement-on-terms" class="tocxref"><span class="secno">6.1.2 </span>Agreement on Terms</a></li><li class="tocline"><a href="#application-of-marketing-elements" class="tocxref"><span class="secno">6.1.3 </span>Application of Marketing Elements</a></li></ul></li><li class="tocline"><a href="#negotiation-of-payment-instruments-2" class="tocxref"><span class="secno">6.2 </span>Negotiation of Payment Instruments</a><ul class="toc"><li class="tocline"><a href="#discovery-of-accepted-schemes" class="tocxref"><span class="secno">6.2.1 </span>Discovery of Accepted Schemes</a></li><li class="tocline"><a href="#selection-of-payment-instruments" class="tocxref"><span class="secno">6.2.2 </span>Selection of Payment Instruments</a></li><li class="tocline"><a href="#authentication-to-access-instruments" class="tocxref"><span class="secno">6.2.3 </span>Authentication to Access Instruments</a></li></ul></li><li class="tocline"><a href="#payment-processing-2" class="tocxref"><span class="secno">6.3 </span>Payment Processing</a><ul class="toc"><li class="tocline"><a href="#initiation-of-processing" class="tocxref"><span class="secno">6.3.1 </span>Initiation of Processing</a></li><li class="tocline"><a href="#verification-of-available-funds" class="tocxref"><span class="secno">6.3.2 </span>Verification of Available Funds</a></li><li class="tocline"><a href="#authorization-of-transfer" class="tocxref"><span class="secno">6.3.3 </span>Authorization of Transfer</a></li><li class="tocline"><a href="#completion-of-transfer" class="tocxref"><span class="secno">6.3.4 </span>Completion of Transfer</a></li></ul></li><li class="tocline"><a href="#delivery-of-product-receipt-and-refunds-2" class="tocxref"><span class="secno">6.4 </span>Delivery of Product/Receipt and Refunds</a><ul class="toc"><li class="tocline"><a href="#delivery-of-product" class="tocxref"><span class="secno">6.4.1 </span>Delivery of Product</a></li><li class="tocline"><a href="#delivery-of-receipt" class="tocxref"><span class="secno">6.4.2 </span>Delivery of Receipt</a></li><li class="tocline"><a href="#refunds" class="tocxref"><span class="secno">6.4.3 </span>Refunds</a></li></ul></li></ul></li><li class="tocline"><a href="#additional-examples-of-the-payment-phases" class="tocxref"><span class="secno">7. </span>Additional Examples of the Payment Phases</a><ul class="toc"><li class="tocline"><a href="#credit-card-payment-visa-mastercard" class="tocxref"><span class="secno">7.1 </span>Credit Card Payment (Visa, MasterCard)</a><ul class="toc"></ul></li><li class="tocline"><a href="#tokenized-payments-applepay-venmo-cybersource" class="tocxref"><span class="secno">7.2 </span>Tokenized Payments (ApplePay / Venmo / CyberSource)</a><ul class="toc"></ul></li><li class="tocline"><a href="#three-corner-model-payments-paypal-alipay-google-wallet" class="tocxref"><span class="secno">7.3 </span>Three Corner Model Payments (PayPal / Alipay / Google Wallet)</a><ul class="toc"></ul></li><li class="tocline"><a href="#cryptocurrency-payment-bitcoin-ripple" class="tocxref"><span class="secno">7.4 </span>Cryptocurrency Payment (Bitcoin, Ripple)</a><ul class="toc"></ul></li><li class="tocline"><a href="#electronic-check-payment" class="tocxref"><span class="secno">7.5 </span>Electronic Check Payment</a></li><li class="tocline"><a href="#direct-debit" class="tocxref"><span class="secno">7.6 </span>Direct Debit (SEPA Direct Debit)</a><ul class="toc"></ul></li><li class="tocline"><a href="#credit-transfer" class="tocxref"><span class="secno">7.7 </span>Credit Transfer (SEPAmail)</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#future-work" class="tocxref"><span class="secno">A. </span>Future Work</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.1 </span>Informative references</a></li></ul></li></ul></section>
+
+
+
+  <section id="introduction" typeof="bibo:Chapter" resource="#introduction" property="bibo:hasPart">
+    <!--OddPage--><h2 id="h-introduction" resource="#h-introduction"><span property="xhv:role" resource="xhv:heading"><span class="secno">1. </span>Introduction</span></h2>
+
+    <p>
+ECommerce is thriving and continues to expand. However,
+fragmentation of payment systems is limiting the growth potential
+as are problems — both real and perceived — such as
+fraud and usability.
+    </p>
+
+    <p>
+Because the Web is ubiquitous, strengthening support for Web
+payments has the potential to create new opportunities for
+businesses and customers. Mobile devices are already transforming
+the industry by supplanting physical payment cards in proximity
+payments, voucher distribution, and identification when people
+authenticate to a scanner, point of sale, or access gate. Although
+we are seeing innovation in mobile payment systems, the lack of
+standards makes it more difficult to adapt to new payment
+approaches or integrate new payment providers.
+    </p>
+
+    <p>
+The <abbr title="World Wide Web Consortium">W3C</abbr> Web Payments Interest Group is developing a roadmap for standards to
+improve the interoperability of payments using Web technologies for both
+online and brick-and-mortar (offline) scenarios. This will help achieve
+greater interoperability among merchants and their customers,
+payment providers, software vendors, mobile operators, native mobile
+apps, and payment networks. The roadmap will include
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a> in use
+today (such as electronic checks, credit cards, direct debit, and
+cryptocurrencies) and those of the future. The roadmap will be derived from
+the use cases listed below.
+    </p>
+
+    <section id="why-this-work-is-important" typeof="bibo:Chapter" resource="#why-this-work-is-important" property="bibo:hasPart">
+      <h3 id="h-why-this-work-is-important" resource="#h-why-this-work-is-important"><span property="xhv:role" resource="xhv:heading"><span class="secno">1.1 </span>Why This Work is Important</span></h3>
+      <p>
+The Web Payments work is not just about making payments easier, faster,
+more secure, and more innovative. There are many people around the world that
+today's financial system does not reach. These people are called the world's
+unbanked (or underbanked). The unbanked often live paycheck to paycheck, do
+not have access to savings accounts or low-fee check cashing services, lines
+of credit, or a way of saving for their future. Being unable to plan for one's
+financial future often results in a focus on the short-term, which creates a
+vicious cycle of not being able to escape one's situation. Not being able to
+participate in the financial system creates unintended inequities that create
+waste and result in a net loss for society.
+      </p>
+      <p>
+However, some of the shortcomings of today's financial system could be
+addressed via technological improvements. For example, there is a considerable
+overlap between the unbanked and underbanked population and access to advanced
+mobile phones and the Web. By providing financial services to people with
+mobile phones in a standardized way via the Web, we could see an improvement
+in the financial health of these individuals and their families.
+      </p>
+      <p>
+Extending the current financial system to reach further helps an ever
+increasing number of people plan for their future, focus on the long-term, and
+thus contributes to a greater net gain for society.
+      </p>
+    </section>
+
+    <section id="relationships" typeof="bibo:Chapter" resource="#relationships" property="bibo:hasPart">
+      <h3 id="h-relationships" resource="#h-relationships"><span property="xhv:role" resource="xhv:heading"><span class="secno">1.2 </span>Relationship to Other Documents</span></h3>
+      <p>
+This document is one part of a greater body of work around Web Payments that
+the <a href="https://www.w3.org/Payments/IG/">Web Payments Interest Group</a>
+at <abbr title="World Wide Web Consortium">W3C</abbr> is producing. These other documents include:
+      </p>
+
+      <ul>
+        <li>
+<a href="https://www.w3.org/Payments/IG/Vision">A Vision for Web Payments</a>
+describes the desirable properties of a Web Payments architecture.
+        </li>
+
+        <li>
+<a href="http://www.w3.org/TR/web-payments-use-cases/">Web Payments Use Cases
+1.0</a> (this document) is a prioritized list of all Web Payments scenarios
+that the Web Payments Interest Group expects the architecture to address
+in time.
+        </li>
+
+        <li>
+<a href="https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/capabilities/index.html">
+Web Payments Capabilities 1.0</a>
+derives a set of capabilities from the use cases that, if standardized, will
+improve payments  on the Web.
+        </li>
+
+        <li>
+<a href="https://www.w3.org/Payments/IG/Roadmap">Web Payments Roadmap 1.0</a>
+proposes an implementation and deployment plan that will result in
+enhancements to the Open Web Platform that will achieve the scenarios outlined
+in the Use Cases document and the capabilities listed in the Capabilities
+document.
+        </li>
+      </ul>
+    </section>
+
+    <section id="how-this-document-is-organized" typeof="bibo:Chapter" resource="#how-this-document-is-organized" property="bibo:hasPart">
+      <h3 id="h-how-this-document-is-organized" resource="#h-how-this-document-is-organized"><span property="xhv:role" resource="xhv:heading"><span class="secno">1.3 </span>How this Document is Organized</span></h3>
+
+      <p>
+This document is organized as follows:
+      </p>
+
+      <ul>
+          <li>
+<a href="#terminology">Section 2: Terminology</a> defines basic payment
+terminology.
+        </li>
+        <li>
+<a href="#an-overview-of-the-payment-phases">Section 3: An Overview of the
+Payment Phases</a> describes a common payment flow at a high level. The group
+expects to work on additional payment flows in future work.
+        </li>
+        <li>
+<a href="#a-simple-example-of-the-payment-phases">Section 4: A Simple
+Example of the Payment Phases</a> is a specific
+narrative, labeled according to the steps of section 3.
+<a href="#additional-examples-of-the-payment-phases">Section 7:
+Additional Examples of the Payment Phases</a> describes additional familiar
+narratives to give a more complete picture of how the payment phases apply.
+        </li>
+        <li>
+<a href="#assumptions">Section 5: Assumptions</a> highlights general
+assumptions that have been made about the use cases.
+        </li>
+        <li>
+<a href="#use-cases-1">Section 6: Use Cases</a> lists the use cases - short
+scenarios that cover diverse aspects of each payment step.
+        </li>
+      </ul>
+
+      <p>
+Each use case has:
+      </p>
+      <ul>
+          <li>
+A title and short description.
+        </li>
+        <li>
+A <em>Roadmap phase</em> which specifies the intended phase of the
+<a href="https://www.w3.org/Payments/IG/Roadmap">Web Payments Roadmap</a> that
+will enable the use case.
+        </li>
+        <li>
+A short <em>Motivation</em> statement to help explain why the use
+case has been included, including how it relates to similar use cases.
+        </li>
+      </ul>
+
+      <p>
+Each use case may also have notes on:
+      </p>
+
+      <ul>
+          <li>
+Security/Privacy. Security or privacy issues that may arise through this use
+case.
+        </li>
+        <li>
+Accessibility. Accessibility considerations (e.g., in multi-factor
+authentication, management of biometrics in the case of users with some
+disabilities).
+        </li>
+        <li>
+Regulatory. Regulatory considerations (e.g., anti-money laundering
+clearing, suspicious activity reporting, tax collection, trade compliance).
+        </li>
+        <li>
+Exceptions. Considerations in the case of specific exceptions (e.g., if a
+user pays with a voucher and the <a href="#dfn-transaction" class="internalDFN">transaction</a> fails, the user's voucher
+should be restored).
+        </li>
+      </ul>
+
+      <div class="issue"><div class="issue-title" aria-level="4" role="heading" id="h-issue1"><span>Issue 1</span></div><p class="">
+The group seeks input from security, privacy, and accessibility experts.
+Examples of desired groups to perform these reviews are, but are not
+limited to: <abbr title="World Wide Web Consortium">W3C</abbr> Privacy Interest Group,
+<abbr title="World Wide Web Consortium">W3C</abbr> Security Interest Group, <abbr title="World Wide Web Consortium">W3C</abbr> Web Accessibility Initiative and
+Protocols and Formats Working Group, US Federal Reserve Security Panels,
+X9 Security subgroups, and ISO security subgroups.
+      </p></div>
+
+      <div class="note"><div class="note-title" aria-level="4" role="heading" id="h-note1"><span>Note</span></div><p class="">
+All character names appearing in this document are fictitious. Any resemblance
+to real persons, living or dead, is purely coincidental. Some organizations,
+products, and services appearing in this document are real and are included
+purely for pedagogic purposes and don't imply endorsement or approval of the
+Web Payments work in any way, shape, or form. For all other organizations,
+products, or services appearing in this document, any resemblance to real
+entities is purely coincidental.
+      </p></div>
+
+    </section>
+
+  </section>
+
+  <section id="terminology" typeof="bibo:Chapter" resource="#terminology" property="bibo:hasPart">
+    <!--OddPage--><h2 id="h-terminology" resource="#h-terminology"><span property="xhv:role" resource="xhv:heading"><span class="secno">2. </span>Terminology</span></h2>
+
+    <div><p>
+This document attempts to communicate the concepts outlined in the Web
+Payments space by using specific terms to discuss particular concepts. This
+terminology is included below and linked to throughout the document to aid
+the reader:
+</p>
+
+<dl class="termlist">
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt><dfn id="dfn-entity">entity</dfn></dt>
+
+  <dd>A person, organization, or software agent that is capable of
+  interacting with the world.</dd>
+
+  <dt><dfn id="dfn-four-corner-model">four corner model</dfn></dt>
+
+  <dd>A <a href="#dfn-payment-scheme" class="internalDFN">payment scheme</a> which includes the following stakeholders:
+  the <a href="#dfn-payer" class="internalDFN">payer</a> (also known as the Cardholder), the Issuer (who has a
+  relationship with the Cardholder), the Acceptor and the Acquirer
+  (which has a relationship with the Acceptor). The <a href="#dfn-payment-scheme" class="internalDFN">payment
+  scheme</a> defines the rules which apply to all parties; there are no
+  limitations as to who may join the scheme, as long as the requirements
+  of the scheme are met.</dd>
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt><dfn id="dfn-payee">payee</dfn></dt>
+
+  <dd>An entity that receives funds as required by a transaction.</dd>
+
+  <dt><dfn id="dfn-payer">payer</dfn></dt>
+
+  <dd>An entity that provides a source of funds as required by a
+  transaction.</dd>
+
+  <dt></dt>
+
+
+
+  <dt><dfn id="dfn-payment-instrument">payment instrument</dfn></dt>
+
+  <dd>A mechanism used to transfer value from a <a href="#dfn-payer" class="internalDFN">payer</a> to a
+  <a href="#dfn-payee" class="internalDFN">payee</a>. Examples: Corporate Visa card, personal Visa card, a
+  bitcoin account, a PayPal account, and an Alipay account. [PSD2] any
+  personalized device(s) and/or set of procedures agreed between the
+  payment service user and the payment service provider and used in
+  order to initiate a payment order. [ECB] a tool or a set of procedures
+  enabling the transfer of funds from a payer to a payee.</dd>
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt><dfn id="dfn-payment-processor">payment processor</dfn></dt>
+
+  <dd>An <a href="#dfn-entity" class="internalDFN">entity</a> that submits and processes payments using a
+  particular <a href="#dfn-payment-instrument" class="internalDFN">payment instrument</a> to a payment network. Examples:
+  Stripe, PayPal, Authorize.net, Atos, FedACH.</dd>
+
+  <dt><dfn id="dfn-payment-scheme">payment scheme</dfn></dt>
+
+  <dd>Sets of rules and technical standards for the execution of payment
+  <a title="transaction" href="#dfn-transaction" class="internalDFN">transactions</a> that have to be followed by
+  adhering entities (<a title="payment processor" href="#dfn-payment-processor" class="internalDFN">payment
+  processors</a>, <a title="payer" href="#dfn-payer" class="internalDFN">payers</a> and <a title="payee" href="#dfn-payee" class="internalDFN">payees</a>). Examples: Visa, MasterCard, Bitcoin, Ripple,
+  PayPal, Google Pay, Alipay, Yandex money, ACH, SEPA. [ECB] a set of
+  interbank rules, practices and standards necessary for the functioning
+  of payment services.</dd>
+
+  <dt></dt>
+
+
+
+  <dt><dfn id="dfn-payee-initiated-payment">payee-initiated payment</dfn></dt>
+
+  <dd>Also known as a pull payment, a type of <a href="#dfn-transaction" class="internalDFN">transaction</a> where
+  the <a href="#dfn-payee" class="internalDFN">payee</a> initiates the
+  funds transfer from the <a href="#dfn-payee" class="internalDFN">payee</a>. A credit card payment is an
+  example of a pull payment.</dd>
+
+  <dt><dfn id="dfn-purchase">purchase</dfn></dt>
+
+  <dd>Activities surrounding and including a transaction (e.g.,
+  discovery of an offer, negotiation of terms, selection of payment
+  instrument, delivery, etc.).</dd>
+
+  <dt><dfn id="dfn-payer-initiated-payment">payer-initiated payment</dfn></dt>
+
+  <dd>Also known as a push payment, a type of <a href="#dfn-transaction" class="internalDFN">transaction</a> where the
+  <a href="#dfn-payer" class="internalDFN">payer</a> initiates the
+  funds transfer to the <a href="#dfn-payee" class="internalDFN">payee</a>. PayPal is an example of a push
+  payment.</dd>
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt></dt>
+
+
+
+  <dt><dfn id="dfn-transaction">transaction</dfn></dt>
+
+  <dd>An economic exchange between a <a href="#dfn-payer" class="internalDFN">payer</a> and one or more
+  <a title="payee" href="#dfn-payee" class="internalDFN">payees</a>. An agreement, communication, or movement
+  carried out between a buyer and a seller to exchange an asset for
+  payment.</dd>
+
+  <dt><dfn id="dfn-transfer-order">transfer order</dfn></dt>
+
+  <dd>[ECB] an order or message requesting the transfer of assets (e.g.
+  funds, securities, other financial instruments or commodities) from
+  the debtor to the creditor.</dd>
+
+
+
+
+</dl>
+</div>
+
+  </section>
+
+  <section id="an-overview-of-the-payment-phases" typeof="bibo:Chapter" resource="#an-overview-of-the-payment-phases" property="bibo:hasPart">
+    <!--OddPage--><h2 id="h-an-overview-of-the-payment-phases" resource="#h-an-overview-of-the-payment-phases"><span property="xhv:role" resource="xhv:heading"><span class="secno">3. </span>An Overview of the Payment Phases</span></h2>
+
+    <p>There are many types of <a href="#dfn-transaction" class="internalDFN">transaction</a>s in the world of payments,
+including person-to-business, business-to-business, business-to-person,
+government-to-person, person-to-government, and
+person-to-person. In this document we focus on the
+interactions between a <a href="#dfn-payer" class="internalDFN">payer</a> and a <a href="#dfn-payee" class="internalDFN">payee</a>,
+either of which could be a person, business, government, or software
+agent), which we organize into four phases:</p>
+
+    <div class="issue"><div class="issue-title" aria-level="3" role="heading" id="h-issue2"><span>Issue 2</span></div><p class="">
+The group would like feedback related to the general structure of the payment
+phases from individuals that worked on ISO20022, ISO12812, the
+European Payment Commission, and
+various X9 documents to ensure that the phases reflect business processes
+outlined in financial standardization initiatives. Feedback from the general
+public is also requested to see if non-payment professionals can navigate and
+understand the document without prior payment industry knowledge.
+    </p></div>
+
+    <ol>
+        <li>
+Negotiation of Payment Terms
+        </li>
+        <li>
+Negotiation of Payment Instruments
+        </li>
+        <li>
+Payment Processing
+        </li>
+        <li>
+Delivery of Product/Receipt and Refunds
+        </li>
+    </ol>
+
+<p>The descriptions below only discuss the interactions between the
+<a href="#dfn-payer" class="internalDFN">payer</a> and the <a href="#dfn-payee" class="internalDFN">payee</a>. We do not expose the low-level exchanges
+between banks, card associations, or other back-end "payment clearing" parties
+in a <a href="#dfn-transaction" class="internalDFN">transaction</a>. Those details will be discussed in the Interest
+Group's work on architecture and
+requirements.</p>
+
+ <p>Each phase below consists of a series of steps.
+The details of each step vary by <a href="#dfn-payment-scheme" class="internalDFN">payment scheme</a>. Some steps may
+not be relevant at certain times (e.g., depending on
+<a href="#dfn-payment-scheme" class="internalDFN">payment scheme</a> or <a href="#dfn-transaction" class="internalDFN">transaction</a> specifics).
+For example, some  <a title="purchase" href="#dfn-purchase" class="internalDFN">purchases</a> do not involve a proof of
+funds or proof of hold. ACH and SEPA
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a> generally do not support the
+verification of available funds, thus in these
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a> the particular proof of funds
+step is skipped.
+In some cases, steps may happen in a slightly different order than described below.
+  </p>
+    <p>
+It is also important to note that these phases and steps may be interrupted
+at various times (e.g., one party drops out, or exceptions occur like
+insufficient funds or a regulatory block). While these phases are an
+approximation of the general flow of all payments, they are helpful in
+structuring the use cases such that it is easy to figure out to which part of
+the payment process a particular use case belongs.
+    </p>
+
+ <p>While these four phases may apply more or less well to a variety
+of other payment scenarios such as person-to-person
+payments, those topics are not the current focus of the group.  We
+plan to address them directly in <a href="#future-work">future
+work</a>.</p>
+
+    <section id="negotiation-of-payment-terms" typeof="bibo:Chapter" resource="#negotiation-of-payment-terms" property="bibo:hasPart">
+      <h3 id="h-negotiation-of-payment-terms" resource="#h-negotiation-of-payment-terms"><span property="xhv:role" resource="xhv:heading"><span class="secno">3.1 </span>Negotiation of Payment Terms</span></h3>
+      <p>
+In the first phase of the payment process, the <a href="#dfn-payer" class="internalDFN">payer</a> and the
+<a href="#dfn-payee" class="internalDFN">payee</a> negotiate the terms of the payment.
+      </p>
+
+      <ul>
+          <li>
+<strong>Discovery of Offer</strong>. The <a href="#dfn-payer" class="internalDFN">payer</a> discovers the
+<a title="payee" href="#dfn-payee" class="internalDFN">payee's</a> offer (e.g., by browsing a Web page or
+from a native application).
+        </li>
+        <li>
+<strong>Agreement on Terms</strong>. The <a href="#dfn-payer" class="internalDFN">payer</a> and the
+<a href="#dfn-payee" class="internalDFN">payee</a> agree to what will be purchased, for how much,
+in what currency, which <a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a>
+or loyalty programs are acceptable, etc. The <a href="#dfn-payee" class="internalDFN">payee</a> may require the
+<a href="#dfn-payer" class="internalDFN">payer</a> to authenticate themselves. The <a href="#dfn-payee" class="internalDFN">payee</a> may generate an
+invoice for the <a href="#dfn-payer" class="internalDFN">payer</a>.
+        </li>
+        <li>
+<strong>Application of Marketing Elements</strong>. The <a href="#dfn-payer" class="internalDFN">payer</a>
+discovers and applies any loyalty programs, coupons, and other special offers
+to the payment terms.
+        </li>
+      </ul>
+    </section>
+
+    <section id="negotiation-of-payment-instruments" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments" property="bibo:hasPart">
+      <h3 id="h-negotiation-of-payment-instruments" resource="#h-negotiation-of-payment-instruments"><span property="xhv:role" resource="xhv:heading"><span class="secno">3.2 </span>Negotiation of Payment Instruments</span></h3>
+      <p>
+In the second phase of the payment process, <a href="#dfn-payer" class="internalDFN">payer</a> and
+<a href="#dfn-payee" class="internalDFN">payee</a> determine which
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a> the
+<a href="#dfn-payer" class="internalDFN">payer</a> will use to transfer funds to the <a href="#dfn-payee" class="internalDFN">payee</a>.
+      </p>
+
+      <ul>
+          <li>
+<strong>Discovery of Accepted Schemes</strong>. The <a href="#dfn-payer" class="internalDFN">payer</a>
+discovers the <a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a> that
+are accepted by the <a href="#dfn-payee" class="internalDFN">payee</a>.
+        </li>
+        <li>
+<strong>Selection of Payment Instruments</strong>. The <a href="#dfn-payer" class="internalDFN">payer</a>
+selects one or more <a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a>
+that are available to the <a href="#dfn-payer" class="internalDFN">payer</a> and are accepted by the
+<a href="#dfn-payee" class="internalDFN">payee</a>.
+        </li>
+        <li>
+<strong>Authentication to Access Instruments</strong>. The
+<a title="payer" href="#dfn-payer" class="internalDFN">payer's</a> access to the <a href="#dfn-payment-instrument" class="internalDFN">payment instrument</a>
+is authenticated. The <a href="#dfn-payer" class="internalDFN">payer</a> consents to pay. Note: This authentication
+with the <a href="#dfn-payment-processor" class="internalDFN">payment processor</a> is distinct from any authentication required
+by the <a href="#dfn-payee" class="internalDFN">payee</a> (such as when a merchant requires a customer to
+have an account and log in to the merchant's Web site).
+        </li>
+      </ul>
+    </section>
+
+    <section id="payment-processing" typeof="bibo:Chapter" resource="#payment-processing" property="bibo:hasPart">
+      <h3 id="h-payment-processing" resource="#h-payment-processing"><span property="xhv:role" resource="xhv:heading"><span class="secno">3.3 </span>Payment Processing</span></h3>
+      <p>
+The third phase of the payment process is used to initiate the transfer of
+funds. Depending on the <a href="#dfn-payment-instrument" class="internalDFN">payment instrument</a>, the transfer of funds
+may be verified immediately or only after several days.
+      </p>
+       <ul>
+          <li>
+<strong>Initiation of Processing</strong>. Depending on the
+<a href="#dfn-payment-instrument" class="internalDFN">payment instrument</a>, the <a href="#dfn-payer" class="internalDFN">payer</a> (e.g., when using
+PayPal or Yandex Money), the <a href="#dfn-payee" class="internalDFN">payee</a> (e.g., when using a credit card), or other
+party (e.g., bank) initiates processing.
+        </li>
+        <li>
+<strong>Verification of Available Funds</strong>. The <a href="#dfn-payer" class="internalDFN">payer</a> may
+need to provide a proof of funds or a proof of hold to the <a href="#dfn-payee" class="internalDFN">payee</a>
+before finalizing payment and delivery of the product.
+        </li>
+        <li>
+<strong>Authorization of Transfer</strong>. The <a href="#dfn-payee" class="internalDFN">payee</a> receives
+proof that the transfer of funds has been authorized.
+        </li>
+        <li>
+<strong>Completion of Transfer</strong>. The <a href="#dfn-payment-scheme" class="internalDFN">payment scheme</a>
+determines the details of payment clearing and settlement. Transfer times
+may vary from near-realtime to multiple days. The <a href="#dfn-payee" class="internalDFN">payee</a>,
+the <a href="#dfn-payer" class="internalDFN">payer</a>, and/or third parties (such as regulatory bodies) may be
+notified as each stage of the clearing and settlement process is completed.
+        </li>
+      </ul>
+    </section>
+
+    <section id="delivery-of-product-receipt-and-refunds" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds" property="bibo:hasPart">
+      <h3 id="h-delivery-of-product-receipt-and-refunds" resource="#h-delivery-of-product-receipt-and-refunds"><span property="xhv:role" resource="xhv:heading"><span class="secno">3.4 </span>Delivery of Product/Receipt and Refunds</span></h3>
+      <p>
+In the fourth phase of the payment process, the <a href="#dfn-transaction" class="internalDFN">transaction</a> is completed
+by providing the <a href="#dfn-payer" class="internalDFN">payer</a> with a receipt and/or the product that
+was purchased.
+      </p>
+
+      <ul>
+          <li>
+<strong>Delivery of Product</strong>. The <a href="#dfn-payer" class="internalDFN">payer</a> receives goods or
+services immediately, at a later date, automatically on a recurring basis,
+etc. depending on the terms of the <a href="#dfn-purchase" class="internalDFN">purchase</a>. A digital proof of
+payment may be required to access the product.
+        </li>
+        <li>
+<strong>Delivery of Receipt</strong>. Depending on the
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment scheme(s)</a> chosen, there are
+various ways and times that a receipt may be delivered (e.g., credit card
+receipt, digital proof of <a href="#dfn-purchase" class="internalDFN">purchase</a>, or encrypted line-item receipt).
+        </li>
+        <li>
+<strong>Refunds</strong>. At times exceptions may occur (e.g., defective
+product or application of store return policy). In this case, the
+<a href="#dfn-payee" class="internalDFN">payee</a> initiates payment to the <a href="#dfn-payer" class="internalDFN">payer</a>. The refund may
+take different forms, including a refund to the <a title="payer" href="#dfn-payer" class="internalDFN">payer's</a>
+payment instrument, a refund using a different payment scheme, or store credit.
+        </li>
+      </ul>
+    </section>
+
+  </section>
+
+  <section id="a-simple-example-of-the-payment-phases" typeof="bibo:Chapter" resource="#a-simple-example-of-the-payment-phases" property="bibo:hasPart">
+    <!--OddPage--><h2 id="phases-overview" resource="#phases-overview"><span property="xhv:role" resource="xhv:heading"><span class="secno">4. </span>A Simple Example of the Payment Phases</span></h2>
+    <p>
+The following scenario is provided to aid the reader in understanding how the
+phases of the payment process apply to a real world situation. In this scenario,
+we follow Jill, who seeks a new outfit for a party. She selects items from
+PayToParty, which is a brick-and-mortar store with an online presence.
+She chooses how to pay and the items are delivered to her home on the
+following day.
+    </p>
+
+    <p>
+See the appendix for <a href="#additional-examples">additional examples of
+the payment phases</a>.
+    </p>
+
+    <div class="issue"><div class="issue-title" aria-level="3" role="heading" id="h-issue3"><span>Issue 3</span></div><p class="">
+General feedback is requested on whether this section is helpful. We are
+attempting to ground the payment phases and steps in a real world use case.
+An alternative would be removing this section entirely if the preceding
+section suffices, or moving this narrative to section 7 with the other examples.
+    </p></div>
+
+    <section id="negotiation-of-purchase-terms" typeof="bibo:Chapter" resource="#negotiation-of-purchase-terms" property="bibo:hasPart">
+      <h3 id="h-negotiation-of-purchase-terms" resource="#h-negotiation-of-purchase-terms"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.1 </span>Negotiation of Purchase Terms</span></h3>
+      <ul>
+        <li>
+<strong>Discovery of Offer</strong>: Jill begins her <a href="#dfn-purchase" class="internalDFN">purchase</a> at
+home on her laptop, where she browses the items on the PayToParty Web
+site. On the way to work the next morning, she explores the catalog
+further from a native app on her smart phone. Jill can't decide
+whether the dress displayed online is
+<a href="https://en.wikipedia.org/wiki/The_dress_(viral_phenomenon)">
+blue with black stripes or white with gold stripes</a>,
+so during her lunch break, she drops into the
+PayToParty store near her office. She spots a few more items that
+she thinks she'd like to <a href="#dfn-purchase" class="internalDFN">purchase</a>, but decides to wait until later to
+make the <a href="#dfn-purchase" class="internalDFN">purchase</a>.
+        </li>
+
+        <li>
+<strong>Agreement on Terms</strong>: That same evening at home,
+Jill logs into her account on the PayToParty Web site, adding her
+chosen items to her shopping cart. The total price appears on the
+page.
+        </li>
+
+        <li>
+<strong>Application of Marketing Elements</strong>: As Jill prepares to
+check out, PayToParty notifies her of a discount for 10% if she uses
+the store's loyalty card to pay.
+        </li>
+      </ul>
+    </section>
+
+    <section id="negotiation-of-payment-instruments-1" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-1" property="bibo:hasPart">
+      <h3 id="h-negotiation-of-payment-instruments-1" resource="#h-negotiation-of-payment-instruments-1"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.2 </span>Negotiation of Payment Instruments</span></h3>
+      <ul>
+        <li>
+<strong>Discovery of Accepted Schemes</strong>: Given where Jill lives,
+PayToParty accepts payment by credit card, debit card, the PayToParty
+loyalty card, and PayPal, but not Jill's favorite cryptocurrency (which she
+uses on other sites).
+        </li>
+
+        <li>
+<strong>Selection of Payment Instruments</strong>: Jill pushes the
+"Pay Now to Party!" button and is presented with a number of options
+to pay, including her
+credit card, her PayToParty loyalty card (which is highlighted to remind her
+of the discount), and a PayPal account. There is also a gift card from
+PayToParty that she received for her birthday, but she chooses not to
+use it for this <a href="#dfn-purchase" class="internalDFN">purchase</a>.
+        </li>
+
+        <li>
+<strong>Authentication to Access Instruments</strong>: Jill selects
+the PayToParty loyalty card, the use of which is protected by two-factor
+authentication, and is asked to input a code that is sent to her phone
+before the <a href="#dfn-purchase" class="internalDFN">purchase</a> can be completed.
+        </li>
+      </ul>
+    </section>
+
+    <section id="payment-processing-1" typeof="bibo:Chapter" resource="#payment-processing-1" property="bibo:hasPart">
+      <h3 id="h-payment-processing-1" resource="#h-payment-processing-1"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.3 </span>Payment Processing</span></h3>
+      <ul>
+        <li>
+<strong>Initiation of Processing</strong>. PayToParty receives a
+message from Jill's device authorizing the payment. PayToParty
+submits the message to their <a href="#dfn-payment-processor" class="internalDFN">payment processor</a>, requesting a
+proof of hold for the funds.
+        </li>
+        <li>
+<strong>Verification of Available Funds</strong>. PayToParty
+receives a proof of hold on Jill's funds for the <a href="#dfn-purchase" class="internalDFN">purchase</a> price of
+the goods. The PayToParty night-shift employees begin packing her purchased
+items for delivery the next day.
+        </li>
+        <li>
+<strong>Authorization of Transfer</strong>. Once Jill's package is ready to
+go, PayToParty exchanges the proof of hold for a proof of payment by
+re-submitting the request to the payment network. They receive a proof of
+payment from the <a href="#dfn-payment-processor" class="internalDFN">payment processor</a>.
+        </li>
+        <li>
+<strong>Completion of Transfer</strong>. Since Jill's PayToParty loyalty card
+operates as a credit card, PayToParty will receive the funds in their normal
+end of week settlement.
+        </li>
+      </ul>
+    </section>
+
+    <section id="delivery-of-product-receipt-and-refunds-1" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-1" property="bibo:hasPart">
+      <h3 id="h-delivery-of-product-receipt-and-refunds-1" resource="#h-delivery-of-product-receipt-and-refunds-1"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.4 </span>Delivery of Product/Receipt and Refunds</span></h3>
+      <ul>
+        <li>
+<strong>Delivery of Receipt</strong>. Jill's cloud-based wallet
+receives a detailed line-item digital receipt for the <a href="#dfn-purchase" class="internalDFN">purchase</a>.
+        </li>
+
+        <li>
+<strong>Delivery of Product</strong>. Jill's package goes out by courier the
+next morning and is on her doorstep before she leaves for work.
+        </li>
+      </ul>
+    </section>
+  </section>
+
+  <section id="assumptions" typeof="bibo:Chapter" resource="#assumptions" property="bibo:hasPart">
+    <!--OddPage--><h2 id="h-assumptions" resource="#h-assumptions"><span property="xhv:role" resource="xhv:heading"><span class="secno">5. </span>Assumptions</span></h2>
+
+    <p>
+The use cases below rely on a number of assumptions that are not
+detailed in the use cases but that will be explored in more detail in
+the architecture and requirements documents.
+    </p>
+
+    <ul>
+        <li>
+<strong>Connectivity</strong>. Connectivity requirements vary according to
+use case. The types of connections a device may use include Internet
+connectivity, proxied connections through short-range radio transmissions,
+and proximity connections over a technology such as Near-Field Communication
+(NFC) or Bluetooth Low Energy (BTLE). Some use cases assume no
+connectivity (e.g., user is temporarily unable to connect to a mobile phone
+network or a WiFi hotspot).
+        </li>
+        <li>
+<strong>Registered Payment Instruments</strong>. In order for the
+<a href="#dfn-payer" class="internalDFN">payer</a> to select and utilize
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a>, they must be
+registered in some way and discoverable by a browser, native application,
+or other software.
+        </li>
+        <li>
+<strong>Security</strong>. Keys, encryption, and other security technology
+must be used to secure sensitive information. It is important that sensitive
+information is not transmitted to parties that do not absolutely need to
+know the information in order to complete the <a href="#dfn-transaction" class="internalDFN">transaction</a>.</li>
+        <li>
+<strong>Identity</strong>. There will be an interoperable
+identifier used to identify the participants and accounts in a Web Payments
+transaction.
+        </li>
+    </ul>
+  </section>
+
+  <section id="use-cases-1" typeof="bibo:Chapter" resource="#use-cases-1" property="bibo:hasPart">
+    <!--OddPage--><h2 id="use-cases" resource="#use-cases"><span property="xhv:role" resource="xhv:heading"><span class="secno">6. </span>Use Cases</span></h2>
+
+    <p>
+This section examines the phases of payment, and the steps involved in each
+phase, through a variety of use cases. The purpose of this section is to
+elaborate on the variety of scenarios present in each step of the payment
+process.
+    </p>
+
+    <div class="issue"><div class="issue-title" aria-level="3" role="heading" id="h-issue4"><span>Issue 4</span></div><p class="">
+General feedback is requested related to the general structure of the
+use case snippets below. Are they focused enough to convey each topic listed?
+Is there information that should be added to each use case in general? Would
+more elaborate use cases be helpful? Would an attempt to minimize each existing
+use further be helpful in scanning the document more quickly?
+    </p></div>
+
+    <section id="negotiation-of-payment-terms-1" typeof="bibo:Chapter" resource="#negotiation-of-payment-terms-1" property="bibo:hasPart">
+      <h3 id="h-negotiation-of-payment-terms-1" resource="#h-negotiation-of-payment-terms-1"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.1 </span>Negotiation of Payment Terms</span></h3>
+      <p>
+      </p>
+
+      <section id="discovery-of-offer" typeof="bibo:Chapter" resource="#discovery-of-offer" property="bibo:hasPart">
+        <h4 id="h-discovery-of-offer" resource="#h-discovery-of-offer"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.1.1 </span>Discovery of Offer</span></h4>
+
+        <dl id="uc-website" class="dl-horizontal">
+          <dt>Website</dt>
+          <dd>
+Penny uses the HobbyCo website to select a $15 model train for <a href="#dfn-purchase" class="internalDFN">purchase</a>.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+A human being seeing a visual offer of sale on a website is the most common
+way offers are discovered on the Web today (2015).
+          </dd>
+        </dl>
+
+        <dl id="uc-pos-kiosk" class="dl-horizontal">
+          <dt>Point of Sale Kiosk</dt>
+          <dd>
+Cory shops for groceries at his local ChowMart, scans his loyalty card and
+all of the items he wants to <a href="#dfn-purchase" class="internalDFN">purchase</a> at the automated kiosk, requests
+a cash back amount, and is presented with a total amount.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Unifying point of sale interaction w/ the Web Payments architecture is
+vital for the success of this work.
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+At present kiosks are rarely accessible to blind people, people with low
+vision, people who use wheelchairs, or people with restricted mobility that
+makes touch interaction difficult or impossible. They don’t tend to offer
+speech output, any ability to zoom or customise colours, may be difficult to
+reach from a wheelchair/sitting position, and do not accept voice commands.
+Enabling as much of the payment interaction to move to a customer-held device
+with accessibility features would help alleviate a number of barriers that
+exist today.
+          </dd>
+          <dt>Privacy</dt>
+          <dd>
+Cory should exercise control over how much he wants the merchant
+to be able to track his activities. Programs like loyalty cards will
+likely involve agreement to more data with the merchant.<br>
+Making kiosks that are used for financial transactions accessible introduces
+several challenges. Speech output may be overheard by people nearby, increased
+text size and/or visibility of content may make it easier for other people
+to read, and voice commands may also be overheard.
+          </dd>
+        </dl>
+
+        <dl id="uc-mobile" class="dl-horizontal">
+          <dt>Mobile</dt>
+          <dd>
+A mobile device can be used to discover an offer in a variety of ways:
+            <ul>
+              <li>
+Hani takes a taxi from the airport to his hotel. The taxi driver
+displays the total with his mobile device. Hani and the taxi driver
+touch their mobile devices to each other. The total appears on Hani's mobile
+device.
+              </li>
+              <li>
+There is a Quick Response Code (QR Code) printed on the bottom of a cup that
+Donna wants to buy. Donna uses her mobile phone app to capture the QR Code,
+view the price of the item, and add it to the list of items that she is buying
+from the store.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Unifying the way proximity mobile offers work with the Web Payments
+architecture would help ensure ubiquity.
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+An auditory cue notifying people that have low vision or are blind
+that a payment offer/invoice is awaiting their response as well as providing
+guidance on how close their payment device is to the payment terminal would
+be helpful.
+          </dd>
+          <dt>Exceptions</dt>
+          <dd>
+No mobile phone connectivity (e.g. visiting a different country or trip occurs
+outside the range of a mobile network).
+          </dd>
+        </dl>
+
+        <dl id="uc-freemium" class="dl-horizontal">
+          <dt>Freemium</dt>
+          <dd>
+Chaoxiang plays his favorite native app game and wants to upgrade his avatar
+with a few extra "power-ups". Clicking on a power-up displays the price.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Many of the very successful games these days run on the freemium model,
+but are tied to specific app stores. Providing an app-store agnostic
+mechanism to pay for items in freemium games would give players and
+developers more choices.
+          </dd>
+        </dl>
+
+        <dl id="uc-email" class="dl-horizontal">
+          <dt>Email</dt>
+          <dd>
+A GroupBuyCo customer receives an offer by email to <a href="#dfn-purchase" class="internalDFN">purchase</a> the deal
+of the day.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Unifying how people initiate payments from email, at a point of sale,
+and via a Web site will help ensure the ubiquity of the Web payment
+technology platform.
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>
+It is important to recognize that initiating a payment from within an
+email application could lead to a wholly new category of phishing/fraud.
+          </dd>
+        </dl>
+
+        <dl id="uc-hold-funds" class="dl-horizontal">
+          <dt>Hold Funds</dt>
+          <dd>
+Renne checks into a hotel and is asked for a deposit for any damages
+to the room.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Some <a title="transaction" href="#dfn-transaction" class="internalDFN">transactions</a>, such as a hold of funds,
+do not always reach completion and are primarily used
+to protect the <a href="#dfn-payee" class="internalDFN">payee</a> from negligence on the part of the
+<a href="#dfn-payer" class="internalDFN">payer</a> (e.g., such as a <a href="#dfn-payer" class="internalDFN">payer</a> damaging a hotel room).
+          </dd>
+          <dt>Exceptions</dt>
+          <dd>
+Software acting on the <a title="payer" href="#dfn-payer" class="internalDFN">payer's</a> behalf may keep
+track of exactly how much money the <a href="#dfn-payer" class="internalDFN">payer</a> has available and
+not allow them to process the offer.
+          </dd>
+        </dl>
+
+        <dl id="uc-preauth" class="dl-horizontal">
+          <dt>Pre-authorization</dt>
+          <dd>
+Krishna pulls up to a pump at a petrol station. His in-vehicle application
+recognizes the station location and the pump. The pump communicates which
+fuels it has and their price in an offer. Krishna's car asks if he wants to
+approve a fill up for up to €35.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Some offers are not aware of the final price but would rather set limits on
+the amount of the <a href="#dfn-purchase" class="internalDFN">purchase</a> before a particular metered good or service is
+delivered.
+          </dd>
+          <dt>Privacy</dt>
+          <dd>
+Due to the sensitivity of location data, individuals should be able to make
+small fuel <a title="purchase" href="#dfn-purchase" class="internalDFN">purchases</a> in a way that respects their privacy.
+          </dd>
+          <dt>Security</dt>
+          <dd>
+Automated <a title="purchase" href="#dfn-purchase" class="internalDFN">purchases</a> (e.g,. by a vehicle) may involve
+increased logging and security (e.g., a second factor of authentication).
+          </dd>
+          <dt>Regulatory</dt>
+          <dd>
+If a pre-authorization is initiated by a software agent (such as a vehicle)
+due to a <a title="payer" href="#dfn-payer" class="internalDFN">payer's</a> negligence, the regulatory environment
+may assert that the software manufacturer is liable if the proper consent
+notifications were not displayed when the pre-authorization rule was activated.
+          </dd>
+        </dl>
+
+        <dl id="uc-machine-readability" class="dl-horizontal">
+          <dt>Machine Readability</dt>
+          <dd>
+BigBoxCo expresses their entire product catalog online as machine-readable
+information so that SearchCo may index their content more easily and direct
+more customer traffic to BigBoxCo's website.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Machine-readable offers will have a direct positive impact on store sales
+if they are indexed by search engines.
+          </dd>
+        </dl>
+
+        <dl id="uc-live-prices" class="dl-horizontal">
+          <dt>Live Market Prices</dt>
+          <dd>
+EnergyCo lists barrels of refined oil for sale on their website based on an
+algorithm that uses the cost of coal and crude oil as inputs. EnergyCo
+guarantees their prices for up to 24 hours from the posting date.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+The ability to express a non-repudiable offer as the basis of a legally
+enforceable contract will reduce <a href="#dfn-transaction" class="internalDFN">transaction</a> friction.
+          </dd>
+          <dt>Regulatory</dt>
+          <dd>
+Listing inaccurate prices or not honoring prices could be prosecuted under
+certain regulatory regimes.
+          </dd>
+        </dl>
+
+        <dl id="uc-trialware" class="dl-horizontal">
+          <dt>Trialware</dt>
+          <dd>
+Amantha downloads the latest version of her favorite game and beats
+the first level. The game asks her if she'd like to buy the full game
+to play further levels.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+There is a fairly large trialware industry that could benefit from
+a simple way of executing a payment without requiring redirection
+to another site to enter account and payment details.
+          </dd>
+        </dl>
+
+        <dl id="uc-vehicle" class="dl-horizontal">
+          <dt>In-vehicle</dt>
+          <dd>
+Jeff listens to a lot of music on the way to work. The music station
+serves a digital offer along with the music stream. This enables Jeff to
+easily buy music that he really likes.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Car manufacturers and the entertainment industry may be interested in
+extending their sales channels into vehicles.
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+For safety reasons, the interface used to interact with the digital offer
+must not lead to an increase in vehicle accidents.
+          </dd>
+          <dt>Regulatory</dt>
+          <dd>
+It may be illegal to provide services such as this if the vehicle is in
+motion or if it requires the driver to look away from the road.
+          </dd>
+        </dl>
+
+        <dl id="uc-memorable-ids" class="dl-horizontal">
+          <dt>Memorable Ids</dt>
+          <dd>
+Vern sends money to his friend Milena by typing in Milena's mobile phone number
+and the amount he wants to send.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Some countries, like the United Kingdom, maintain registries that map
+memorable identifiers like mobile phone numbers to bank accounts. These
+memorable payment identifiers can be used to transmit money from person to
+person using direct bank to bank transfers.
+          </dd>
+        </dl>
+
+      </section>
+
+      <section id="agreement-on-terms" typeof="bibo:Chapter" resource="#agreement-on-terms" property="bibo:hasPart">
+        <h4 id="h-agreement-on-terms" resource="#h-agreement-on-terms"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.1.2 </span>Agreement on Terms</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-one-time-payment" class="dl-horizontal">
+          <dt>One-time Payment</dt>
+          <dd>
+Jamie wishes to pay for a single article from a market analyst.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>It should be clear to a
+<a title="payer" href="#dfn-payer" class="internalDFN">payer</a> whether a
+<a href="#dfn-purchase" class="internalDFN">purchase</a> is one-time or recurring, prior to initiation of
+the payment.
+          </dd>
+        </dl>
+
+        <dl id="uc-registrationless" class="dl-horizontal">
+          <dt>Registration-less</dt>
+          <dd>
+Some <a title="payee" href="#dfn-payee" class="internalDFN">payees</a> would rather not require a <a href="#dfn-payer" class="internalDFN">payer</a> to
+register at their site before initiating a purchase:
+            <ul>
+              <li>
+Sven wants to view a pay to read article and does so without needing to
+pre-register with the website.
+              </li>
+              <li>
+Reiko finds a blowtorch for sale at a local digital resale website and
+places money into escrow without needing to register with the website.
+              </li>
+              <li>
+Olaseni is listening to music in a local coffee shop and likes a song he hears.
+He initiates a purchase of the song from the local "music beacon" without
+needing to register with the coffee shop or the music service.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+There are a large number of "paywall" websites on the Web that require a
+customer to register before they may use the website. In many cases, if the
+site isn't regularly visited by the customer, they abandon the transaction
+when they see the paywall requirement. Providing a mechanism to sell an
+inexpensive item to a customer without requiring registration would be of
+great benefit to not only the merchants selling goods and services, but
+customers that would like to avoid lengthy registration processes.
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+People who are on the Autistic spectrum may require trust with the merchant
+to be established through a more formal means to prevent distress and
+abandonment of the transaction.
+          </dd>
+        </dl>
+
+        <dl id="uc-subscription" class="dl-horizontal">
+          <dt>Subscription</dt>
+          <dd>
+Larissa subscribes to a site that provides a monthly analysis of the world
+of finance.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1 (if time permits)</dd>
+          <dt>Motivation</dt>
+          <dd>
+<a title="payer" href="#dfn-payer" class="internalDFN">Payers</a> should be able to understand if a
+particular <a href="#dfn-purchase" class="internalDFN">purchase</a> is a recurring payment prior to initiating
+the payment.
+          </dd>
+          <dt>Regulatory</dt>
+          <dd>
+Some regulations may require that subscriptions should be automatically
+canceled after the subscription time span unless explicitly renewed by
+a <a href="#dfn-payer" class="internalDFN">payer</a>.
+          </dd>
+        </dl>
+
+        <dl id="uc-credentials" class="dl-horizontal">
+          <dt>Credentials</dt>
+          <dd>
+At times it is necessary to transmit personally identifiable information
+(e.g., about a qualification, achievement, personal quality, aspect of an
+<a href="#dfn-entity" class="internalDFN">entity</a>'s background, or verifiable statement by an entity about
+another entity) in order to be cleared to make a purchase:
+            <ul>
+                <li>
+PharmCo will only sell regulated drugs to someone with proof
+of an active pharmacist's license.
+              </li>
+                <li>
+WineCo will only sell wine to someone with proof of being over the age of 21.
+              </li>
+                <li>
+BoomCo will only ship industrial explosives to a business that can
+provide evidence of construction permits, a contractor's license, and
+an explosives handling license.
+              </li>
+                <li>
+HomeLoanCo will not finalize a quote for a home mortgage without
+a credit score report and an audited finances report.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+There are certain types of  <a title="purchase" href="#dfn-purchase" class="internalDFN">purchases</a> that cannot
+be initiated without a proper set of credentials. While this isn't fundamental
+to the payment process, it is an integral part of some <a href="#dfn-transaction" class="internalDFN">transaction</a>
+processes.
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>It is important that people retain control over when
+	    and how their credentials are shared.</dd>
+          <dt>Regulatory</dt>
+          <dd>
+There are a large number of regulations covering the collection, storage, and
+usage of personally identifiable information. Any system designed to transmit
+or collect credentials must conform to all local and federal regulations
+related to identity and privacy.
+          </dd>
+          <dt>Exceptions</dt>
+          <dd>A <a href="#dfn-transaction" class="internalDFN">transaction</a> may fail if a required credential is not available.
+          </dd>
+        </dl>
+
+        <dl id="uc-privacy" class="dl-horizontal">
+          <dt>Privacy Protection</dt>
+          <dd>
+Tibor orders chocolates from CandyCo. CandyCo requests Tibor's
+tokenized shipping address to send him the candy. With Tibor's
+authorization, his payment software transmits a tokenized shipping address to
+BoomCo that the shipper can decipher. Tibor's privacy is protected from the
+candy store, which did not require any personally identifying information to
+complete the <a href="#dfn-transaction" class="internalDFN">transaction</a>.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Certain low-value <a href="#dfn-transaction" class="internalDFN">transaction</a>s shouldn't require the
+<a href="#dfn-payer" class="internalDFN">payer</a> to divulge personal information that is not necessary
+to complete the <a href="#dfn-transaction" class="internalDFN">transaction</a>.
+          </dd>
+          <dt>Privacy</dt>
+          <dd>
+Non-essential, personally identifiable data should be anonymized and
+protected throughout the process.
+          </dd>
+        </dl>
+
+        <dl id="uc-need-to-know" class="dl-horizontal">
+          <dt>Need to Know</dt>
+          <dd>
+PayCo, a payment processor, is required to keep a certain amount of
+information on their customers
+for anti-money laundering / know your customer regulatory purposes. When a
+<a href="#dfn-payer" class="internalDFN">payer</a> performs a <a href="#dfn-transaction" class="internalDFN">transaction</a> with a <a href="#dfn-payee" class="internalDFN">payee</a>, PayCo
+would like to reduce the amount of information that's transmitted to the
+<a href="#dfn-payee" class="internalDFN">payee</a> while ensuring that PayCo complies with regulations.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+There are types of information, such as personally identifiable information,
+that <a title="payee" href="#dfn-payee" class="internalDFN">payees</a> do not need to know for some
+transactions. Limiting sensitive information to be transmitted to entities
+involved in a payment on a purely need-to-know basis increases security
+while ensuring regulatory compliance.
+          </dd>
+        </dl>
+
+        <dl id="uc-invoices" class="dl-horizontal">
+          <dt>Invoices</dt>
+          <dd>
+There are a large variety of invoices that are used in the world:
+<ul>
+  <li>
+Sunan goes to SuperVoices to download a voiceover that he commissioned for
+his new pet sitting service. SuperVoices generates a detailed invoice for the
+service and provides it to Sunan.
+  </li>
+  <li>
+João is given an electronic
+<a href="https://en.wikipedia.org/wiki/Boleto">Boleto</a> by
+a technology website to pay for a new laptop.
+  </li>
+</ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+For certain <a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a>, the <a href="#dfn-payer" class="internalDFN">payer</a>
+will have to provide the payment service with a detailed digital invoice from
+the <a href="#dfn-payee" class="internalDFN">payee</a> in order to initiate payment to the <a href="#dfn-payee" class="internalDFN">payee</a>.
+          </dd>
+        </dl>
+
+        <dl id="uc-full-disclosure" class="dl-horizontal">
+          <dt>Full Disclosure</dt>
+          <dd>
+Marge wishes to renew her passport online which requires transmission
+of a fee and a great deal of information about her real-world identity.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Some <a href="#dfn-transaction" class="internalDFN">transaction</a>s will require very sensitive personally identifiable
+information to be transmitted by the <a href="#dfn-payer" class="internalDFN">payer</a>.
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>We must ensure adequate security for these highly sensitive
+      transactions to reduce the likelihood of phishing attacks.</dd>
+        </dl>
+
+    </section>
+
+      <section id="application-of-marketing-elements" typeof="bibo:Chapter" resource="#application-of-marketing-elements" property="bibo:hasPart">
+        <h4 id="h-application-of-marketing-elements" resource="#h-application-of-marketing-elements"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.1.3 </span>Application of Marketing Elements</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-coupons" class="dl-horizontal">
+          <dt>Coupons</dt>
+          <dd>
+JustPopcorn sends Marco a special discount offer given Marco's past
+<a title="purchase" href="#dfn-purchase" class="internalDFN">purchases</a>. The offer takes the form of a coupon that
+may be applied during payment.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Providing a mechanism to apply digital coupons before a payment is initiated
+helps price-conscious customers as well as merchants attempting to research
+price sensitivity.
+          </dd>
+        </dl>
+
+        <dl id="uc-loyalty" class="dl-horizontal">
+          <dt>Loyalty Cards</dt>
+          <dd>
+Terry uses his FoodCo loyalty card when purchasing his weekly groceries, which
+gives him a discount on gas  <a title="purchase" href="#dfn-purchase" class="internalDFN">purchases</a> performed at the
+FoodCo gas station.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Loyalty cards may be used at multiple locations to effect the price of a
+particular good.
+          </dd>
+        </dl>
+
+        <dl id="uc-store-credit" class="dl-horizontal">
+          <dt>Store Credit</dt>
+          <dd>
+When Fjörleif arrives as the self-checkout kiosk,
+she scans five dress shirts and two new pairs of dress pants.
+The kiosk mentions that Fjörleif could save 15% off of her <a href="#dfn-purchase" class="internalDFN">purchase</a>
+if she makes the <a href="#dfn-purchase" class="internalDFN">purchase</a> using store credit. She accepts the offer and
+a new store credit card is placed in her payment application on her mobile
+phone.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Merchants often provide discounts to customers if they sign up for a
+store-specific line of credit.
+          </dd>
+        </dl>
+
+      </section>
+
+    </section>
+
+    <section id="negotiation-of-payment-instruments-2" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-2" property="bibo:hasPart">
+      <h3 id="h-negotiation-of-payment-instruments-2" resource="#h-negotiation-of-payment-instruments-2"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2 </span>Negotiation of Payment Instruments</span></h3>
+      <p>
+      </p>
+
+
+      <section id="discovery-of-accepted-schemes" typeof="bibo:Chapter" resource="#discovery-of-accepted-schemes" property="bibo:hasPart">
+        <h4 id="h-discovery-of-accepted-schemes" resource="#h-discovery-of-accepted-schemes"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.1 </span>Discovery of Accepted Schemes</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-ubiquitous" class="dl-horizontal">
+          <dt>Ubiquitous Schemes</dt>
+          <dd>
+A game store Web site accepts payment via credit card, e-check, and
+operator billing.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+Ubiquitous <a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a> should be supported
+without changes to how the schemes or payment instruments operate.
+          </dd>
+          <dt>Regulatory</dt>
+          <dd>
+Often payment schemes have their own internal regulations as well as
+regulations at the local and federal level that cover the usage of the
+scheme.
+          </dd>
+        </dl>
+
+        <dl id="uc-emerging" class="dl-horizontal">
+          <dt>Emerging Schemes</dt>
+          <dd>
+CrowdFundCo supports Bitcoin, Ripple, Google Wallet, and PayPal.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+The same mechanism used to support existing
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a> should also
+support emerging <a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a>.
+          </dd>
+        </dl>
+
+      </section>
+
+      <section id="selection-of-payment-instruments" typeof="bibo:Chapter" resource="#selection-of-payment-instruments" property="bibo:hasPart">
+        <h4 id="h-selection-of-payment-instruments" resource="#h-selection-of-payment-instruments"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.2 </span>Selection of Payment Instruments</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-discovery" class="dl-horizontal">
+          <dt>Discovery</dt>
+          <dd>
+Yanos has a multiple digital wallets: one on his mobile phone, two in the
+cloud (but on different websites), and one on his smart watch. Each one has
+a credit card that he may want to use for a credit card-based <a href="#dfn-purchase" class="internalDFN">purchase</a>.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+A <a href="#dfn-payer" class="internalDFN">payer</a> will most likely use multiple digital wallets over time. It is
+important to ensure that the wallets that they use are presented to them in a
+consistent manner across devices.
+<span class="issue">The amount of wallet/payment instrument discovery
+flexibility that phase 1 should support is currently unknown.</span>
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+The consistent presentation of digital wallet interfaces also includes
+consistent accessibility hints that are exposed in an interoperable fashion so
+that devices that are accessability-aware can easily integrate with the
+transaction process.
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>
+Discovery of digital wallets must be done in such a way as to ensure
+privacy protection.
+          </dd>
+        </dl>
+
+        <dl id="uc-payer-privacy" class="dl-horizontal">
+          <dt>Payer Privacy</dt>
+          <dd>We anticipate a range of privacy scenarios:
+            <ul>
+                <li>
+Lucio sends information about instruments he is willing to use to
+TrustedMerchant, who provides a discount for access to his information.
+              </li>
+                <li>
+Carla does not want to share information about the
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a> she uses with any
+merchants, so that information is not shared with any online merchants.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+Sharing or protecting data on the sorts of
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a> available to
+a <a href="#dfn-payer" class="internalDFN">payer</a> should be a decision made by the <a href="#dfn-payer" class="internalDFN">payer</a>.
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>
+The types of <a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a> available
+to a <a href="#dfn-payer" class="internalDFN">payer</a> could be
+used to digitally fingerprint a <a href="#dfn-payer" class="internalDFN">payer</a> even if they were using an
+pseudo-anonymous payment mechanism. Merchants and <a href="#dfn-payee" class="internalDFN">payee</a>s may be legally
+obligated to protect this kind of <a href="#dfn-payer" class="internalDFN">payer</a> payment information.
+          </dd>
+        </dl>
+
+        <dl id="uc-manual-selection" class="dl-horizontal">
+          <dt>Manual Selection</dt>
+          <dd>In many cases, the <a href="#dfn-payer" class="internalDFN">payer</a> will select a payment instrument manually:
+            <ul>
+                <li>
+Marie has credit cards from three different institutions:
+one for work (from BankA), one personal card (from BankB), and one retail card
+(from PayCo). She wants to choose the right one depending on the context of her
+purchase.
+              </li>
+                <li>
+Claire has one debit card and multiple credit cards from the same bank.
+              </li>
+                <li>
+Veronique wants to use a cryptocurrency in some cases (e.g.,
+peer-to-peer payments).
+              </li>
+                <li>
+Seth participates in a loyalty program with his local grocery store and
+can apply a variety of digital coupons when he visits the store.
+<span class="issue">Is a loyalty card a payment instrument, or a credential?
+</span>
+              </li>
+                <li>
+David wants to be able to manually arrange available
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a> when they are presented
+to him. <span class="issue">Why does this need to be standardized?
+Isn't this just a part of the wallet UI?</span>
+              </li>
+              <li>
+Fergus wants to pay for a meal using two different payment instruments:
+cash and a company credit card. He'd like to pay $20.24 with the company
+credit card and provide a $5 tip with digital cash.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+There are scenarios, such as the first interaction/use of a payment instrument,
+where selection of the payment instrument won't be able to be performed
+automatically.
+          </dd>
+        </dl>
+
+        <dl id="uc-automatic-selection" class="dl-horizontal">
+          <dt>Automatic Selection</dt>
+          <dd>
+When a <a title="payer" href="#dfn-payer" class="internalDFN">payer's</a> personal preferences are known, it
+becomes possible to make selections for them automatically.
+
+            <ul>
+                <li>
+Jonny's payment software on his smart watch chooses the payment instrument that
+will provide him with the biggest cost savings for each <a href="#dfn-purchase" class="internalDFN">purchase</a> he makes
+throughout the week.
+              </li>
+                <li>
+PayCo wants Elizabeth to know that if she pays with the debit card preferred
+by PayCo (because of a lower <a href="#dfn-transaction" class="internalDFN">transaction</a> fee for PayCo),
+she will benefit from a discount.
+              </li>
+                <li>
+Whenever Mary shops at BigFreshGrocery she uses the same credit card.
+She wants payment to happen automatically with that card when she puts her
+phone near the checkout terminal as well as when purchasing groceries online
+from BigFreshGrocery.
+              </li>
+                <li>
+Lalana does not like to scroll. She wants the instruments she uses most
+often to appear at top of the displayed list of available payment instruments.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Payment solutions providers can make payments easier and faster through automation.
+          </dd>
+        </dl>
+
+      </section>
+
+      <section id="authentication-to-access-instruments" typeof="bibo:Chapter" resource="#authentication-to-access-instruments" property="bibo:hasPart">
+        <h4 id="h-authentication-to-access-instruments" resource="#h-authentication-to-access-instruments"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.3 </span>Authentication to Access Instruments</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-password" class="dl-horizontal">
+          <dt>Password Auth</dt>
+          <dd>
+When Suresh attempts to pay online, he is asked for a username and password
+by his payment service provider before the payment is approved.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+The most common mechanism for protecting access to payment instruments on the
+Web in 2015 is the use of a username and password.
+          </dd>
+        </dl>
+
+        <dl id="uc-multifactor" class="dl-horizontal">
+          <dt>Multi-Factor</dt>
+          <dd>
+We anticipate a range of authentication scenarios, leveraging a wide variety
+of approaches and device capabilities:
+            <ul>
+              <li>
+When Ian selects his debit card, he is prompted for a PIN.
+              </li>
+              <li>
+Horace presses the biometric fingerprint reader on his phone to authorize a
+purchase.
+              </li>
+              <li>
+An authentication code is sent to Tony's mobile phone as a text message
+to ensure that he is the one that initiated the payment. Once he enters the
+authentication code, the payment proceeds.
+              </li>
+              <li>
+Wes has configured his debit card to require a fingerprint scan from his
+mobile device and a Universal Two Factor (U2F) device to be used when
+performing a <a href="#dfn-purchase" class="internalDFN">purchase</a> over $1,000.
+              </li>
+              <li>
+Frederic taps his phone at the grocery store to pay, and BankA sends him a
+one-time password (OTP) on his mobile phone that he enters using a keypad at
+the checkout counter.
+              </li>
+              <li>
+Nadia's bank asks her to use her two-factor authentication device and at
+least one of their in-branch retinal scanners or palm-vein readers
+before she is allowed to withdraw $25,000.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>The payments architecture should support
+	    the authentication devices available today for
+multi-factor authentication, as well as those of the future.
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+Not everyone can provide fingerprints or detailed iris scans. Therefore, it
+is important to offer multiple forms of biometric verification to improve
+accessibility in addition to providing alternatives to biometric verification,
+such as strong two-factor verification.
+          </dd>
+        </dl>
+
+        <dl id="uc-kyc" class="dl-horizontal">
+          <dt>KYC</dt>
+          <dd>
+A number of Know Your Customer (KYC) requirements must be met when a financial
+service provider authorizes access to a particular <a href="#dfn-payment-instrument" class="internalDFN">payment instrument</a>:
+            <ul>
+              <li>
+BigBank performs KYC clearing on a continuous basis to ensure that their
+customers are properly vetted before participating in financial transactions.
+              </li>
+              <li>
+Multigen, a wealth management company, must ensure that their customer's
+are accredited investors before allowing them to directly manage certain
+investments in their account.
+              </li>
+              <li>
+The Central Bank of Pakistan enables independent mobile resellers to
+perform minimal thumbprint-based KYC clearing in remote regions of the
+country.
+              </li>
+              <li>
+Pharmaxis, a medical drug reseller, requires that a customer is licensed to
+practice medicine and write prescriptions for Class 2 medications (highly
+addictive drugs with a known medical use) before a purchase is allowed to
+proceed.
+              </li>
+              <li>
+Dr. Kubo provides a set of explosives expert KYC credentials at the time of
+transaction to meet transaction requirements managed by the financial
+institution and merchant.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Authorization to access an instrument depends on more than just authenticating
+with the payment service provider, it may also require the <a href="#dfn-payee" class="internalDFN">payee</a> to
+have other provable qualities before the transaction can proceed.
+          </dd>
+          <dt>Regulation</dt>
+          <dd>
+In many countries, a variety of regulations exist that require merchants and
+financial service providers to prove that they have vetted their customers
+before allowing a transaction to proceed.
+          </dd>
+        </dl>
+
+        <dl id="uc-" class="dl-horizontal">
+          <dt>AML</dt>
+          <dd>
+Financial service providers, and some merchants, are required to adhere to
+Anti-Money Laundering (AML) regulations by blocking transactions involving
+known bad actors or by reporting suspicious activity related to financial
+transactions:
+            <ul>
+              <li>
+Corresponda Bank's AML system notices an outgoing payment to an account listed
+as frozen by FinCEN and prevents the payment from proceeding.
+              </li>
+              <li>
+FasterPay, a payment service provider, notices tens of thousands of small
+transactions flowing from high-risk foreign accounts into a previously dormant
+domestic account and automatically files a Suspicious Activity Report.
+              </li>
+              <li>
+Eastern Group, an international remittance system, verifies that both the
+sender and a recipient of an international remittance are not on a watch
+list and have known accounts at the source and destination of funds
+before authorizing the transaction.
+              </li>
+              <li>
+The Flamingo, a casino, automatically files a Currency Transaction Report
+when one of its systems detects a customer withdrawing over $10,000 USD
+in winnings over the course of a day.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Financial service providers, and some merchants, are required to adhere to
+Anti-Money Laundering (AML) regulations by reporting suspicious activity
+related to financial transactions or by blocking transactions involving
+known bad actors.
+          </dd>
+          <dt>Exceptions</dt>
+          <dd>
+If a <a href="#dfn-payee" class="internalDFN">payee</a> detects that a <a href="#dfn-payer" class="internalDFN">payer</a> is on an applicable blacklist, the
+transaction must not proceed.
+          </dd>
+        </dl>
+
+          <dl id="uc-biometric" class="dl-horizontal">
+            <dt>Biometric</dt>
+            <dd>
+In current online and offline payment <a href="#dfn-transaction" class="internalDFN">transaction</a>s, biometric
+authentication can be used instead of password-based authentication:
+              <ul>
+                  <li>
+John registers his fingerprint with his payment provider so that he can
+just use a fingerprint to pay for low-value items.
+                </li>
+                  <li>
+Ruba registers her voiceprint and face with her payment provider for use
+in <a href="#dfn-transaction" class="internalDFN">transaction</a>s greater than $1,000.
+                </li>
+                  <li>
+Rico buys a $5,000 car for his daughter through an online dealership. His
+<a href="#dfn-payment-processor" class="internalDFN">payment processor</a> requires a password plus two forms of biometric
+identification. Rico doesn't have hands, so he uses a face and iris scan to
+perform the authentication.
+                </li>
+              </ul>
+            </dd>
+            <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+            <dt>Motivation</dt>
+            <dd>
+Biometrics can be utilized on point of sale terminals, mobile, and wearable
+devices. Web payment systems based on biometrics could achieve more reliable
+information security and convenience. Some forms of biometric authentication,
+like facial recognition, can also be used to augment password-based
+authentication mechanisms.
+            </dd>
+            <dt>Security / Privacy</dt>
+            <dd>
+              <ul>
+                  <li>
+An individual's privacy should be protected when performing any sort of
+biometric authentication.
+                </li>
+                  <li>
+Important data, such as the fingerprint template and private key, and
+sensitive code should be stored and executed in a Trusted Execution
+Environment (TEE).
+                </li>
+                  <li>
+The fingerprint authentication protocol, which is capable of transmitting a
+proof of fingerprint authentication credential, should not contain any
+personal fingerprint data.
+                </li>
+              </ul>
+            </dd>
+            <dt>Accessibility</dt>
+          <dd>
+Not everyone can provide fingerprints or detailed iris scans. Therefore, it
+is important to offer multiple forms of biometric verification to improve
+accessibility in addition to providing alternatives to biometric verification,
+such as strong two-factor verification.
+          </dd>
+          </dl>
+
+        <dl id="uc-risk-monitoring" class="dl-horizontal">
+          <dt>Risk Monitoring</dt>
+          <dd>
+Gao's payment processor service continuously monitor's his daily spending limit,
+daily withdrawal limit, and typical spending behavior and alerts him when a
+suspicious payment has been requested.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+As financial services have moved online, the number of Internet-based attacks
+on <a href="#dfn-payer" class="internalDFN">payer</a> financial accounts have increased. One way to protect against
+these sorts of attacks is to perform continous risk monitoring.
+          </dd>
+        </dl>
+
+        <dl id="uc-joint" class="dl-horizontal">
+          <dt>Joint Accounts</dt>
+          <dd>
+ArcheryCorp's manufacturing division has a joint expense account that is
+shared among multiple employees to make purchases. The account is protected
+by an access control list as well as limits on the amount that each
+employee can spend without authorization by management.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+There are many types of accounts that are accessed via different payment
+instruments that can be shared in an organization. Access to the accounts
+are typically protected by one or more sets of authorization rules.
+          </dd>
+        </dl>
+      </section>
+
+    </section>
+
+    <section id="payment-processing-2" typeof="bibo:Chapter" resource="#payment-processing-2" property="bibo:hasPart">
+      <h3 id="h-payment-processing-2" resource="#h-payment-processing-2"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.3 </span>Payment Processing</span></h3>
+      <p>
+      </p>
+
+      <section id="initiation-of-processing" typeof="bibo:Chapter" resource="#initiation-of-processing" property="bibo:hasPart">
+        <h4 id="h-initiation-of-processing" resource="#h-initiation-of-processing"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.3.1 </span>Initiation of Processing</span></h4>
+        <p>
+        </p>
+
+        <div class="note"><div class="note-title" aria-level="5" role="heading" id="h-note2"><span>Note</span></div><p class="">
+Before subjecting a person or organization to any financial <a href="#dfn-transaction" class="internalDFN">transaction</a>
+commitment (such as a web payment), they should be presented with the option
+of reversing, checking, or confirming their choice or submission. It should
+also be noted that this does not preclude certain <a href="#dfn-transaction" class="internalDFN">transaction</a> operations
+from being automated once they have been authorized by an <a href="#dfn-entity" class="internalDFN">entity</a>.
+For more details, see the section on
+<a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#minimize-error-reversible">Error Prevention (Legal, Financial, Data)</a>
+in [<cite><a class="bibref" href="#bib-WCAG20">WCAG20</a></cite>].
+        </p></div>
+
+        <dl id="uc-payee-initiated" class="dl-horizontal">
+          <dt>Payee-initiated</dt>
+          <dd>Some payments are initiated by the payee:
+            <ul>
+                <li>
+Richard choses to pay using a credit card at FlowerFriends. FlowerFriends
+initiates payment processing using their <a href="#dfn-payment-processor" class="internalDFN">payment processor</a> to contact the
+acquiring bank that handles credit card payments for FlowerFriends.
+              </li>
+                <li>
+Pitir has authorized RentSeekers to pull money out of his bank account on a
+monthly basis in order to pay his rent. RentSeekers initiates a payment using
+the ACH network to pull money from Pitir's bank account.
+              </li>
+              <li>
+Fiona shows a QR Code, which contains her payment details, to a cashier when
+she is checking out. The cashier scans the QR Code and initiates a payment
+using the details in the QR Code.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+Payee-initiated payments, also known as "pull payments" or
+"four corner model payments", are widely deployed and utilized today.
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>
+One of the biggest security flaws of <a href="#dfn-payee" class="internalDFN">payee</a>-initiated payments is that
+all the information necessary to initiate a <a href="#dfn-transaction" class="internalDFN">transaction</a> from the
+<a title="payer" href="#dfn-payer" class="internalDFN">payer's</a> financial account is typically transmitted
+to the <a href="#dfn-payee" class="internalDFN">payee</a>. For example, credit card information along with
+expiration date, name, and CVV2 code are transmitted and could be intercepted
+by rogue software running on the <a title="payer" href="#dfn-payer" class="internalDFN">payer's</a> servers.
+Special attention should be paid to ensuring that this risky security
+model isn't supported by a Web Payments solution. For example, at a minimum,
+credit card tokenization such as EMVCo's solution should be supported
+alongside other tokenization solutions.
+          </dd>
+        </dl>
+
+        <dl id="uc-payer-initiated" class="dl-horizontal">
+          <dt>Payer-initiated</dt>
+          <dd>Some payments are initiated by the payer:
+            <ul>
+                <li>
+Once Sally has signed into PayPal to pay, PayPal initiates payment processing.
+              </li>
+                <li>
+Joakim uses his Bitcoin wallet to send money to his friend.
+              </li>
+                <li>
+Carson (in New York City) sends money to Vladimir (in Moscow) using
+his Ripple client, which converts the currency from US Dollars to Rubels in
+transit.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+Payer-initiated payments, also known as "push payments",
+"three corner model payments", or "peer-to-peer payments", are fundamentally
+more secure as no information is given to the <a href="#dfn-payee" class="internalDFN">payee</a> that would
+allow them or an attacker to replay the <a href="#dfn-transaction" class="internalDFN">transaction</a> for a different
+amount or to a different <a href="#dfn-payee" class="internalDFN">payee</a> at a later date.
+          </dd>
+          <dt>Regulatory</dt>
+          <dd>
+There are a number of regulations that cover the protection of confidential
+customer data both from a payment scheme perspective as well as a federal
+level.
+          </dd>
+        </dl>
+
+      </section>
+
+      <section id="verification-of-available-funds" typeof="bibo:Chapter" resource="#verification-of-available-funds" property="bibo:hasPart">
+        <h4 id="h-verification-of-available-funds" resource="#h-verification-of-available-funds"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.3.2 </span>Verification of Available Funds</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-hold-verification" class="dl-horizontal">
+          <dt>Hold Verification</dt>
+          <dd>
+Renne checks into a hotel and is asked for a deposit for any damages to the
+room. She uses her phone to provide a proof-of-hold until she checks out of
+the hotel, at which time the hold on her funds will be released.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+Delivering services or products that are difficult to "undo," such
+as performing an oil change, dispensing fuel, or renting a car or hotel
+room are examples of situations which may require a two-part
+<a href="#dfn-transaction" class="internalDFN">transaction</a>.
+          </dd>
+        </dl>
+
+        <dl id="uc-funds-verification" class="dl-horizontal">
+          <dt>Funds Verification</dt>
+          <dd>
+When Mario wishes to <a href="#dfn-purchase" class="internalDFN">purchase</a> a race car through the manufacturer,
+the company that makes the car requires a proof of funds from Mario's bank
+in order for the customization of the car to proceed.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+A <a href="#dfn-payee" class="internalDFN">payee</a> may want to limit access to certain services to only those
+who they know can afford the good or service because the act of
+providing an acceptable level of service to the <a href="#dfn-payee" class="internalDFN">payee</a> during the
+pre-sale phase may be costly.
+          </dd>
+        </dl>
+
+      </section>
+
+      <section id="authorization-of-transfer" typeof="bibo:Chapter" resource="#authorization-of-transfer" property="bibo:hasPart">
+        <h4 id="h-authorization-of-transfer" resource="#h-authorization-of-transfer"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.3.3 </span>Authorization of Transfer</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-proofs" class="dl-horizontal">
+          <dt>Proofs</dt>
+          <dd>
+Goods and services may be released at different times depending on the type of
+<a href="#dfn-transaction" class="internalDFN">transaction</a> being performed:
+            <ul>
+                <li>
+Sung-hyun provides a proof of initiation of funds transfer to get access to
+an online streaming music service.
+              </li>
+                <li>
+Zhang Wei orders 10 large boxes of envelopes from an online shop in
+Tianjin. He uses an escrow service to provide a proof of escrow to the
+online shop in order to get them to initiate the shipment.
+              </li>
+                <li>
+To protect Tibor's privacy when he <a title="purchase" href="#dfn-purchase" class="internalDFN">purchases</a> candy
+online, the store asks only for Tibor's verified shipping address and a
+proof of payment to send him the chocolates.
+              </li>
+                <li>
+RockinRadio, SmoothSounds, and classicallyClassic are independent, specialized
+music streaming services. They accept proof of <a href="#dfn-purchase" class="internalDFN">purchase</a> from each other
+to provide a track that is in their online streaming catalogue even if it was
+originally bought from another provider.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+At times, it is safe to release a good
+when the payment network acknowledges that the funds are on their way. At other
+times, it's not safe to release a good or service until it has been proven that
+the funds are sitting in the <a title="payee" href="#dfn-payee" class="internalDFN">payee's</a> financial
+account.
+          </dd>
+          <dt>Exceptions</dt>
+          <dd>
+If a particular expected proof is not provided, the <a href="#dfn-transaction" class="internalDFN">transaction</a> will most
+likely fail or transition into an alternate path.
+          </dd>
+        </dl>
+
+      </section>
+
+      <section id="completion-of-transfer" typeof="bibo:Chapter" resource="#completion-of-transfer" property="bibo:hasPart">
+        <h4 id="h-completion-of-transfer" resource="#h-completion-of-transfer"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.3.4 </span>Completion of Transfer</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-delay-variation" class="dl-horizontal">
+          <dt>Variation of Delay</dt>
+          <dd>When a <a href="#dfn-transaction" class="internalDFN">transaction</a> occurs, the time it takes to transmit and receive
+funds often vary according to the <a href="#dfn-payment-scheme" class="internalDFN">payment scheme</a>:
+            <ul>
+                <li>
+Eman uses a credit card to buy some gifts for her parents. The shop has
+access to the funds in three days.
+              </li>
+                <li>
+Frank uses an electronic check to pay his rent. The rental agency has access
+to the funds in 7 days.
+              </li>
+                <li>
+Felicity has chosen Bitcoin to pay for glasses online. The store
+that sells the glasses has almost guaranteed access to the funds within
+15 minutes.
+              </li>
+                <li>
+Vanessa uses Ripple to <a href="#dfn-purchase" class="internalDFN">purchase</a> a new work outfit in US Dollars.
+Funds in Euros are available to OnlineWorkClothes within a few minutes.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Exceptions</dt>
+          <dd>
+If the funds are sent but never received, then the <a href="#dfn-payee" class="internalDFN">payee</a> will
+select a recourse mechanism that is included in the last <a href="#dfn-transaction" class="internalDFN">transaction</a>
+message.
+          </dd>
+        </dl>
+
+        <dl id="uc-escrow" class="dl-horizontal">
+          <dt>Escrow</dt>
+          <dd>
+There are a number of considerations when providing escrow services to both
+<a title="payer" href="#dfn-payer" class="internalDFN">payers</a> and <a title="payee" href="#dfn-payee" class="internalDFN">payees</a>:
+            <ul>
+              <li>
+Jack has established an online store on a trusted third party website to
+sell pants. Mary wants to buy a pair of pants from Jack's online store.
+Mary doesn't trust Jack because she has never met him nor has she done
+business with him before. Jack doesn't trust Mary because he doesn't know
+if he will be paid after shipping the pants to Mary. Mary makes a purchase,
+selecting to put her money in escrow at the trusted third party. Jack is
+notified that the funds have been received by the trusted third party.
+Jack sends the pants to Mary via Express Mail. When Mary gets the pants,
+she will tell the trusted third party and they will move the funds
+to Jack's account.
+              </li>
+              <li>
+Escrow services in China sometimes provide a virtual financial account to
+<a title="payer" href="#dfn-payer" class="internalDFN">payers</a>. Money is typically transferred from the
+<a title="payer" href="#dfn-payer" class="internalDFN">payer's</a> bank account to the escrow service provider's
+bank to hold, but where the funds are still legally owned by the <a href="#dfn-payer" class="internalDFN">payer</a>.
+When Hung transfers funds to an escrow service provider, his
+rights and responsibilities are exchanged with the escrow service provider
+at the same time as well as how various parties involved with the account
+can access and use the funds.
+              </li>
+            </ul>
+
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+A trusted third party is typically helpful for non-instant transactions
+where neither the <a href="#dfn-payer" class="internalDFN">payer</a> or the <a href="#dfn-payee" class="internalDFN">payee</a> have an existing
+relationship. A trusted third party protects the <a href="#dfn-payer" class="internalDFN">payer</a> by ensuring that
+the <a href="#dfn-payee" class="internalDFN">payee</a> has been vetted and by guaranteeing product or a refund. The
+trusted third party protects the <a href="#dfn-payee" class="internalDFN">payee</a> by ensuring that funds from the
+<a href="#dfn-payer" class="internalDFN">payer</a> have been verified before releasing the product to them.
+          </dd>
+          <dt>Regulatory</dt>
+          <dd>
+The use of money held in escrow accounts by the escrow service provider is
+covered by a number of consumer protection laws that restrict what the
+escrow service provider can do with the money. Expressing these restrictions
+in a way that enhances interoperability is desirable.
+          </dd>
+        </dl>
+
+        <dl id="uc-notifications" class="dl-horizontal">
+          <dt>Notifications</dt>
+          <dd>
+Gavin sends an electronic check to WaveMart. WaveMart receives a notification
+that payment has been initiated almost immediately. Four days later, WaveMart
+receives a notification from their bank that payment has been received.
+          </dd>
+          <dt>Roadmap phase</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+It is difficult for an organization to know when a payment has been received
+without depending on proprietary software.
+          </dd>
+          <dt>Exceptions</dt>
+          <dd>
+It may also be important to be notified when a payment that was initiated
+has not been received, or when a payment has been reversed after it had been
+received.
+          </dd>
+        </dl>
+
+      </section>
+
+    </section>
+
+    <section id="delivery-of-product-receipt-and-refunds-2" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-2" property="bibo:hasPart">
+      <h3 id="h-delivery-of-product-receipt-and-refunds-2" resource="#h-delivery-of-product-receipt-and-refunds-2"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.4 </span>Delivery of Product/Receipt and Refunds</span></h3>
+      <section id="delivery-of-product" typeof="bibo:Chapter" resource="#delivery-of-product" property="bibo:hasPart">
+        <h4 id="h-delivery-of-product" resource="#h-delivery-of-product"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.4.1 </span>Delivery of Product</span></h4>
+        <p>
+        </p>
+
+        <dl id="uc-physical-goods" class="dl-horizontal">
+          <dt>Physical Goods</dt>
+          <dd>
+Giralt orders a bicycle for his daughter through BikeSmart online and has it
+shipped to his home address.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+The <a href="#dfn-purchase" class="internalDFN">purchase</a> and delivery of physical goods via an online marketplace
+is one of the cornerstones of online commerce.
+          </dd>
+        </dl>
+
+        <dl id="uc-virtual-goods" class="dl-horizontal">
+          <dt>Virtual Goods</dt>
+          <dd>
+When Lilith buys music from a band at MusicBox and then goes to their
+Web site to download additional content, no registration is required, just a
+proof of <a href="#dfn-purchase" class="internalDFN">purchase</a> that is sent to the band's website, after which
+MusicBox provides Lilith a link to download the additional content.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1</dd>
+          <dt>Motivation</dt>
+          <dd>
+Delivery of product can happen on any site that accepts a proof of purchase
+that contains a recognized product identifier.
+          </dd>
+        </dl>
+
+        <dl id="uc-dropshipping" class="dl-horizontal">
+          <dt>Dropshipping</dt>
+          <dd>
+Takeru orders a new backpack online and has it shipped to a nearby department
+store for pickup.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+It is common in Japan and the United Kingdom to purchase items online and then
+have them shipped to a nearby department store to save on shipping.
+          </dd>
+        </dl>
+
+      </section>
+
+      <section id="delivery-of-receipt" typeof="bibo:Chapter" resource="#delivery-of-receipt" property="bibo:hasPart">
+        <h4 id="h-delivery-of-receipt" resource="#h-delivery-of-receipt"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.4.2 </span>Delivery of Receipt</span></h4>
+        <dl id="uc-electronic-receipts" class="dl-horizontal">
+          <dt>Electronic Receipts</dt>
+          <dd>
+Ashraf pulls up to a pump at a petrol station. He pays electronically using a
+credit card (via his phone). A machine-readable electronic receipt for
+the <a href="#dfn-purchase" class="internalDFN">purchase</a> from the gas station is transferred to his phone and
+displayed using his favorite expense tracking software.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1 (very basic receipt container and delivery protocol)</dd>
+          <dt>Motivation</dt>
+          <dd>
+Standardized, machine-readable electronic receipts make it easier to
+track expenses, prove that certain <a title="purchase" href="#dfn-purchase" class="internalDFN">purchases</a> were
+made, file tax returns, and simplify management of unnecessary paper.
+          </dd>
+          <dt>Privacy</dt>
+          <dd>
+Many merchants want to ensure that receipts are not readable by any party
+between them and their customer.
+          </dd>
+          <dt>Security</dt>
+          <dd>
+Electronic receipts should be tamperproof such that the information can be
+verified to have come from the merchant issuing the receipt. One mechanism
+that could be employed would be the use of digital signatures over the
+contents of the electronic receipt.
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+Protecting digital receipts may have the unintended consequence of degrading
+or preventing their use with accessibility technology. It is important that
+protection measures do not prevent accessibility technology from reading
+pertinent information about the transaction.
+          </dd>
+        </dl>
+
+        <dl id="uc-physical-receipts" class="dl-horizontal">
+          <dt>Physical Receipts</dt>
+          <dd>
+Bongani reserves a bus ticket online using his mobile phone. At the bus
+terminal he taps his phone to a kiosk and receives a printed physical receipt
+that he can use on the bus.
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+There will be a transition period from the use of physical receipts and
+tickets to digital receipts. In some cases, physical receipts may never be
+replaced, so it is important to ensure that digital receipts have a mechanism
+to be transformed to physical receipts.
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>
+Physical receipts should ensure that private information is not exposed on
+the receipt.
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+Implementations should ensure that people who have visual disabilities have
+options such as Braille output for physical receipts alongside high-contrast /
+large print lettering.
+          </dd>
+        </dl>
+
+      </section>
+      <section id="refunds" typeof="bibo:Chapter" resource="#refunds" property="bibo:hasPart">
+        <h4 id="h-refunds" resource="#h-refunds"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.4.3 </span>Refunds</span></h4>
+        <dl id="uc-refund" class="dl-horizontal">
+          <dt>Basic Refund</dt>
+          <dd>
+At times, it becomes necessary to refund a <a title="payer" href="#dfn-payer" class="internalDFN">payer's</a>
+payment:
+            <ul>
+              <li>
+Pele buys a slice of pizza with a credit card at a local restaurant
+and is accidentally charged for five slices of pizza. He notices the
+mistake after he pays and requests a refund, which the restaurant
+manager approves. The overcharged funds are returned to his account.
+              </li>
+              <li>
+Teo claims that a blender he purchased online was faulty and returns
+the product to the merchant. The merchant provides the customer with a refund
+in the form of store credit based on the return policy.
+              </li>
+              <li>
+<span class="issue">Should we include a scenario where the refund is to a
+different payment scheme, e.g., cash?</span>
+              </li>
+              <li>
+A financial crimes regulator identifies a criminal syndicate that is
+operating via a number of fake identities. The fake identities are flagged
+and an electronic message is sent to all
+<a title="payment processor" href="#dfn-payment-processor" class="internalDFN">payment processors</a> to reverse all
+payments sent to the fake identities.
+              </li>
+            </ul>
+          </dd>
+          <dt>Roadmap phase</dt>
+          <dd>1 (if time permits)</dd>
+          <dt>Motivation</dt>
+          <dd>
+Some <a href="#dfn-transaction" class="internalDFN">transaction</a>s are the result of human error or fault. In these
+cases, it is helpful to be able to reverse the <a href="#dfn-transaction" class="internalDFN">transaction</a> and provide
+a refund to the customer.
+          </dd>
+          <dt>Regulatory</dt>
+          <dd>
+Consumer protection laws and regulations affect the ways a customer can
+request a refund for a defective product or service.
+          </dd>
+        </dl>
+
+      </section>
+
+    </section>
+  </section>
+
+  <section id="additional-examples-of-the-payment-phases" typeof="bibo:Chapter" resource="#additional-examples-of-the-payment-phases" property="bibo:hasPart">
+    <!--OddPage--><h2 id="additional-examples" resource="#additional-examples"><span property="xhv:role" resource="xhv:heading"><span class="secno">7. </span>Additional Examples of the Payment Phases</span></h2>
+    <p>
+Early in the document we provide an
+<a href="#a-simple-example-of-the-payment-phases">example of the payment
+phases</a>. In this appendix we provide further examples to
+illustrate the phase steps.
+    </p>
+
+    <div class="issue"><div class="issue-title" aria-level="3" role="heading" id="h-issue5"><span>Issue 5</span></div><p class="">
+Input is requested from experts at each organization providing services
+mentioned below as well as engineers and designers of technologies used below.
+Specifically, if the payment flows outlined below contain errors or omissions
+the group would like to be to ensure that the oversight is corrected as soon
+as possible.
+    </p></div>
+
+    <section id="credit-card-payment-visa-mastercard" typeof="bibo:Chapter" resource="#credit-card-payment-visa-mastercard" property="bibo:hasPart">
+      <h3 id="h-credit-card-payment-visa-mastercard" resource="#h-credit-card-payment-visa-mastercard"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.1 </span>Credit Card Payment (Visa, MasterCard)</span></h3>
+      <p>
+This scenario outlines a typical card purchase using the "four corner model".
+Janet is buying an handbag online from a resale shop.
+      </p>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-purchase-terms-1" property="bibo:hasPart">
+        <h4 id="negotiation-of-purchase-terms-1" resource="#negotiation-of-purchase-terms-1"><span property="xhv:role" resource="xhv:heading">Negotiation of Purchase Terms</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Offer</strong>: Janet searches her favorite resale shop
+online to discover a gently used purse that she has always wanted.
+          </li>
+          <li>
+<strong>Agreement on Terms</strong>: Janet selects the purse and puts it into
+the shopping cart before others have a chance to buy it. She agrees with the
+shipping terms and adds an extended warranty for the product.
+          </li>
+          <li>
+<strong>Application of Marketing Elements</strong>: At the time of reviewing
+the shopping cart, she is asked if she would like the scarf which goes with
+the purse.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-3" property="bibo:hasPart">
+        <h4 id="negotiation-of-payment-instruments-3" resource="#negotiation-of-payment-instruments-3"><span property="xhv:role" resource="xhv:heading">Negotiation of Payment Instruments</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Accepted Schemes</strong>: The site takes
+Discover, MasterCard, Visa, and debit cards along with secured money order,
+Bitcoin, Google Wallet, and ApplePay.
+          </li>
+
+          <li>
+<strong>Selection of Payment Instruments</strong>: Janet selects her Discover
+rewards credit card that is highlighted by default because she had used
+it for a previous purchase with the merchant.
+          </li>
+
+          <li>
+<strong>Authentication to Access Instruments</strong>: The merchant asks Janet
+for her zip code and the verification code on the back of the card.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#payment-processing-3" property="bibo:hasPart">
+        <h4 id="payment-processing-3" resource="#payment-processing-3"><span property="xhv:role" resource="xhv:heading">Payment Processing</span></h4>
+        <ul>
+          <li>
+<strong>Initiation of Processing</strong>: The merchant initiates an
+payment authorization request to their <a href="#dfn-payment-processor" class="internalDFN">payment processor</a>.
+          </li>
+          <li>
+<strong>Verification of Available Funds</strong>: The payment authorization
+request is successful and the <a href="#dfn-payment-processor" class="internalDFN">payment processor</a> sends a response to the
+merchant acknowledging that the funds are now held until the merchant
+finalizes the payment.
+          </li>
+          <li>
+<strong>Authorization of Transfer</strong>: After the merchant has packed
+the bag for shipping, the merchant sends a message back to the
+<a href="#dfn-payment-processor" class="internalDFN">payment processor</a> to finalize the payment.
+          </li>
+          <li>
+<strong>Completion of Transfer</strong>: The funds are immediately deducted from
+Janet's line of credit. The funds take 3 days to be transferred to the
+merchant's bank account.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-3" property="bibo:hasPart">
+        <h4 id="delivery-of-product-receipt-and-refunds-3" resource="#delivery-of-product-receipt-and-refunds-3"><span property="xhv:role" resource="xhv:heading">Delivery of Product/Receipt and Refunds</span></h4>
+        <ul>
+          <li>
+<strong>Delivery of Receipt</strong>: The seller sends her a digital receipt,
+which she receives by email and directly to her digital wallet. Her
+digital wallet forwards the receipt to her budgeting software. The digital
+wallet forwards the tracking number embedded in the digital receipt to
+her MyUPS Shipping Tracker mobile application.
+          </li>
+
+          <li>
+<strong>Delivery of Product</strong>: The merchant's shipping department packs
+and delivers the bag to the shipper, which then sends it to Janet.
+          </li>
+        </ul>
+      </section>
+    </section>
+
+    <section id="tokenized-payments-applepay-venmo-cybersource" typeof="bibo:Chapter" resource="#tokenized-payments-applepay-venmo-cybersource" property="bibo:hasPart">
+      <h3 id="h-tokenized-payments-applepay-venmo-cybersource" resource="#h-tokenized-payments-applepay-venmo-cybersource"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.2 </span>Tokenized Payments (ApplePay / Venmo / CyberSource)</span></h3>
+      <p>
+The following scenario outlines payment using a mobile device and
+tokenization. The merchant has provided a mobile application that
+customers can download in the example below. This example may apply to
+various tokenization payment systems now in use, such as ApplePay,
+CyberSource, Venmo, and Square.
+      </p>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-purchase-terms-2" property="bibo:hasPart">
+        <h4 id="negotiation-of-purchase-terms-2" resource="#negotiation-of-purchase-terms-2"><span property="xhv:role" resource="xhv:heading">Negotiation of Purchase Terms</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Offer</strong>: Tom uses the Terrific-Tools mobile
+app to select a new ax to purchase and finds a hickory handled model like the
+one his father had.
+          </li>
+
+          <li>
+<strong>Agreement on Terms</strong>: Tom selects the ax, which is in the
+price range he wanted.
+          </li>
+
+          <li>
+<strong>Application of Marketing Elements</strong>: <em>Not applicable to
+this particular use case.</em>
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-4" property="bibo:hasPart">
+        <h4 id="negotiation-of-payment-instruments-4" resource="#negotiation-of-payment-instruments-4"><span property="xhv:role" resource="xhv:heading">Negotiation of Payment Instruments</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Accepted Schemes</strong>: The mobile app uses
+tokenized <a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">payment instruments</a> and the
+Terrific-Tools Application displays the options available.
+          </li>
+
+          <li>
+<strong>Selection of Payment Instruments</strong>: Tom chooses to pay
+with his tokenization-enabled MasterCard.
+          </li>
+
+          <li>
+<strong>Authentication to Access Instruments</strong>: Tom uses the
+fingerprint recognition feature of his device to authenticate his payment.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#payment-processing-4" property="bibo:hasPart">
+        <h4 id="payment-processing-4" resource="#payment-processing-4"><span property="xhv:role" resource="xhv:heading">Payment Processing</span></h4>
+        <ul>
+          <li>
+<strong>Initiation of Processing</strong>: The mobile app creates an
+encrypted transaction and sends it to the payment processor. The payment
+processor decrypts the information and processes the transaction.
+          </li>
+          <li>
+<strong>Verification of Available Funds</strong>: <em>Not applicable to
+this particular use case.</em>
+          </li>
+          <li>
+<strong>Authorization of Transfer</strong>: The payment processor
+responds back to the mobile app with an approval.
+          </li>
+          <li>
+<strong>Completion of Transfer</strong>: The payment processor sends a
+transaction receipt to Terrific-Tools.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-4" property="bibo:hasPart">
+        <h4 id="delivery-of-product-receipt-and-refunds-4" resource="#delivery-of-product-receipt-and-refunds-4"><span property="xhv:role" resource="xhv:heading">Delivery of Product/Receipt and Refunds</span></h4>
+        <ul>
+          <li>
+<strong>Delivery of Receipt</strong>: Terrific-Tools sends a transaction
+receipt to the mobile app.
+          </li>
+
+          <li>
+<strong>Delivery of Product</strong>: Terrific-Tools ships the ax to Tom.
+          </li>
+        </ul>
+      </section>
+    </section>
+
+    <section id="three-corner-model-payments-paypal-alipay-google-wallet" typeof="bibo:Chapter" resource="#three-corner-model-payments-paypal-alipay-google-wallet" property="bibo:hasPart">
+      <h3 id="h-three-corner-model-payments-paypal-alipay-google-wallet" resource="#h-three-corner-model-payments-paypal-alipay-google-wallet"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3 </span>Three Corner Model Payments (PayPal / Alipay / Google Wallet)</span></h3>
+      <p>
+The following scenario outlines an ideal payment experience using a
+<a href="#dfn-payer" class="internalDFN">payer</a>-initiated payment, also known as a "push-payment" or
+"three corner model payment". In this scenario, Meihui is buying an airline
+ticket from a booking website and during the payment process she uses her
+fingerprint instead of a password to authorize the payment.
+      </p>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-purchase-terms-3" property="bibo:hasPart">
+        <h4 id="negotiation-of-purchase-terms-3" resource="#negotiation-of-purchase-terms-3"><span property="xhv:role" resource="xhv:heading">Negotiation of Purchase Terms</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Offer</strong>: Meihui searches for a flight on
+the booking website. She finds a flight for the ideal price and time.
+          </li>
+
+          <li>
+<strong>Agreement on Terms</strong>: Meihui selects the flight and agrees to the
+terms and service associated with the ticket.
+          </li>
+
+          <li>
+<strong>Application of Marketing Elements</strong>: <em>Not applicable to
+this particular use case.</em>
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-5" property="bibo:hasPart">
+        <h4 id="negotiation-of-payment-instruments-5" resource="#negotiation-of-payment-instruments-5"><span property="xhv:role" resource="xhv:heading">Negotiation of Payment Instruments</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Accepted Schemes</strong>: The booking website takes
+Alipay, Visa, MasterCard, and China UnionPay for payment.
+          </li>
+
+          <li>
+<strong>Selection of Payment Instruments</strong>: Meihui chooses Alipay for
+payment.
+          </li>
+
+          <li>
+<strong>Authentication to Access Instruments</strong>: Meihui logs in the Alipay
+with her account name and password. Meihui is told that she will pay for the
+airline ticket with 3,500 RMB and she confirms it. Meihui uses her fingerprint
+to approve the payment.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#payment-processing-5" property="bibo:hasPart">
+        <h4 id="payment-processing-5" resource="#payment-processing-5"><span property="xhv:role" resource="xhv:heading">Payment Processing</span></h4>
+        <ul>
+          <li>
+<strong>Initiation of Processing</strong>: Meihui's Alipay wallet initiates
+the <a href="#dfn-transaction" class="internalDFN">transaction</a>.
+          </li>
+          <li>
+<strong>Verification of Available Funds</strong>: <em>Not applicable to
+this particular use case.</em>
+          </li>
+          <li>
+<strong>Authorization of Transfer</strong>: Alipay initiates the payment to
+the booking website based on Meihui's prior fingerprint-based authorization.
+          </li>
+          <li>
+<strong>Completion of Transfer</strong>: The booking website gets a message
+from Alipay that the transfer is complete.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-5" property="bibo:hasPart">
+        <h4 id="delivery-of-product-receipt-and-refunds-5" resource="#delivery-of-product-receipt-and-refunds-5"><span property="xhv:role" resource="xhv:heading">Delivery of Product/Receipt and Refunds</span></h4>
+        <ul>
+          <li>
+<strong>Delivery of Receipt</strong>: The booking website sees that Meihui's
+airline ticket order has been paid and sends a receipt message to her
+digital wallet.
+          </li>
+
+          <li>
+<strong>Delivery of Product</strong>: The booking website sends an email to
+Meihui with the flight information including the airline, flight number,
+departure time, and gate number.
+          </li>
+        </ul>
+      </section>
+    </section>
+
+    <section id="cryptocurrency-payment-bitcoin-ripple" typeof="bibo:Chapter" resource="#cryptocurrency-payment-bitcoin-ripple" property="bibo:hasPart">
+      <h3 id="h-cryptocurrency-payment-bitcoin-ripple" resource="#h-cryptocurrency-payment-bitcoin-ripple"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.4 </span>Cryptocurrency Payment (Bitcoin, Ripple)</span></h3>
+      <p>
+The following scenario outlines an ideal payment experience using Bitcoin, or a
+Bitcoin-like cryptocurrency. In this scenario, Lenne is buying a pair of
+alpaca socks from an online retailer using a "buy one, get one free" coupon.
+The socks are shipped to her home address.
+      </p>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-purchase-terms-4" property="bibo:hasPart">
+        <h4 id="negotiation-of-purchase-terms-4" resource="#negotiation-of-purchase-terms-4"><span property="xhv:role" resource="xhv:heading">Negotiation of Purchase Terms</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Offer</strong>: Lenne searches for "warm socks,
+locally sourced" in her favorite search engine. A pair of Alpaca socks come up
+as the first hit as the Alpaca's are nearby where she lives and the online
+store (AlpacaToesCo) provides local delivery. She has a coupon in her
+digital wallet for the store, but forgot long ago that it is there.
+          </li>
+
+          <li>
+<strong>Agreement on Terms</strong>: Lenne goes to AlpacaToesCo and puts the
+socks in her online shopping cart and is shown the price. Lenne provides her
+shipping address to AlpacaToes.
+          </li>
+
+          <li>
+<strong>Application of Marketing Elements</strong>: When Lenne puts the socks
+in her online shopping cart, she's reminded of the "buy one, get one free"
+coupon she has in her wallet. She adds another pair of socks and continues
+with the checkout process.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-6" property="bibo:hasPart">
+        <h4 id="negotiation-of-payment-instruments-6" resource="#negotiation-of-payment-instruments-6"><span property="xhv:role" resource="xhv:heading">Negotiation of Payment Instruments</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Accepted Schemes</strong>: The website takes Visa,
+Ripple, and Bitcoin for payment.
+          </li>
+
+          <li>
+<strong>Selection of Payment Instruments</strong>: Lenne has a Visa card
+as well as a local Ripple wallet and a cloud-based Bitcoin wallet. Lenne
+selects her cloud-based Bitcoin wallet.
+          </li>
+
+          <li>
+<strong>Authentication to Access Instruments</strong>: Since the value of the
+payment is less than $50, Lenne isn't asked for her two-factor authentication
+device to approve the <a href="#dfn-purchase" class="internalDFN">purchase</a>.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#payment-processing-6" property="bibo:hasPart">
+        <h4 id="payment-processing-6" resource="#payment-processing-6"><span property="xhv:role" resource="xhv:heading">Payment Processing</span></h4>
+        <ul>
+          <li>
+<strong>Initiation of Processing</strong>: Lenne's cloud-based Bitcoin wallet
+provider initiates the <a href="#dfn-transaction" class="internalDFN">transaction</a>.
+          </li>
+          <li>
+<strong>Verification of Available Funds</strong>: <em>Not applicable to
+this particular use case.</em>
+          </li>
+          <li>
+<strong>Authorization of Transfer</strong>: AlpacaToesCo is sent a message
+from the Bitcoin cloud wallet notifying them that the transfer has been
+initiated. Lenne is told that she will receive a notification when the
+item is shipped.
+          </li>
+          <li>
+<strong>Completion of Transfer</strong>: AlpacaToesCo gets a message from the
+Bitcoin cloud wallet that the transfer is complete. A Bitcoin
+<a href="#dfn-transaction" class="internalDFN">transaction</a> ID is included in the message so that AlpacaToesCo can
+release the product when the appropriate number of verifications are made on
+the <a href="#dfn-transaction" class="internalDFN">transaction</a>.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-6" property="bibo:hasPart">
+        <h4 id="delivery-of-product-receipt-and-refunds-6" resource="#delivery-of-product-receipt-and-refunds-6"><span property="xhv:role" resource="xhv:heading">Delivery of Product/Receipt and Refunds</span></h4>
+        <ul>
+          <li>
+<strong>Delivery of Receipt</strong>: AlpacaToesCo sees 6 verifications on the
+transaction in the Bitcoin blockchain and sends a receipt of sale to Lenne's
+cloud wallet. The store notifies Lenne that they have shipped her package.
+          </li>
+
+          <li>
+<strong>Delivery of Product</strong>: AlpacaToesCo ships the package of socks
+to Lenne and she receives them the next day.
+          </li>
+        </ul>
+      </section>
+    </section>
+
+    <section id="electronic-check-payment" typeof="bibo:Chapter" resource="#electronic-check-payment" property="bibo:hasPart">
+      <h3 id="h-electronic-check-payment" resource="#h-electronic-check-payment"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.5 </span>Electronic Check Payment</span></h3>
+      <p><em>To be completed</em>.</p>
+    </section>
+
+    <section id="direct-debit" typeof="bibo:Chapter" resource="#direct-debit" property="bibo:hasPart">
+      <h3 id="h-direct-debit" resource="#h-direct-debit"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.6 </span>Direct Debit (SEPA Direct Debit)</span></h3>
+      <p>
+The following scenario outlines an ideal payment experience using a
+Direct Debit (<a href="#dfn-payee-initiated-payment" class="internalDFN">payee-initiated payment</a>), also known as a
+pull payment in the context of a <a href="#dfn-four-corner-model" class="internalDFN">four corner model</a> payment.
+In this scenario, Anna is signing up for electricity service via the
+service's website. During the payment process she will validate an electronic
+direct debit mandate.
+      </p>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-purchase-terms-5" property="bibo:hasPart">
+        <h4 id="negotiation-of-purchase-terms-5" resource="#negotiation-of-purchase-terms-5"><span property="xhv:role" resource="xhv:heading">Negotiation of Purchase Terms</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Offer</strong>: Anna connects to a utility website. She
+wants to setup this new utility immediately before she moves in to a new flat.
+          </li>
+          <li>
+<strong>Agreement on Terms</strong>: Anna selects the contract she wants and
+agrees to the terms and service associated with the delivery of electricity.
+          </li>
+          <li>
+<strong>Application of Marketing Elements</strong>: <em>Not applicable to this
+particular use case.</em>
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-7" property="bibo:hasPart">
+        <h4 id="negotiation-of-payment-instruments-7" resource="#negotiation-of-payment-instruments-7"><span property="xhv:role" resource="xhv:heading">Negotiation of Payment Instruments</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Accepted Schemes</strong>: The utility website takes
+Visa, MasterCard, and SEPA Direct Debit for payment.
+          </li>
+          <li>
+<strong>Selection of Payment Instruments</strong>: Anna chooses SEPA Direct
+Debit for payment.
+          </li>
+          <li>
+<strong>Authentication to Access Instruments</strong>: Anna provides
+all the mandatory data required for a valid electronic SEPA Direct Debit
+Mandate as well as the IBAN number associated with Anna's account. Anna is
+told that she is setting up a recurring payment with the utility and the
+payment will be automatically withdrawn at the end of the month based on
+her electricity consumption. She agrees to the automatic transfer by
+entering her secret PIN.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#payment-processing-7" property="bibo:hasPart">
+        <h4 id="payment-processing-7" resource="#payment-processing-7"><span property="xhv:role" resource="xhv:heading">Payment Processing</span></h4>
+        <ul>
+          <li>
+<strong>Initiation of Processing</strong>: At the end of the month the utility
+invoice system will initiate the payment by sending an invoice by email
+that will be sent directly to Anna's payment service provider.
+          </li>
+          <li>
+<strong>Verification of Available Funds</strong>: <em>Not applicable to this
+particular use case.</em>
+          </li>
+          <li>
+<strong>Authorization of Transfer</strong>: Anna's payment service provider
+authorizes the transfer based on the reference ID that was validated by
+Anna during the <strong>Authentication to Access Instruments</strong> phase.
+          </li>
+          <li>
+<strong>Completion of Transfer</strong>: The utility website gets a message
+from its payment service provider that the transfer has been completed.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-7" property="bibo:hasPart">
+        <h4 id="delivery-of-product-receipt-and-refunds-7" resource="#delivery-of-product-receipt-and-refunds-7"><span property="xhv:role" resource="xhv:heading">Delivery of Product/Receipt and Refunds</span></h4>
+        <ul>
+          <li>
+<strong>Delivery of Receipt</strong>: The utility website sees that Anna's
+direct debit mandate has been validated and sends a receipt message to her
+digital wallet.
+          </li>
+          <li>
+<strong>Delivery of Product</strong>: The utility website sends an email to
+Anna with the contract information based on the email provided in the
+Completion of Transfer message sent to her payment service provider.
+          </li>
+          <li>
+<strong>Refunds</strong>: Anna could request a refund by contacting her bank
+if something goes wrong with the Direct Debit.
+          </li>
+        </ul>
+      </section>
+    </section>
+
+    <section id="credit-transfer" typeof="bibo:Chapter" resource="#credit-transfer" property="bibo:hasPart">
+      <h3 id="h-credit-transfer" resource="#h-credit-transfer"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.7 </span>Credit Transfer (SEPAmail)</span></h3>
+      <p>
+The following scenario outlines an ideal payment experience using a
+<a href="#dfn-payer-initiated-payment" class="internalDFN">payer-initiated payment</a>, also known as a
+push payment in the context of a <a href="#dfn-four-corner-model" class="internalDFN">four corner model</a> payment. In
+this scenario, Anna is buying a very expensive piece of furniture that costs
+far more than the maximum amount allowed by her payment card. She pays
+using her bank account via her bank's website.
+      </p>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-purchase-terms-6" property="bibo:hasPart">
+        <h4 id="negotiation-of-purchase-terms-6" resource="#negotiation-of-purchase-terms-6"><span property="xhv:role" resource="xhv:heading">Negotiation of Purchase Terms</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Offer</strong>: Anna browses a Furniture website.
+She wants to buy a desk for her new flat.
+          </li>
+          <li>
+<strong>Agreement on Terms</strong>: Anna selects a heavy oak antique desk
+from the 17th century.
+          </li>
+          <li>
+<strong>Application of Marketing Elements</strong>: <em>Not applicable to this
+particular use case.</em>
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-8" property="bibo:hasPart">
+        <h4 id="negotiation-of-payment-instruments-8" resource="#negotiation-of-payment-instruments-8"><span property="xhv:role" resource="xhv:heading">Negotiation of Payment Instruments</span></h4>
+        <ul>
+          <li>
+<strong>Discovery of Accepted Schemes</strong>: The furniture website takes
+Visa, MasterCard, and SEPA "Credit Transfer via SEPAmail" for payment.
+          </li>
+          <li>
+<strong>Selection of Payment Instruments</strong>: Anna chooses
+"Credit Transfer via SEPAmail" for payment and provides a tokenized version
+of her IBAN account number. The furniture website sends a "payment request"
+to its payment service provider which will forward it to Anna’s bank.
+          </li>
+          <li>
+<strong>Authentication to Access Instruments</strong>: Anna connects to her
+bank's website where the payment request is pending approval.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#payment-processing-8" property="bibo:hasPart">
+        <h4 id="payment-processing-8" resource="#payment-processing-8"><span property="xhv:role" resource="xhv:heading">Payment Processing</span></h4>
+        <ul>
+          <li>
+<strong>Initiation of Processing</strong>: Anna approves the payment request.
+          </li>
+          <li>
+<strong>Verification of Available Funds</strong>: The availability of
+funds is verified by Anna's bank.
+          </li>
+          <li>
+<strong>Authorization of Transfer</strong>: The funds transfer is automatically
+authorized by Anna's bank.
+          </li>
+          <li>
+<strong>Completion of Transfer</strong>: Anna's bank sends the Credit Transfer,
+as well as a payment report (analogous to a signed receipt) to the furniture
+website's payment service provider. The furniture website gets a message
+(also known as a "payment advice") from its payment service provider that the
+transfer is complete depending of the Scheme of Credit Transfer used:
+within 24 hours for a SEPA Credit Transfer, often longer in International
+Credit Transfer outside Europe.
+          </li>
+        </ul>
+      </section>
+
+      <section class="notoc" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-8" property="bibo:hasPart">
+        <h4 id="delivery-of-product-receipt-and-refunds-8" resource="#delivery-of-product-receipt-and-refunds-8"><span property="xhv:role" resource="xhv:heading">Delivery of Product/Receipt and Refunds</span></h4>
+        <ul>
+          <li>
+<strong>Delivery of Receipt</strong>: The furniture website sees that Anna's
+credit transfer has been received and sends a receipt by email to
+Anna based on the email address included in the payment report.
+          </li>
+          <li>
+<strong>Delivery of Product</strong>: The piece of furniture is shipped to
+Anna.
+          </li>
+          <li>
+<strong>Refunds</strong>: Anna must contact the furniture website directly
+since the credit transfer cannot be reversed since she initiated it.
+          </li>
+        </ul>
+      </section>
+    </section>
+
+  </section>
+
+  <section class="appendix" id="future-work" typeof="bibo:Chapter" resource="#future-work" property="bibo:hasPart">
+    <!--OddPage--><h2 id="h-future-work" resource="#h-future-work"><span property="xhv:role" resource="xhv:heading"><span class="secno">A. </span>Future Work</span></h2>
+
+    <ul>
+      <li>
+Integration of US Federal Reserve Faster Payments Use Cases
+      </li>
+      <li>
+Integration of Bill and Melinda Gates Foundation Level One Project Use Cases
+      </li>
+      <li>
+Government Entitlement Disbursement
+      </li>
+      <li>
+Automatic Tax Payment
+      </li>
+      <li>
+Person to Person Cash Payment
+      </li>
+      <li>
+Government Entitlement Disbursement
+      </li>
+    </ul>
+
+  </section>
+
+  <section class="appendix" id="acknowledgements" typeof="bibo:Chapter" resource="#acknowledgements" property="bibo:hasPart">
+    <!--OddPage--><h2 id="h-acknowledgements" resource="#h-acknowledgements"><span property="xhv:role" resource="xhv:heading"><span class="secno">B. </span>Acknowledgements</span></h2>
+    <p>
+The editors wish to thank the participants of the
+<a href="http://www.w3.org/Payments/IG/">Web Payments Interest Group</a>
+for discussions about and contributions to this document, as well as the
+<a href="https://www.w3.org/community/webpayments/">Web Payments Community
+Group</a> for earlier work that informed this document.
+    </p>
+  </section>
+
+
+
+<section id="references" class="appendix" typeof="bibo:Chapter" resource="#references" property="bibo:hasPart"><!--OddPage--><h2 id="h-references" resource="#h-references"><span property="xhv:role" resource="xhv:heading"><span class="secno">C. </span>References</span></h2><section id="informative-references" typeof="bibo:Chapter" resource="#informative-references" property="bibo:hasPart"><h3 id="h-informative-references" resource="#h-informative-references"><span property="xhv:role" resource="xhv:heading"><span class="secno">C.1 </span>Informative references</span></h3><dl class="bibliography" resource=""><dt id="bib-WCAG20">[WCAG20]</dt><dd>Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et al. <a href="http://www.w3.org/TR/WCAG20/" property="dc:references"><cite>Web Content Accessibility Guidelines (WCAG) 2.0</cite></a>. 11 December 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/WCAG20/" property="dc:references">http://www.w3.org/TR/WCAG20/</a>
+</dd></dl></section></section></body></html>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/WD/use-cases/2015-07-30/diff-20150416.html	Tue Jul 28 10:34:20 2015 -0400
@@ -0,0 +1,17835 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document w3p:WD" prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#">
+<head><meta lang="" property="dc:language" content="en">
+    <title>Web Payments Use Cases 1.0</title>
+    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+    
+    
+    
+    
+    
+    <style type="text/css">
+body {
+  line-height: 1.4em;
+}
+h4 {
+  color: #005A9C;
+}
+dl {
+  margin-top: 20px;
+  margin-bottom: 20px;
+}
+dt,
+dd {
+  line-height: 1.42857143;
+}
+dl > dt:first-of-type {
+  font-weight: bold;
+}
+@media (min-width: 768px), print {
+  .dl-horizontal {
+    margin-bottom: 4em;
+  }
+  .dl-horizontal dt {
+    font-weight: normal;
+    float: left;
+    width: 160px;
+    clear: left;
+    overflow: hidden;
+    text-align: right;
+    text-overflow: ellipsis;
+    white-space: nowrap;
+  }
+  .dl-horizontal dd {
+    margin-left: 180px;
+  }
+  .dl-horizontal dd > ul {
+    padding-left: 20px;
+    margin: 0px;
+  }
+}
+    </style>
+  <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 { 
+    text-transform:     lowercase;
+    font-variant:       small-caps;
+    font-style:         normal;
+    color:              #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+    border: none;
+}
+
+dfn {
+    font-weight:    bold;
+}
+
+a.internalDFN {
+    color:  inherit;
+    border-bottom:  1px solid #99c;
+    text-decoration:    none;
+}
+
+a.externalDFN {
+    color:  inherit;
+    border-bottom:  1px dotted #ccc;
+    text-decoration:    none;
+}
+
+a.bibref {
+    text-decoration:    none;
+}
+
+cite .bibref {
+    font-style: normal;
+}
+
+code {
+    color:  #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+    text-decoration:    none;
+}
+
+a .secno, a .figno {
+    color:  #000;
+}
+
+ul.tof, ol.tof {
+    list-style: none outside none;
+}
+
+.caption {
+    margin-top: 0.5em;
+    font-style:   italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+    border-spacing: 0;
+    border-collapse:    collapse;
+    border-bottom:  3px solid #005a9c;
+}
+
+.simple th {
+    background: #005a9c;
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+}
+
+.simple th[scope="row"] {
+    background: inherit;
+    color:  inherit;
+    border-top: 1px solid #ddd;
+}
+
+.simple td {
+    padding:    3px 10px;
+    border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+    background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+    margin-top: 0;
+}
+
+.section dd > p:last-child {
+    margin-bottom: 0;
+}
+
+.section dd {
+    margin-bottom:  1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+    margin-bottom:  0;
+}
+
+@media print {
+    .removeOnSave {
+        display: none;
+    }
+}
+</style><style>/* --- ISSUES/NOTES --- */
+div.issue-title, div.note-title , div.warning-title {
+    padding-right:  1em;
+    min-width: 7.5em;
+    color: #b9ab2d;
+}
+div.issue-title { color: #e05252; }
+div.note-title { color: #2b2; }
+div.warning-title { color: #f22; }
+div.issue-title span, div.note-title span, div.warning-title span {
+    text-transform: uppercase;
+}
+div.note, div.issue, div.warning {
+    margin-top: 1em;
+    margin-bottom: 1em;
+}
+.note > p:first-child, .issue > p:first-child, .warning > p:first-child { margin-top: 0 }
+.issue, .note, .warning {
+    padding: .5em;
+    border-left-width: .5em;
+    border-left-style: solid;
+}
+div.issue, div.note , div.warning {
+    padding: 1em 1.2em 0.5em;
+    margin: 1em 0;
+    position: relative;
+    clear: both;
+}
+span.note, span.issue, span.warning { padding: .1em .5em .15em; }
+
+.issue {
+    border-color: #e05252;
+    background: #fbe9e9;
+}
+.note {
+    border-color: #52e052;
+    background: #e9fbe9;
+}
+
+.warning {
+    border-color: #f11;
+    border-right-width: .2em;
+    border-top-width: .2em;
+    border-bottom-width: .2em;
+    border-style: solid;
+    background: #fbe9e9;
+}
+
+.warning-title:before{
+    content: "⚠"; /*U+26A0 WARNING SIGN*/
+    font-size: 3em;
+    float: left;
+    height: 100%;
+    padding-right: .3em;
+    vertical-align: top;
+    margin-top: -0.5em;
+}
+</style><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--><style type='text/css'>
+.diff-old-a {
+  font-size: smaller;
+  color: red;
+}
+
+.diff-new { background-color: yellow; }
+.diff-chg { background-color: lime; }
+.diff-new:before,
+.diff-new:after
+    { content: "\2191" }
+.diff-chg:before, .diff-chg:after
+    { content: "\2195" }
+.diff-old { text-decoration: line-through; background-color: #FBB; }
+.diff-old:before,
+.diff-old:after
+    { content: "\2193" }
+:focus { border: thin red solid}
+</style>
+</head>
+
+<body class="h-entry" role="document" id="respecDocument">
+<div class="head" role="contentinfo" id="respecHeader">
+<p>
+<a href="http://www.w3.org/">
+<img width="72" height="48" src="https://www.w3.org/Icons/w3c_home" alt="W3C">
+</a>
+</p>
+<h1 class="title p-name" id="title" property="dcterms:title">
+Web
+Payments
+Use
+Cases
+1.0
+</h1>
+<h2 id="w3c-working-draft-30-july-2015">
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+<del class="diff-old">First
+Public
+</del>
+Working
+Draft
+<del class="diff-old">16
+April
+</del>
+<time property="dcterms:issued" class="dt-published" datetime="2015-07-30">
+<ins class="diff-chg">30
+July
+</ins>
+2015
+</time>
+</h2>
+<dl>
+<dt>
+This
+version:
+</dt>
+<dd>
+<del class="diff-old">http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/
+</del>
+<a class="u-url" href="http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150730/">
+<ins class="diff-chg">http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150730/
+</ins>
+</a>
+</dd>
+<dt>
+Latest
+published
+version:
+</dt>
+<dd>
+<a href="http://www.w3.org/TR/web-payments-use-cases/">
+http://www.w3.org/TR/web-payments-use-cases/
+</a>
+</dd>
+<dt>
+Latest
+editor's
+draft:
+</dt>
+<dd>
+<a href="https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html">
+https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html
+</a>
+</dd>
+<dt>
+<ins class="diff-new">Previous
+version:
+</ins></dt><dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/"><ins class="diff-new">
+http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/
+</ins></a></dd><dt>
+Editors:
+</dt>
+<dd class="p-author h-card vcard" property="bibo:editor" resource="_:editor0">
+<span property="rdf:first" typeof="foaf:Person">
+<meta property="foaf:name" content="Manu Sporny">
+<a class="u-url url p-name fn" property="foaf:homepage" href="https://manu.sporny.org/">
+Manu
+Sporny
+</a>,
+<a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://digitalbazaar.com/">
+Digital
+Bazaar
+</a>
+</span>
+<span property="rdf:rest" resource="_:editor1">
+</span>
+</dd>
+<dd class="p-author h-card vcard" resource="_:editor1">
+<span property="rdf:first" typeof="foaf:Person">
+<meta property="foaf:name" content="Ian Jacobs">
+<a class="u-url url p-name fn" property="foaf:homepage" href="http://www.w3.org/People/Jacobs/">
+Ian
+Jacobs
+</a>,
+<a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.w3.org/">
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+</a>
+</span>
+<span property="rdf:rest" resource="rdf:nil">
+</span>
+</dd>
+<dt>
+Authors:
+</dt>
+<dd class="p-author h-card vcard">
+<span property="dc:contributor" typeof="foaf:Person">
+<meta property="foaf:name" content="Ian Jacobs">
+<a class="u-url url p-name fn" property="foaf:homepage" href="http://www.w3.org/People/Jacobs/">
+Ian
+Jacobs
+</a>,
+<a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.w3.org/">
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+</a>
+</span>
+</dd>
+<dd class="p-author h-card vcard">
+<span property="dc:contributor" typeof="foaf:Person">
+<meta property="foaf:name" content="Manu Sporny">
+<a class="u-url url p-name fn" property="foaf:homepage" href="https://manu.sporny.org/">
+Manu
+Sporny
+</a>,
+<a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://digitalbazaar.com/">
+Digital
+Bazaar
+</a>
+</span>
+</dd>
+<dd class="p-author h-card vcard">
+<span property="dc:contributor" typeof="foaf:Person">
+<span property="foaf:name" class="p-name fn">
+<ins class="diff-chg">Qian
+Sun
+</ins></span>,<a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.alibabagroup.com/"><ins class="diff-chg">
+Alibaba
+</ins></a>
+<del class="diff-old">David
+Ezell
+</del>
+</span>
+</dd>
+<dd class="p-author h-card vcard">
+<span property="dc:contributor" typeof="foaf:Person">
+<meta property="foaf:name" content="Cyril Vignet">
+<a class="u-url url p-name fn" property="foaf:homepage" href="https://www.linkedin.com/pub/cyril-vignet/bb/704/423">
+<ins class="diff-chg">Cyril
+Vignet
+</ins>
+</a>,
+<del class="diff-old">NACS
+</del>
+<a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.bpce.fr/">
+<ins class="diff-chg">Groupe
+BPCE
+</ins>
+</a>
+</span>
+</dd>
+<dd class="p-author h-card vcard">
+<span property="dc:contributor" typeof="foaf:Person">
+<del class="diff-old">Qian
+Sun
+,
+Alibaba
+</del>
+<meta property="foaf:name" content="David Ezell">
+<a class="u-url url p-name fn" property="foaf:homepage" href="http://example.org/">
+<ins class="diff-chg">David
+Ezell
+</ins></a>,<a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.nacsonline.com/"><ins class="diff-chg">
+NACS
+</ins>
+</a>
+</span>
+</dd>
+<dd class="p-author h-card vcard">
+<span property="dc:contributor" typeof="foaf:Person">
+<meta property="foaf:name" content="David Jackson">
+<a class="u-url url p-name fn" property="foaf:homepage" href="https://www.linkedin.com/in/davidjjackson">
+David
+Jackson
+</a>,
+<a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">
+Oracle
+</a>
+</span>
+</dd>
+<dt>
+Version
+control:
+</dt>
+<dd>
+<a href="https://github.com/w3c/webpayments-ig">
+Github
+Repository
+</a>
+</dd>
+<dd>
+<a href="http://www.w3.org/Payments/IG/track/products/2">
+Issues
+</a>
+</dd>
+</dl>
+<p>
+<ins class="diff-new">This
+document
+is
+also
+available
+in
+this
+non-normative
+format:
+</ins><a rel="alternate" href="diff-20150416.html"><ins class="diff-new">
+diff
+to
+previous
+version
+</ins></a></p>
+<p class="copyright">
+<a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
+Copyright
+</a>

+2015
+<a href="http://www.w3.org/">
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+</a>
+<sup>

+</sup>
+(
+<a href="http://www.csail.mit.edu/">
+<abbr title="Massachusetts Institute of Technology">
+MIT
+</abbr>
+</a>,
+<a href="http://www.ercim.eu/">
+<abbr title="European Research Consortium for Informatics and Mathematics">
+ERCIM
+</abbr>
+</a>,
+<a href="http://www.keio.ac.jp/">
+Keio
+</a>,
+<a href="http://ev.buaa.edu.cn/">
+Beihang
+</a>
+).
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+<a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">
+liability
+</a>,
+<a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">
+trademark
+</a>
+and
+<a href="http://www.w3.org/Consortium/Legal/copyright-documents">
+document
+use
+</a>
+rules
+apply.
+</p>
+<hr>
+</div>
+<section id="abstract" class="introductory" property="dc:abstract">
+<h2 id="h-abstract" resource="#h-abstract">
+<span property="xhv:role" resource="xhv:heading">
+Abstract
+</span>
+</h2>
+<p>
+This
+document
+is
+a
+prioritized
+list
+of
+Web
+payments
+use
+cases.
+Guided
+by
+these
+use
+cases,
+the
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Web
+Payments
+Interest
+Group
+plans
+to
+derive
+architecture
+and
+associated
+technology
+requirements
+to
+integrate
+payments
+into
+the
+Open
+Web
+Platform.
+That
+work
+will
+form
+the
+basis
+of
+conversations
+with
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+groups
+and
+the
+broader
+payments
+industry
+about
+what
+standards
+(from
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+or
+other
+organizations)
+will
+be
+necessary
+to
+fulfill
+the
+use
+cases
+and
+make
+payments
+over
+the
+Web
+easier
+and
+more
+secure.
+</p>
+</section>
+<section id="sotd" class="introductory">
+<h2 id="h-sotd" resource="#h-sotd">
+<span property="xhv:role" resource="xhv:heading">
+Status
+of
+This
+Document
+</span>
+</h2>
+<p>
+<em>
+This
+section
+describes
+the
+status
+of
+this
+document
+at
+the
+time
+of
+its
+publication.
+Other
+documents
+may
+supersede
+this
+document.
+A
+list
+of
+current
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+publications
+and
+the
+latest
+revision
+of
+this
+technical
+report
+can
+be
+found
+in
+the
+<a href="http://www.w3.org/TR/">
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+technical
+reports
+index
+</a>
+at
+http://www.w3.org/TR/.
+</em>
+</p>
+<p>
+This
+document
+is
+a
+work
+in
+progress
+and
+is
+being
+released
+early
+and
+often
+using
+an
+agile
+process;
+it
+is
+incomplete.
+</p>
+<p>
+The
+Web
+Payments
+IG
+has
+only
+had
+the
+opportunity
+to
+review
+a
+handful
+of
+the
+40+
+use
+cases,
+120+
+requirements,
+hundreds
+of
+pages
+of
+payments
+research
+submitted
+to
+the
+group
+via
+various
+other
+standards
+group
+output
+such
+as
+ISO20022,
+research
+documents
+from
+X9
+and
+the
+US
+Federal
+Reserve,
+documents
+from
+the
+Web
+Payments
+Community
+Group,
+and
+input
+from
+the
+general
+public.
+Our
+desire
+is
+to
+align
+with
+the
+larger
+payments
+industry
+when
+it's
+possible
+to
+do
+so.
+Expect
+this
+document
+to
+be
+rapidly
+iterated
+upon
+with
+that
+desire
+in
+mind.
+</p>
+<p>
+<ins class="diff-new">The
+following
+changes
+have
+been
+made
+since
+the
+last
+version
+of
+this
+document:
+</ins></p><ul><li><ins class="diff-new">
+Reorganization
+of
+use
+cases
+by
+phases
+approved
+by
+the
+Web
+Payments
+IG.
+</ins></li><li><ins class="diff-new">
+Removal
+of
+the
+"Goals"
+for
+each
+use
+case
+as
+they
+were
+repetitive
+and
+did
+not
+greatly
+aid
+understanding
+of
+the
+use
+case.
+</ins></li><li><ins class="diff-new">
+Addition
+of
+Regulatory
+concerns
+to
+a
+number
+of
+the
+use
+cases.
+</ins></li><li><ins class="diff-new">
+Addition
+of
+two
+more
+scenarios
+related
+to
+Direct
+Debit
+and
+Credit
+Transfer.
+</ins></li><li><ins class="diff-new">
+Addition
+of
+"Relationship
+to
+Other
+Documents"
+section.
+</ins></li><li><ins class="diff-new">
+Integration
+of
+a
+unified
+Web
+Payments
+Activity
+glossary.
+</ins></li><li><ins class="diff-new">
+Addition
+of
+Escrow,
+Biometric,
+Know
+Your
+Customer
+(KYC),
+and
+Anti-Money
+Laundering
+(AML)
+use
+cases.
+</ins></li><li><ins class="diff-new">
+Integration
+of
+feedback
+from
+the
+public,
+Web
+Payments
+Community
+Group,
+and
+Web
+Payments
+Interest
+Group.
+</ins></li></ul><p>
+This
+document
+was
+published
+by
+the
+<a href="http://www.w3.org/blog/wpig/">
+Web
+Payments
+Interest
+Group
+</a>
+as
+a
+<del class="diff-old">First
+Public
+</del>
+Working
+Draft.
+The group does not expect this document to become a
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Recommendation.
+If
+you
+wish
+to
+make
+comments
+regarding
+this
+document,
+please
+send
+them
+to
+<a href="mailto:public-webpayments-comments@w3.org">
+public-webpayments-comments@w3.org
+</a>
+(
+<a href="mailto:public-webpayments-comments-request@w3.org?subject=subscribe">
+subscribe
+</a>,
+<a href="http://lists.w3.org/Archives/Public/public-webpayments-comments/">
+archives
+</a>
+).
+All
+comments
+are
+welcome.
+</p>
+<p>
+Publication
+as
+a
+<del class="diff-old">First
+Public
+</del>
+Working
+Draft
+does
+not
+imply
+endorsement
+by
+the
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Membership.
+This
+is
+a
+draft
+document
+and
+may
+be
+updated,
+replaced
+or
+obsoleted
+by
+other
+documents
+at
+any
+time.
+It
+is
+inappropriate
+to
+cite
+this
+document
+as
+other
+than
+work
+in
+progress.
+</p>
+<p>
+This
+document
+was
+produced
+by
+a
+group
+operating
+under
+the
+<a id="sotd_patent" property="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">
+5
+February
+2004
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Patent
+Policy
+</a>.
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+maintains
+a
+<a href="http://www.w3.org/2004/01/pp-impl/73816/status" rel="disclosure">
+public
+list
+of
+any
+patent
+disclosures
+</a>
+made
+in
+connection
+with
+the
+deliverables
+of
+the
+group;
+that
+page
+also
+includes
+instructions
+for
+disclosing
+a
+patent.
+An
+individual
+who
+has
+actual
+knowledge
+of
+a
+patent
+which
+the
+individual
+believes
+contains
+<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
+Essential
+Claim(s)
+</a>
+must
+disclose
+the
+information
+in
+accordance
+with
+<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
+section
+6
+of
+the
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Patent
+Policy
+</a>.
+</p>
+<p>
+This
+document
+is
+governed
+by
+the
+<a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">
+1
+August
+2014
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Process
+Document
+</a>.
+</p>
+</section>
+<section id="toc">
+<h2 class="introductory" id="h-toc" resource="#h-toc">
+<span property="xhv:role" resource="xhv:heading">
+Table
+of
+Contents
+</span>
+</h2>
+<ul class="toc" role="directory" id="respecContents">
+<li class="tocline">
+<a href="#introduction" class="tocxref">
+<span class="secno">
+1.
+</span>
+Introduction
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#why-this-work-is-important" class="tocxref">
+<span class="secno">
+1.1
+</span>
+Why
+This
+Work
+is
+Important
+</a>
+</li>
+<li class="tocline">
+<a href="#relationships" class="tocxref">
+<span class="secno">
+1.2
+</span>
+<ins class="diff-new">Relationship
+to
+Other
+Documents
+</ins></a></li><li class="tocline"><a href="#how-this-document-is-organized" class="tocxref"><span class="secno"><ins class="diff-new">
+1.3
+</ins></span>
+How
+this
+Document
+is
+Organized
+</a>
+</li>
+</ul>
+</li>
+<li class="tocline">
+<a href="#terminology" class="tocxref">
+<span class="secno">
+2.
+</span>
+Terminology
+</a>
+</li>
+<li class="tocline">
+<a href="#an-overview-of-the-payment-phases" class="tocxref">
+<span class="secno">
+3.
+</span>
+An
+Overview
+of
+the
+Payment
+Phases
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#negotiation-of-payment-terms" class="tocxref">
+<span class="secno">
+3.1
+</span>
+Negotiation
+of
+Payment
+Terms
+</a>
+</li>
+<li class="tocline">
+<a href="#negotiation-of-payment-instruments" class="tocxref">
+<span class="secno">
+3.2
+</span>
+Negotiation
+of
+Payment
+Instruments
+</a>
+</li>
+<li class="tocline">
+<a href="#payment-processing" class="tocxref">
+<span class="secno">
+3.3
+</span>
+Payment
+Processing
+</a>
+</li>
+<li class="tocline">
+<a href="#delivery-of-product-receipt-and-refunds" class="tocxref">
+<span class="secno">
+3.4
+</span>
+Delivery
+of
+Product/Receipt
+and
+Refunds
+</a>
+</li>
+</ul>
+</li>
+<li class="tocline">
+<a href="#a-simple-example-of-the-payment-phases" class="tocxref">
+<span class="secno">
+4.
+</span>
+A
+Simple
+Example
+of
+the
+Payment
+Phases
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#negotiation-of-purchase-terms" class="tocxref">
+<span class="secno">
+4.1
+</span>
+Negotiation
+of
+Purchase
+Terms
+</a>
+</li>
+<li class="tocline">
+<a href="#negotiation-of-payment-instruments-1" class="tocxref">
+<span class="secno">
+4.2
+</span>
+Negotiation
+of
+Payment
+Instruments
+</a>
+</li>
+<li class="tocline">
+<a href="#payment-processing-1" class="tocxref">
+<span class="secno">
+4.3
+</span>
+Payment
+Processing
+</a>
+</li>
+<li class="tocline">
+<a href="#delivery-of-product-receipt-and-refunds-1" class="tocxref">
+<span class="secno">
+4.4
+</span>
+Delivery
+of
+Product/Receipt
+and
+Refunds
+</a>
+</li>
+</ul>
+</li>
+<li class="tocline">
+<a href="#assumptions" class="tocxref">
+<span class="secno">
+5.
+</span>
+Assumptions
+</a>
+</li>
+<li class="tocline">
+<a href="#use-cases-1" class="tocxref">
+<span class="secno">
+6.
+</span>
+Use
+Cases
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#negotiation-of-payment-terms-1" class="tocxref">
+<span class="secno">
+6.1
+</span>
+Negotiation
+of
+Payment
+Terms
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#discovery-of-offer" class="tocxref">
+<span class="secno">
+6.1.1
+</span>
+Discovery
+of
+Offer
+</a>
+</li>
+<li class="tocline">
+<a href="#agreement-on-terms" class="tocxref">
+<span class="secno">
+6.1.2
+</span>
+Agreement
+on
+Terms
+</a>
+</li>
+<li class="tocline">
+<a href="#application-of-marketing-elements" class="tocxref">
+<span class="secno">
+6.1.3
+</span>
+Application
+of
+Marketing
+Elements
+</a>
+</li>
+</ul>
+</li>
+<li class="tocline">
+<a href="#negotiation-of-payment-instruments-2" class="tocxref">
+<span class="secno">
+6.2
+</span>
+Negotiation
+of
+Payment
+Instruments
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#discovery-of-accepted-schemes" class="tocxref">
+<span class="secno">
+6.2.1
+</span>
+Discovery
+of
+Accepted
+Schemes
+</a>
+</li>
+<li class="tocline">
+<a href="#selection-of-payment-instruments" class="tocxref">
+<span class="secno">
+6.2.2
+</span>
+Selection
+of
+Payment
+Instruments
+</a>
+</li>
+<li class="tocline">
+<a href="#authentication-to-access-instruments" class="tocxref">
+<span class="secno">
+6.2.3
+</span>
+Authentication
+to
+Access
+Instruments
+</a>
+</li>
+</ul>
+</li>
+<li class="tocline">
+<a href="#payment-processing-2" class="tocxref">
+<span class="secno">
+6.3
+</span>
+Payment
+Processing
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#initiation-of-processing" class="tocxref">
+<span class="secno">
+6.3.1
+</span>
+Initiation
+of
+Processing
+</a>
+</li>
+<li class="tocline">
+<a href="#verification-of-available-funds" class="tocxref">
+<span class="secno">
+6.3.2
+</span>
+Verification
+of
+Available
+Funds
+</a>
+</li>
+<li class="tocline">
+<a href="#authorization-of-transfer" class="tocxref">
+<span class="secno">
+6.3.3
+</span>
+Authorization
+of
+Transfer
+</a>
+</li>
+<li class="tocline">
+<a href="#completion-of-transfer" class="tocxref">
+<span class="secno">
+6.3.4
+</span>
+Completion
+of
+Transfer
+</a>
+</li>
+</ul>
+</li>
+<li class="tocline">
+<a href="#delivery-of-product-receipt-and-refunds-2" class="tocxref">
+<span class="secno">
+6.4
+</span>
+Delivery
+of
+Product/Receipt
+and
+Refunds
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#delivery-of-product" class="tocxref">
+<span class="secno">
+6.4.1
+</span>
+Delivery
+of
+Product
+</a>
+</li>
+<li class="tocline">
+<a href="#delivery-of-receipt" class="tocxref">
+<span class="secno">
+6.4.2
+</span>
+Delivery
+of
+Receipt
+</a>
+</li>
+<li class="tocline">
+<a href="#refunds" class="tocxref">
+<span class="secno">
+6.4.3
+</span>
+Refunds
+</a>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="tocline">
+<a href="#additional-examples-of-the-payment-phases" class="tocxref">
+<span class="secno">
+7.
+</span>
+Additional
+Examples
+of
+the
+Payment
+Phases
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#credit-card-payment-visa-mastercard" class="tocxref">
+<span class="secno">
+7.1
+</span>
+Credit
+Card
+Payment
+(Visa,
+MasterCard)
+</a>
+<ul class="toc">
+</ul>
+</li>
+<li class="tocline">
+<a href="#tokenized-payments-applepay-venmo-cybersource" class="tocxref">
+<span class="secno">
+7.2
+</span>
+Tokenized
+Payments
+(ApplePay
+/
+Venmo
+/
+CyberSource)
+</a>
+<ul class="toc">
+</ul>
+</li>
+<li class="tocline">
+<a href="#three-corner-model-payments-paypal-alipay-google-wallet" class="tocxref">
+<span class="secno">
+7.3
+</span>
+Three
+Corner
+Model
+Payments
+(PayPal
+/
+Alipay
+/
+Google
+Wallet)
+</a>
+<ul class="toc">
+</ul>
+</li>
+<li class="tocline">
+<a href="#cryptocurrency-payment-bitcoin-ripple" class="tocxref">
+<span class="secno">
+7.4
+</span>
+Cryptocurrency
+Payment
+(Bitcoin,
+Ripple)
+</a>
+<ul class="toc">
+</ul>
+</li>
+<li class="tocline">
+<a href="#electronic-check-payment" class="tocxref">
+<span class="secno">
+7.5
+</span>
+Electronic
+<del class="diff-old">Cheque
+</del>
+<ins class="diff-chg">Check
+</ins>
+Payment
+</a>
+</li>
+<li class="tocline">
+<a href="#direct-debit" class="tocxref">
+<span class="secno">
+7.6
+</span>
+<del class="diff-old">Credit
+Transfer
+/
+</del>
+Direct
+Debit
+<ins class="diff-new">(SEPA
+Direct
+Debit)
+</ins></a><ul class="toc"></ul></li><li class="tocline"><a href="#credit-transfer" class="tocxref"><span class="secno"><ins class="diff-new">
+7.7
+</ins></span><ins class="diff-new">
+Credit
+Transfer
+(SEPAmail)
+</ins>
+</a>
+<ul class="toc">
+</ul>
+</li>
+</ul>
+</li>
+<li class="tocline">
+<a href="#future-work" class="tocxref">
+<span class="secno">
+A.
+</span>
+Future
+Work
+</a>
+</li>
+<li class="tocline">
+<a href="#acknowledgements" class="tocxref">
+<span class="secno">
+B.
+</span>
+Acknowledgements
+</a>
+</li>
+<li class="tocline">
+<a href="#references" class="tocxref">
+<span class="secno">
+C.
+</span>
+References
+</a>
+<ul class="toc">
+<li class="tocline">
+<a href="#informative-references" class="tocxref">
+<span class="secno">
+C.1
+</span>
+Informative
+references
+</a>
+</li>
+</ul>
+</li>
+</ul>
+</section>
+<section id="introduction" typeof="bibo:Chapter" resource="#introduction" property="bibo:hasPart">
+<h2 id="h-introduction" resource="#h-introduction">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+1.
+</span>
+Introduction
+</span>
+</h2>
+<p>
+ECommerce
+is
+thriving
+and
+continues
+to
+expand.
+However,
+fragmentation
+of
+payment
+systems
+is
+limiting
+the
+growth
+potential
+as
+are
+problems
+—
+both
+real
+and
+perceived
+—
+such
+as
+fraud
+and
+usability.
+</p>
+<p>
+Because
+the
+Web
+is
+ubiquitous,
+strengthening
+support
+for
+Web
+payments
+has
+the
+potential
+to
+create
+new
+opportunities
+for
+businesses
+and
+customers.
+Mobile
+devices
+are
+already
+transforming
+the
+industry
+by
+supplanting
+physical
+payment
+cards
+in
+proximity
+payments,
+voucher
+distribution,
+and
+identification
+when
+people
+authenticate
+to
+a
+scanner,
+point
+of
+sale,
+or
+access
+gate.
+Although
+we
+are
+seeing
+innovation
+in
+mobile
+payment
+systems,
+the
+lack
+of
+standards
+makes
+it
+more
+difficult
+to
+adapt
+to
+new
+payment
+approaches
+or
+integrate
+new
+payment
+providers.
+</p>
+<p>
+The
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Web
+Payments
+Interest
+Group
+is
+developing
+a
+roadmap
+for
+standards
+to
+improve
+the
+interoperability
+of
+payments
+using
+Web
+technologies
+for
+both
+online
+and
+brick-and-mortar
+(offline)
+scenarios.
+This
+will
+help
+achieve
+greater
+interoperability
+among
+merchants
+and
+their
+customers,
+payment
+providers,
+software
+vendors,
+mobile
+operators,
+native
+mobile
+apps,
+and
+payment
+networks.
+The
+roadmap
+will
+include
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">
+payment
+schemes
+</a>
+in
+use
+today
+(such
+as
+electronic
+<del class="diff-old">cheques,
+</del>
+<ins class="diff-chg">checks,
+</ins>
+credit
+cards,
+direct
+debit,
+and
+cryptocurrencies)
+and
+those
+of
+the
+future.
+The
+roadmap
+will
+be
+derived
+from
+the
+use
+cases
+listed
+below.
+</p>
+<section id="why-this-work-is-important" typeof="bibo:Chapter" resource="#why-this-work-is-important" property="bibo:hasPart">
+<h3 id="h-why-this-work-is-important" resource="#h-why-this-work-is-important">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+1.1
+</span>
+Why
+This
+Work
+is
+Important
+</span>
+</h3>
+<p>
+The
+Web
+Payments
+work
+is
+not
+just
+about
+making
+payments
+easier,
+faster,
+more
+secure,
+and
+more
+innovative.
+There
+are
+many
+people
+around
+the
+world
+that
+today's
+financial
+system
+does
+not
+reach.
+These
+people
+are
+called
+the
+world's
+unbanked
+(or
+underbanked).
+The
+unbanked
+often
+live
+<del class="diff-old">pay
+cheque
+</del>
+<ins class="diff-chg">paycheck
+</ins>
+to
+<del class="diff-old">pay
+cheque,
+</del>
+<ins class="diff-chg">paycheck,
+</ins>
+do
+not
+have
+access
+to
+savings
+accounts
+or
+low-fee
+<del class="diff-old">cheque
+</del>
+<ins class="diff-chg">check
+</ins>
+cashing
+services,
+lines
+of
+credit,
+or
+a
+way
+of
+saving
+for
+their
+future.
+Being
+unable
+to
+plan
+for
+one's
+financial
+future
+often
+results
+in
+a
+focus
+on
+the
+short-term,
+which
+creates
+a
+vicious
+cycle
+of
+not
+being
+able
+to
+escape
+one's
+situation.
+Not
+being
+able
+to
+participate
+in
+the
+financial
+system
+creates
+unintended
+inequities
+that
+create
+waste
+and
+result
+in
+a
+net
+loss
+for
+society.
+</p>
+<p>
+However,
+some
+of
+the
+shortcomings
+of
+today's
+financial
+system
+could
+be
+addressed
+via
+technological
+improvements.
+For
+example,
+there
+is
+a
+considerable
+overlap
+between
+the
+unbanked
+and
+underbanked
+population
+and
+access
+to
+advanced
+mobile
+phones
+and
+the
+Web.
+By
+providing
+financial
+services
+to
+people
+with
+mobile
+phones
+in
+a
+standardized
+way
+via
+the
+Web,
+we
+could
+see
+an
+improvement
+in
+the
+financial
+health
+of
+these
+individuals
+and
+their
+families.
+</p>
+<p>
+Extending
+the
+current
+financial
+system
+to
+reach
+further
+helps
+an
+ever
+increasing
+number
+of
+people
+plan
+for
+their
+future,
+focus
+on
+the
+long-term,
+and
+thus
+contributes
+to
+a
+greater
+net
+gain
+for
+society.
+</p>
+</section>
+<section id="relationships" typeof="bibo:Chapter" resource="#relationships" property="bibo:hasPart">
+<h3 id="h-relationships" resource="#h-relationships">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+<ins class="diff-new">1.2
+</ins></span><ins class="diff-new">
+Relationship
+to
+Other
+Documents
+</ins></span></h3><p><ins class="diff-new">
+This
+document
+is
+one
+part
+of
+a
+greater
+body
+of
+work
+around
+Web
+Payments
+that
+the
+</ins><a href="https://www.w3.org/Payments/IG/"><ins class="diff-new">
+Web
+Payments
+Interest
+Group
+</ins></a><ins class="diff-new">
+at
+</ins><abbr title="World Wide Web Consortium"><ins class="diff-new">
+W3C
+</ins></abbr><ins class="diff-new">
+is
+producing.
+These
+other
+documents
+include:
+</ins></p><ul><li><a href="https://www.w3.org/Payments/IG/Vision"><ins class="diff-new">
+A
+Vision
+for
+Web
+Payments
+</ins></a><ins class="diff-new">
+describes
+the
+desirable
+properties
+of
+a
+Web
+Payments
+architecture.
+</ins></li><li><a href="http://www.w3.org/TR/web-payments-use-cases/"><ins class="diff-new">
+Web
+Payments
+Use
+Cases
+1.0
+</ins></a><ins class="diff-new">
+(this
+document)
+is
+a
+prioritized
+list
+of
+all
+Web
+Payments
+scenarios
+that
+the
+Web
+Payments
+Interest
+Group
+expects
+the
+architecture
+to
+address
+in
+time.
+</ins></li><li><a href="https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/capabilities/index.html"><ins class="diff-new">
+Web
+Payments
+Capabilities
+1.0
+</ins></a><ins class="diff-new">
+derives
+a
+set
+of
+capabilities
+from
+the
+use
+cases
+that,
+if
+standardized,
+will
+improve
+payments
+on
+the
+Web.
+</ins></li><li><a href="https://www.w3.org/Payments/IG/Roadmap"><ins class="diff-new">
+Web
+Payments
+Roadmap
+1.0
+</ins></a><ins class="diff-new">
+proposes
+an
+implementation
+and
+deployment
+plan
+that
+will
+result
+in
+enhancements
+to
+the
+Open
+Web
+Platform
+that
+will
+achieve
+the
+scenarios
+outlined
+in
+the
+Use
+Cases
+document
+and
+the
+capabilities
+listed
+in
+the
+Capabilities
+document.
+</ins></li></ul></section>
+<section id="how-this-document-is-organized" typeof="bibo:Chapter" resource="#how-this-document-is-organized" property="bibo:hasPart">
+<h3 id="h-how-this-document-is-organized" resource="#h-how-this-document-is-organized">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+<del class="diff-old">1.2
+</del>
+<ins class="diff-chg">1.3
+</ins>
+</span>
+How
+this
+Document
+is
+Organized
+</span>
+</h3>
+<p>
+This
+document
+is
+organized
+as
+follows:
+</p>
+<ul>
+<li>
+<a href="#terminology">
+Section
+<del class="diff-old">2
+</del>
+<ins class="diff-chg">2:
+Terminology
+</ins></a>
+defines
+basic
+payment
+<del class="diff-old">terms.
+</del>
+<ins class="diff-chg">terminology.
+</ins>
+</li>
+<li>
+<a href="#an-overview-of-the-payment-phases">
+Section
+<del class="diff-old">3
+</del>
+<ins class="diff-chg">3:
+An
+Overview
+of
+the
+Payment
+Phases
+</ins></a>
+describes
+a
+common
+payment
+flow
+at
+a
+high
+level.
+The
+group
+expects
+to
+work
+on
+additional
+payment
+flows
+in
+future
+work.
+</li>
+<li>
+<a href="#a-simple-example-of-the-payment-phases">
+Section
+<del class="diff-old">4
+</del>
+<ins class="diff-chg">4:
+A
+Simple
+Example
+of
+the
+Payment
+Phases
+</ins></a>
+is
+a
+specific
+narrative,
+labeled
+according
+to
+the
+steps
+of
+section
+3.
+<a href="#additional-examples-of-the-payment-phases">
+Section
+<del class="diff-old">7
+</del>
+<ins class="diff-chg">7:
+Additional
+Examples
+of
+the
+Payment
+Phases
+</ins></a>
+describes
+additional
+familiar
+narratives
+to
+give
+a
+more
+complete
+picture
+of
+how
+the
+payment
+phases
+apply.
+</li>
+<li>
+<a href="#assumptions">
+Section
+<del class="diff-old">6
+</del>
+<ins class="diff-chg">5:
+Assumptions
+</ins></a><ins class="diff-chg">
+highlights
+general
+assumptions
+that
+have
+been
+made
+about
+the
+use
+cases.
+</ins></li><li><a href="#use-cases-1"><ins class="diff-chg">
+Section
+6:
+Use
+Cases
+</ins></a>
+lists
+the
+use
+cases
+-
+short
+scenarios
+that
+cover
+diverse
+aspects
+of
+each
+payment
+step.
+</li>
+</ul>
+<p>
+Each
+use
+case
+has:
+</p>
+<ul>
+<li>
+A
+title
+and
+short
+description.
+</li>
+<li>
+<del class="diff-old">Goals.
+How
+</del>
+<ins class="diff-chg">A
+</ins><em><ins class="diff-chg">
+Roadmap
+phase
+</ins></em><ins class="diff-chg">
+which
+specifies
+</ins>
+the
+<del class="diff-old">use
+case
+advances
+one
+or
+more
+</del>
+<ins class="diff-chg">intended
+phase
+</ins>
+of
+the
+<del class="diff-old">goals
+for
+an
+interoperable
+</del>
+<a href="https://www.w3.org/Payments/IG/Roadmap">
+Web
+<del class="diff-old">payments
+framework
+.
+</del>
+<ins class="diff-chg">Payments
+Roadmap
+</ins></a><ins class="diff-chg">
+that
+will
+enable
+the
+use
+case.
+</ins>
+</li>
+<li>
+<del class="diff-old">Motivation.
+This
+is
+commentary
+</del>
+<ins class="diff-chg">A
+short
+</ins><em><ins class="diff-chg">
+Motivation
+</ins></em><ins class="diff-chg">
+statement
+</ins>
+to
+help
+explain
+why
+the
+use
+case
+has
+been
+included,
+including
+how
+it
+relates
+to
+similar
+use
+cases.
+</li>
+</ul>
+<p>
+Each
+use
+case
+may
+also
+have
+notes
+on:
+</p>
+<ul>
+<li>
+Security/Privacy.
+Security
+or
+privacy
+issues
+that
+may
+arise
+through
+this
+use
+case.
+</li>
+<li>
+<ins class="diff-new">Accessibility.
+Accessibility
+considerations
+(e.g.,
+in
+multi-factor
+authentication,
+management
+of
+biometrics
+in
+the
+case
+of
+users
+with
+some
+disabilities).
+</ins></li><li><ins class="diff-new">
+Regulatory.
+Regulatory
+considerations
+(e.g.,
+anti-money
+laundering
+clearing,
+suspicious
+activity
+reporting,
+tax
+collection,
+trade
+compliance).
+</ins></li><li>
+Exceptions.
+Considerations
+in
+the
+case
+of
+specific
+exceptions
+(e.g.,
+if
+a
+user
+pays
+with
+a
+voucher
+and
+the
+<a href="#dfn-transaction" class="internalDFN">
+transaction
+</a>
+fails,
+the
+user's
+voucher
+should
+be
+restored).
+</li>
+<del class="diff-old">Accessibility.
+Accessibility
+considerations
+(e.g.,
+in
+multi-factor
+authentication,
+management
+of
+biometrics
+in
+the
+case
+of
+users
+with
+some
+disabilities).
+</del>
+</ul>
+<div class="issue">
+<div class="issue-title" aria-level="4" role="heading" id="h-issue1">
+<span>
+Issue
+1
+</span>
+</div>
+<p class="">
+The
+group
+seeks
+input
+from
+security,
+privacy,
+and
+accessibility
+experts.
+Examples
+of
+desired
+groups
+to
+perform
+these
+reviews
+are,
+but
+are
+not
+limited
+to:
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Privacy
+Interest
+Group,
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Security
+Interest
+Group,
+<abbr title="World Wide Web Consortium">
+W3C
+</abbr>
+Web
+Accessibility
+Initiative
+and
+Protocols
+and
+Formats
+Working
+Group,
+US
+Federal
+Reserve
+Security
+Panels,
+X9
+Security
+subgroups,
+and
+ISO
+security
+subgroups.
+</p>
+</div>
+<del class="diff-old">The
+Interest
+Group
+(currently)
+regards
+some
+of
+the
+use
+cases
+as
+"essential"
+to
+addressing
+their
+goals
+and
+others
+as
+"non-essential."
+</del>
+<div class="note">
+<div class="note-title" aria-level="4" role="heading" id="h-note1">
+<span>
+Note
+</span>
+</div>
+<p class="">
+All
+character
+names
+appearing
+in
+this
+document
+are
+fictitious.
+Any
+resemblance
+to
+real
+persons,
+living
+or
+dead,
+is
+purely
+coincidental.
+Some
+organizations,
+products,
+and
+services
+appearing
+in
+this
+document
+are
+real
+and
+are
+included
+purely
+for
+pedagogic
+purposes
+and
+don't
+imply
+endorsement
+or
+approval
+of
+the
+Web
+Payments
+work
+in
+any
+way,
+shape,
+or
+form.
+For
+all
+other
+organizations,
+products,
+or
+services
+appearing
+in
+this
+document,
+any
+resemblance
+to
+real
+entities
+is
+purely
+coincidental.
+</p>
+</div>
+</section>
+</section>
+<section id="terminology" typeof="bibo:Chapter" resource="#terminology" property="bibo:hasPart">
+<h2 id="h-terminology" resource="#h-terminology">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+2.
+</span>
+Terminology
+</span>
+</h2>
+<div>
+<p>
+This
+document
+attempts
+to
+communicate
+the
+concepts
+outlined
+in
+the
+Web
+Payments
+space
+by
+using
+specific
+terms
+to
+discuss
+particular
+concepts.
+This
+terminology
+is
+included
+below
+and
+linked
+to
+throughout
+the
+document
+to
+aid
+the
+reader:
+</p>
+<dl class="termlist">
+<dt>
+</dt>
+<dt>
+</dt>
+<dt>
+</dt>
+<dt>
+</dt>
+<dt>
+</dt>
+<dt>
+</dt>
+<dt>
+</dt>
+<dt>
+</dt>
+<dt>
+<dfn lt="entity|entities" id="dfn-entity">
+entity
+</dfn>
+</dt>
+<dd>
+A
+person,
+organization,
+or
+software
+agent
+that
+is
+capable
+of
+interacting
+with
+the
+world.
+</dd>
+<dt>
+<dfn id="dfn-four-corner-model">
+<ins class="diff-chg">four
+corner
+model
+</ins></dfn></dt><dd><ins class="diff-chg">
+A
+</ins><a href="#dfn-payment-scheme" class="internalDFN"><ins class="diff-chg">
+payment
+scheme
+</ins></a><ins class="diff-chg">
+which
+includes
+the
+following
+stakeholders:
+the
+</ins><a href="#dfn-payer" class="internalDFN"><ins class="diff-chg">
+payer
+</ins></a><ins class="diff-chg">
+(also
+known
+as
+the
+Cardholder),
+the
+Issuer
+(who
+has
+a
+relationship
+with
+the
+Cardholder),
+the
+Acceptor
+and
+the
+Acquirer
+(which
+has
+a
+relationship
+with
+the
+Acceptor).
+The
+</ins><a href="#dfn-payment-scheme" class="internalDFN"><ins class="diff-chg">
+payment
+scheme
+</ins></a><ins class="diff-chg">
+defines
+the
+rules
+which
+apply
+to
+all
+parties;
+there
+are
+no
+limitations
+as
+to
+who
+may
+join
+the
+scheme,
+as
+long
+as
+the
+requirements
+of
+the
+scheme
+are
+met.
+</ins></dd><dt></dt><dt></dt><dt></dt><dt><dfn lt="payee|payees" id="dfn-payee">
+payee
+</dfn>
+</dt>
+<dd>
+An
+entity
+that
+receives
+funds
+as
+required
+by
+a
+<del class="diff-old">transaction
+.
+</del>
+<ins class="diff-chg">transaction.
+</ins>
+</dd>
+<dt>
+<dfn lt="payer|payers" id="dfn-payer">
+payer
+</dfn>
+</dt>
+<dd>
+An
+entity
+that
+provides
+a
+source
+of
+funds
+as
+required
+by
+a
+<del class="diff-old">transaction
+.
+</del>
+<ins class="diff-chg">transaction.
+</ins>
+</dd>
+<dt>
+</dt>
+<dt>
+<dfn lt="payment instrument|payment instruments" id="dfn-payment-instrument">
+payment
+instrument
+</dfn>
+</dt>
+<dd>
+A
+mechanism
+used
+to
+transfer
+value
+from
+a
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+to
+a
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>.
+Examples:
+Corporate
+Visa
+card,
+personal
+Visa
+card,
+a
+bitcoin
+account,
+a
+PayPal
+account,
+<ins class="diff-new">and
+</ins>
+an
+Alipay
+<del class="diff-old">account,
+etc.
+</del>
+<ins class="diff-chg">account.
+[PSD2]
+any
+personalized
+device(s)
+and/or
+set
+of
+procedures
+agreed
+between
+the
+payment
+service
+user
+and
+the
+payment
+service
+provider
+and
+used
+in
+order
+to
+initiate
+a
+payment
+order.
+[ECB]
+a
+tool
+or
+a
+set
+of
+procedures
+enabling
+the
+transfer
+of
+funds
+from
+a
+payer
+to
+a
+payee.
+</ins>
+</dd>
+<dt>
+</dt>
+<dt>
+</dt>
+<dt>
+<dfn lt="payment processor|payment processors" id="dfn-payment-processor">
+payment
+processor
+</dfn>
+</dt>
+<dd>
+An
+<a href="#dfn-entity" class="internalDFN">
+entity
+</a>
+that
+submits
+and
+processes
+payments
+using
+a
+particular
+<a href="#dfn-payment-instrument" class="internalDFN">
+payment
+instrument
+</a>
+to
+a
+payment
+network.
+Examples:
+Stripe,
+PayPal,
+Authorize.net,
+Atos,
+FedACH.
+</dd>
+<dt>
+<dfn lt="payment scheme|payment schemes" id="dfn-payment-scheme">
+payment
+scheme
+</dfn>
+</dt>
+<dd>
+Sets
+of
+rules
+and
+technical
+standards
+for
+the
+execution
+of
+payment
+<a title="transaction" href="#dfn-transaction" class="internalDFN">
+transactions
+</a>
+that
+have
+to
+be
+followed
+by
+adhering
+entities
+(
+<a title="payment processor" href="#dfn-payment-processor" class="internalDFN">
+payment
+processors
+</a>,
+<a title="payer" href="#dfn-payer" class="internalDFN">
+payers
+</a>
+and
+<a title="payee" href="#dfn-payee" class="internalDFN">
+payees
+</a>
+).
+Examples:
+Visa,
+MasterCard,
+Bitcoin,
+Ripple,
+PayPal,
+Google
+Pay,
+Alipay,
+Yandex
+money,
+ACH,
+SEPA.
+<ins class="diff-new">[ECB]
+a
+set
+of
+interbank
+rules,
+practices
+and
+standards
+necessary
+for
+the
+functioning
+of
+payment
+services.
+</ins>
+</dd>
+<dt>
+</dt>
+<dt>
+<dfn lt="pull payment|pull payments|payee-initiated payment|payee-initiated payments" id="dfn-payee-initiated-payment">
+<ins class="diff-chg">payee-initiated
+payment
+</ins></dfn></dt><dd><ins class="diff-chg">
+Also
+known
+as
+a
+pull
+payment,
+a
+type
+of
+</ins><a href="#dfn-transaction" class="internalDFN"><ins class="diff-chg">
+transaction
+</ins></a><ins class="diff-chg">
+where
+the
+</ins><a href="#dfn-payee" class="internalDFN"><ins class="diff-chg">
+payee
+</ins></a><ins class="diff-chg">
+initiates
+the
+funds
+transfer
+from
+the
+</ins><a href="#dfn-payee" class="internalDFN"><ins class="diff-chg">
+payee
+</ins></a>.<ins class="diff-chg">
+A
+credit
+card
+payment
+is
+an
+example
+of
+a
+pull
+payment.
+</ins></dd><dt><dfn lt="purchase|purchases" id="dfn-purchase">
+purchase
+</dfn>
+</dt>
+<dd>
+Activities
+surrounding
+and
+including
+a
+transaction
+(e.g.,
+discovery
+of
+an
+offer,
+negotiation
+of
+terms,
+selection
+of
+payment
+<del class="diff-old">instrument
+,
+</del>
+<ins class="diff-chg">instrument,
+</ins>
+delivery,
+etc.).
+</dd>
+<dt>
+<del class="diff-old">transaction
+</del>
+<dfn lt="push payment|push payments|payer-initiated payment|payer-initiated payments" id="dfn-payer-initiated-payment">
+<ins class="diff-chg">payer-initiated
+payment
+</ins>
+</dfn>
+</dt>
+<dd>
+<del class="diff-old">An
+exchange
+</del>
+<ins class="diff-chg">Also
+known
+as
+a
+push
+payment,
+a
+type
+</ins>
+of
+<del class="diff-old">value
+(e.g.,
+buying
+or
+selling
+something)
+</del>
+<a href="#dfn-transaction" class="internalDFN">
+<ins class="diff-chg">transaction
+</ins></a><ins class="diff-chg">
+where
+the
+</ins><a href="#dfn-payer" class="internalDFN"><ins class="diff-chg">
+payer
+</ins></a><ins class="diff-chg">
+initiates
+the
+funds
+transfer
+to
+the
+</ins><a href="#dfn-payee" class="internalDFN"><ins class="diff-chg">
+payee
+</ins></a>.<ins class="diff-chg">
+PayPal
+is
+an
+example
+of
+a
+push
+payment.
+</ins>
+</dd>
+<dt>
+</dt>
+<dt>
+<del class="diff-old">Note
+</del>
+</dt>
+<dt>
+</dt>
+<dt>
+<del class="diff-old">There
+are
+</del>
+<dfn lt="transaction|transactions" id="dfn-transaction">
+<ins class="diff-chg">transaction
+</ins></dfn></dt><dd><ins class="diff-chg">
+An
+economic
+exchange
+between
+</ins>
+a
+<del class="diff-old">number
+of
+financial
+industry
+standards
+(such
+as
+ISO20022,
+ISO12812,
+various
+X9
+standards,
+PCI
+DSS,
+</del>
+<a href="#dfn-payer" class="internalDFN">
+<ins class="diff-chg">payer
+</ins></a>
+and
+<del class="diff-old">others)
+that
+define
+payment
+terms.
+The
+Web
+Payments
+Interest
+Group
+has
+as
+a
+goal
+to
+make
+use
+of
+industry-defined
+terms
+in
+its
+deliverables.
+At
+the
+same
+time,
+the
+group
+has
+as
+</del>
+<ins class="diff-chg">one
+or
+more
+</ins><a title="payee" href="#dfn-payee" class="internalDFN"><ins class="diff-chg">
+payees
+</ins></a>.<ins class="diff-chg">
+An
+agreement,
+communication,
+or
+movement
+carried
+out
+between
+</ins>
+a
+<del class="diff-old">goal
+that
+these
+use
+cases
+may
+be
+understood
+by
+both
+payment
+industry
+professionals
+</del>
+<ins class="diff-chg">buyer
+</ins>
+and
+<ins class="diff-new">a
+seller
+to
+exchange
+an
+asset
+for
+payment.
+</ins></dd><dt><dfn lt="transfer order|transfer orders" id="dfn-transfer-order"><ins class="diff-new">
+transfer
+order
+</ins></dfn></dt><dd><ins class="diff-new">
+[ECB]
+an
+order
+or
+message
+requesting
+</ins>
+the
+<del class="diff-old">broader
+Web
+community.
+Thus,
+our
+definitions
+are
+simplified
+and
+few
+in
+number
+here,
+but
+</del>
+<ins class="diff-chg">transfer
+of
+assets
+(e.g.
+funds,
+securities,
+other
+financial
+instruments
+or
+commodities)
+from
+</ins>
+the
+<del class="diff-old">group
+is
+also
+developing
+a
+more
+complete
+glossary
+with
+detailed
+definitions
+and
+mappings
+</del>
+<ins class="diff-chg">debtor
+</ins>
+to
+<del class="diff-old">industry-defined
+terms.
+</del>
+<ins class="diff-chg">the
+creditor.
+</ins></dd><dt>
+</dt>
+</dl>
+</div>
+</section>
+<section id="an-overview-of-the-payment-phases" typeof="bibo:Chapter" resource="#an-overview-of-the-payment-phases" property="bibo:hasPart">
+<h2 id="h-an-overview-of-the-payment-phases" resource="#h-an-overview-of-the-payment-phases">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+3.
+</span>
+An
+Overview
+of
+the
+Payment
+Phases
+</span>
+</h2>
+<p>
+There
+are
+many
+types
+of
+<a href="#dfn-transaction" class="internalDFN">
+transaction
+</a>
+s
+in
+the
+world
+of
+payments,
+including
+person-to-business,
+business-to-business,
+business-to-person,
+government-to-person,
+person-to-government,
+and
+person-to-person.
+In
+this
+document
+we
+focus
+on
+the
+interactions
+between
+a
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+and
+a
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>,
+either
+of
+which
+could
+be
+a
+person,
+business,
+government,
+or
+software
+agent),
+which
+we
+organize
+into
+four
+phases:
+</p>
+<div class="issue">
+<div class="issue-title" aria-level="3" role="heading" id="h-issue2">
+<span>
+Issue
+2
+</span>
+</div>
+<p class="">
+The
+group
+would
+like
+feedback
+related
+to
+the
+general
+structure
+of
+the
+payment
+phases
+from
+individuals
+that
+worked
+on
+ISO20022,
+ISO12812,
+the
+European
+Payment
+Commission,
+and
+various
+X9
+documents
+to
+ensure
+that
+the
+phases
+reflect
+business
+processes
+outlined
+in
+financial
+standardization
+initiatives.
+Feedback
+from
+the
+general
+public
+is
+also
+requested
+to
+see
+if
+non-payment
+professionals
+can
+navigate
+and
+understand
+the
+document
+without
+prior
+payment
+industry
+knowledge.
+</p>
+</div>
+<ol>
+<li>
+Negotiation
+of
+Payment
+Terms
+</li>
+<li>
+Negotiation
+of
+Payment
+Instruments
+</li>
+<li>
+Payment
+Processing
+</li>
+<li>
+Delivery
+of
+Product/Receipt
+and
+Refunds
+</li>
+</ol>
+<p>
+The
+descriptions
+below
+only
+discuss
+the
+interactions
+between
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+and
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>.
+We
+do
+not
+expose
+the
+low-level
+exchanges
+between
+banks,
+card
+associations,
+or
+other
+back-end
+"payment
+clearing"
+parties
+in
+a
+<a href="#dfn-transaction" class="internalDFN">
+transaction
+</a>.
+Those
+details
+will
+be
+discussed
+in
+the
+Interest
+Group's
+work
+on
+architecture
+and
+requirements.
+</p>
+<p>
+Each
+phase
+below
+consists
+of
+a
+series
+of
+steps.
+The
+details
+of
+each
+step
+vary
+by
+<a href="#dfn-payment-scheme" class="internalDFN">
+payment
+scheme
+</a>.
+Some
+steps
+may
+not
+be
+relevant
+at
+certain
+times
+(e.g.,
+depending
+on
+<a href="#dfn-payment-scheme" class="internalDFN">
+payment
+scheme
+</a>
+or
+<a href="#dfn-transaction" class="internalDFN">
+transaction
+</a>
+specifics).
+For
+example,
+some
+<a title="purchase" href="#dfn-purchase" class="internalDFN">
+purchases
+</a>
+do
+not
+involve
+a
+proof
+of
+funds
+or
+proof
+of
+hold.
+ACH
+and
+SEPA
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">
+payment
+schemes
+</a>
+generally
+do
+not
+support
+the
+verification
+of
+available
+funds,
+thus
+in
+these
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">
+payment
+schemes
+</a>
+the
+particular
+proof
+of
+funds
+step
+is
+skipped.
+In
+some
+cases,
+steps
+may
+happen
+in
+a
+slightly
+different
+order
+than
+described
+below.
+</p>
+<p>
+It
+is
+also
+important
+to
+note
+that
+these
+phases
+and
+steps
+may
+be
+interrupted
+at
+various
+times
+(e.g.,
+one
+party
+drops
+out,
+or
+exceptions
+occur
+like
+insufficient
+funds
+or
+a
+regulatory
+block).
+While
+these
+phases
+are
+an
+approximation
+of
+the
+general
+flow
+of
+all
+payments,
+they
+are
+helpful
+in
+structuring
+the
+use
+cases
+such
+that
+it
+is
+easy
+to
+figure
+out
+to
+which
+part
+of
+the
+payment
+process
+a
+particular
+use
+case
+belongs.
+</p>
+<p>
+While
+these
+four
+phases
+may
+apply
+more
+or
+less
+well
+to
+a
+variety
+of
+other
+payment
+scenarios
+such
+as
+person-to-person
+payments,
+those
+topics
+are
+not
+the
+current
+focus
+of
+the
+group.
+We
+plan
+to
+address
+them
+directly
+in
+<a href="#future-work">
+future
+work
+</a>.
+</p>
+<section id="negotiation-of-payment-terms" typeof="bibo:Chapter" resource="#negotiation-of-payment-terms" property="bibo:hasPart">
+<h3 id="h-negotiation-of-payment-terms" resource="#h-negotiation-of-payment-terms">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+3.1
+</span>
+Negotiation
+of
+Payment
+Terms
+</span>
+</h3>
+<p>
+In
+the
+first
+phase
+of
+the
+payment
+process,
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+and
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+negotiate
+the
+terms
+of
+the
+payment.
+</p>
+<ul>
+<li>
+<strong>
+Discovery
+of
+Offer
+</strong>.
+The
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+discovers
+the
+<a title="payee" href="#dfn-payee" class="internalDFN">
+payee's
+</a>
+offer
+(e.g.,
+by
+browsing
+a
+Web
+page
+or
+from
+a
+native
+application).
+</li>
+<li>
+<strong>
+Agreement
+on
+Terms
+</strong>.
+The
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+and
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+agree
+to
+what
+will
+be
+purchased,
+for
+how
+much,
+in
+what
+currency,
+which
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">
+payment
+schemes
+</a>
+or
+loyalty
+programs
+are
+acceptable,
+etc.
+The
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+may
+require
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+to
+authenticate
+themselves.
+The
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+may
+generate
+an
+invoice
+for
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>.
+</li>
+<li>
+<strong>
+Application
+of
+Marketing
+Elements
+</strong>.
+The
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+discovers
+and
+applies
+any
+loyalty
+programs,
+coupons,
+and
+other
+special
+offers
+to
+the
+payment
+terms.
+</li>
+</ul>
+</section>
+<section id="negotiation-of-payment-instruments" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments" property="bibo:hasPart">
+<h3 id="h-negotiation-of-payment-instruments" resource="#h-negotiation-of-payment-instruments">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+3.2
+</span>
+Negotiation
+of
+Payment
+Instruments
+</span>
+</h3>
+<p>
+In
+the
+second
+phase
+of
+the
+payment
+process,
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+and
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+determine
+which
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">
+payment
+instruments
+</a>
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+will
+use
+to
+transfer
+funds
+to
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>.
+</p>
+<ul>
+<li>
+<strong>
+Discovery
+of
+Accepted
+Schemes
+</strong>.
+The
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+discovers
+the
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">
+payment
+instruments
+</a>
+that
+are
+accepted
+by
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>.
+</li>
+<li>
+<strong>
+Selection
+of
+Payment
+Instruments
+</strong>.
+The
+<del class="diff-old">payee
+</del>
+<a href="#dfn-payer" class="internalDFN">
+<ins class="diff-chg">payer
+</ins>
+</a>
+selects
+one
+or
+more
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">
+payment
+instruments
+</a>
+that
+are
+available
+to
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+and
+are
+accepted
+by
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>.
+</li>
+<li>
+<strong>
+Authentication
+to
+Access
+Instruments
+</strong>.
+The
+<a title="payer" href="#dfn-payer" class="internalDFN">
+payer's
+</a>
+access
+to
+the
+<a href="#dfn-payment-instrument" class="internalDFN">
+payment
+instrument
+</a>
+is
+authenticated.
+The
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+consents
+to
+pay.
+Note:
+This
+authentication
+with
+the
+<a href="#dfn-payment-processor" class="internalDFN">
+payment
+processor
+</a>
+is
+distinct
+from
+any
+authentication
+required
+by
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+(such
+as
+when
+a
+merchant
+requires
+a
+customer
+to
+have
+an
+account
+and
+log
+in
+to
+the
+merchant's
+Web
+site).
+</li>
+</ul>
+</section>
+<section id="payment-processing" typeof="bibo:Chapter" resource="#payment-processing" property="bibo:hasPart">
+<h3 id="h-payment-processing" resource="#h-payment-processing">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+3.3
+</span>
+Payment
+Processing
+</span>
+</h3>
+<p>
+The
+third
+phase
+of
+the
+payment
+process
+is
+used
+to
+initiate
+the
+transfer
+of
+funds.
+Depending
+on
+the
+<a href="#dfn-payment-instrument" class="internalDFN">
+payment
+instrument
+</a>,
+the
+transfer
+of
+funds
+may
+be
+verified
+immediately
+or
+only
+after
+several
+days.
+</p>
+<ul>
+<li>
+<strong>
+Initiation
+of
+Processing
+</strong>.
+Depending
+on
+the
+<a href="#dfn-payment-instrument" class="internalDFN">
+payment
+instrument
+</a>,
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+(e.g.,
+when
+using
+PayPal
+or
+Yandex
+Money),
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+(e.g.,
+when
+using
+a
+credit
+card),
+or
+other
+party
+(e.g.,
+bank)
+initiates
+processing.
+</li>
+<li>
+<strong>
+Verification
+of
+Available
+Funds
+</strong>.
+The
+<del class="diff-old">payee
+</del>
+<a href="#dfn-payer" class="internalDFN">
+<ins class="diff-chg">payer
+</ins>
+</a>
+may
+need
+to
+provide
+a
+proof
+of
+funds
+or
+a
+proof
+of
+hold
+to
+the
+<del class="diff-old">payer
+</del>
+<a href="#dfn-payee" class="internalDFN">
+<ins class="diff-chg">payee
+</ins>
+</a>
+before
+finalizing
+payment
+and
+delivery
+of
+the
+product.
+</li>
+<li>
+<strong>
+Authorization
+of
+Transfer
+</strong>.
+The
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+receives
+proof
+that
+the
+transfer
+of
+funds
+has
+been
+authorized.
+</li>
+<li>
+<strong>
+Completion
+of
+Transfer
+</strong>.
+The
+<a href="#dfn-payment-scheme" class="internalDFN">
+payment
+scheme
+</a>
+determines
+the
+details
+of
+payment
+clearing
+and
+settlement.
+Transfer
+times
+may
+vary
+from
+near-realtime
+to
+multiple
+days.
+The
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>,
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>,
+and/or
+third
+parties
+(such
+as
+regulatory
+bodies)
+may
+be
+notified
+as
+each
+stage
+of
+the
+clearing
+and
+settlement
+process
+is
+completed.
+</li>
+</ul>
+</section>
+<section id="delivery-of-product-receipt-and-refunds" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds" property="bibo:hasPart">
+<h3 id="h-delivery-of-product-receipt-and-refunds" resource="#h-delivery-of-product-receipt-and-refunds">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+3.4
+</span>
+Delivery
+of
+Product/Receipt
+and
+Refunds
+</span>
+</h3>
+<p>
+In
+the
+fourth
+phase
+of
+the
+payment
+process,
+the
+<a href="#dfn-transaction" class="internalDFN">
+transaction
+</a>
+is
+completed
+by
+providing
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+with
+a
+receipt
+and/or
+the
+product
+that
+was
+purchased.
+</p>
+<ul>
+<li>
+<strong>
+Delivery
+of
+Product
+</strong>.
+The
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+receives
+goods
+or
+services
+immediately,
+at
+a
+later
+date,
+automatically
+on
+a
+recurring
+basis,
+etc.
+depending
+on
+the
+terms
+of
+the
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>.
+A
+digital
+proof
+of
+payment
+may
+be
+required
+to
+access
+the
+product.
+</li>
+<li>
+<strong>
+Delivery
+of
+Receipt
+</strong>.
+Depending
+on
+the
+<a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">
+payment
+scheme(s)
+</a>
+chosen,
+there
+are
+various
+ways
+and
+times
+that
+a
+receipt
+may
+be
+delivered
+(e.g.,
+credit
+card
+receipt,
+digital
+proof
+of
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>,
+<ins class="diff-new">or
+</ins>
+encrypted
+line-item
+<del class="diff-old">receipt,
+etc.).
+</del>
+<ins class="diff-chg">receipt).
+</ins>
+</li>
+<li>
+<strong>
+Refunds
+</strong>.
+At
+<del class="diff-old">time
+</del>
+<ins class="diff-chg">times
+</ins>
+exceptions
+may
+occur
+(e.g.,
+defective
+<del class="diff-old">product,
+</del>
+<ins class="diff-chg">product
+or
+</ins>
+application
+of
+store
+return
+<del class="diff-old">policy,
+etc.).
+</del>
+<ins class="diff-chg">policy).
+</ins>
+In
+this
+case,
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+initiates
+payment
+to
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>.
+The
+refund
+may
+take
+different
+forms,
+including
+a
+refund
+to
+the
+<a title="payer" href="#dfn-payer" class="internalDFN">
+payer's
+</a>
+payment
+instrument,
+a
+refund
+using
+a
+different
+payment
+scheme,
+or
+store
+credit.
+</li>
+</ul>
+</section>
+</section>
+<section id="a-simple-example-of-the-payment-phases" typeof="bibo:Chapter" resource="#a-simple-example-of-the-payment-phases" property="bibo:hasPart">
+<h2 id="phases-overview" resource="#phases-overview">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+4.
+</span>
+A
+Simple
+Example
+of
+the
+Payment
+Phases
+</span>
+</h2>
+<p>
+The
+following
+scenario
+is
+provided
+to
+aid
+the
+reader
+in
+understanding
+how
+the
+phases
+of
+the
+payment
+process
+apply
+to
+a
+real
+world
+situation.
+In
+this
+scenario,
+we
+follow
+Jill,
+who
+seeks
+a
+new
+outfit
+for
+a
+party.
+She
+selects
+items
+from
+PayToParty,
+which
+is
+a
+brick-and-mortar
+store
+with
+an
+online
+presence.
+She
+chooses
+how
+to
+pay
+and
+the
+items
+are
+delivered
+to
+her
+home
+on
+the
+following
+day.
+</p>
+<p>
+See
+the
+appendix
+for
+<a href="#additional-examples">
+additional
+examples
+of
+the
+payment
+phases
+</a>.
+</p>
+<div class="issue">
+<div class="issue-title" aria-level="3" role="heading" id="h-issue3">
+<span>
+Issue
+3
+</span>
+</div>
+<p class="">
+General
+feedback
+is
+requested
+<del class="diff-old">as
+to
+</del>
+<ins class="diff-chg">on
+</ins>
+whether
+<del class="diff-old">or
+not
+</del>
+this
+section
+is
+<del class="diff-old">helpful
+in
+grounding
+</del>
+<ins class="diff-chg">helpful.
+We
+are
+attempting
+to
+ground
+</ins>
+the
+payment
+phases
+and
+steps
+in
+a
+real
+world
+use
+<del class="diff-old">case
+is
+helpful
+this
+early
+in
+the
+document.
+</del>
+<ins class="diff-chg">case.
+</ins>
+An
+alternative
+would
+be
+removing
+this
+section
+entirely
+if
+the
+preceding
+section
+suffices,
+or
+moving
+this
+narrative
+to
+section
+7
+with
+<ins class="diff-new">the
+</ins>
+other
+examples.
+</p>
+</div>
+<section id="negotiation-of-purchase-terms" typeof="bibo:Chapter" resource="#negotiation-of-purchase-terms" property="bibo:hasPart">
+<h3 id="h-negotiation-of-purchase-terms" resource="#h-negotiation-of-purchase-terms">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+4.1
+</span>
+Negotiation
+of
+Purchase
+Terms
+</span>
+</h3>
+<ul>
+<li>
+<strong>
+Discovery
+of
+Offer
+</strong>:
+Jill
+begins
+her
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>
+at
+home
+on
+her
+laptop,
+where
+she
+browses
+the
+items
+on
+the
+PayToParty
+Web
+site.
+On
+the
+way
+to
+work
+the
+next
+morning,
+she
+explores
+the
+catalog
+further
+from
+a
+native
+app
+on
+her
+smart
+phone.
+Jill
+can't
+decide
+whether
+the
+dress
+displayed
+online
+is
+<a href="https://en.wikipedia.org/wiki/The_dress_(viral_phenomenon)">
+blue
+with
+black
+stripes
+or
+white
+with
+gold
+<del class="diff-old">stripes,
+</del>
+<ins class="diff-chg">stripes
+</ins></a>,
+so
+during
+her
+lunch
+break,
+she
+drops
+into
+the
+PayToParty
+store
+near
+her
+office.
+She
+spots
+a
+few
+more
+items
+that
+she
+thinks
+she'd
+like
+to
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>,
+but
+decides
+to
+wait
+until
+later
+to
+make
+the
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>.
+</li>
+<li>
+<strong>
+Agreement
+on
+Terms
+</strong>:
+That
+same
+evening
+at
+home,
+Jill
+logs
+into
+her
+account
+on
+the
+PayToParty
+Web
+site,
+adding
+her
+<del class="diff-old">preferred
+</del>
+<ins class="diff-chg">chosen
+</ins>
+items
+to
+her
+shopping
+cart.
+The
+total
+price
+appears
+on
+the
+page.
+</li>
+<li>
+<strong>
+Application
+of
+Marketing
+Elements
+</strong>:
+As
+Jill
+prepares
+to
+check
+out,
+PayToParty
+<del class="diff-old">offers
+</del>
+<ins class="diff-chg">notifies
+</ins>
+her
+<ins class="diff-new">of
+</ins>
+a
+discount
+<del class="diff-old">of
+</del>
+<ins class="diff-chg">for
+</ins>
+10%
+if
+she
+uses
+the
+store's
+loyalty
+card
+to
+pay.
+</li>
+</ul>
+</section>
+<section id="negotiation-of-payment-instruments-1" typeof="bibo:Chapter" resource="#negotiation-of-payment-instruments-1" property="bibo:hasPart">
+<h3 id="h-negotiation-of-payment-instruments-1" resource="#h-negotiation-of-payment-instruments-1">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+4.2
+</span>
+Negotiation
+of
+Payment
+Instruments
+</span>
+</h3>
+<ul>
+<li>
+<strong>
+Discovery
+of
+Accepted
+Schemes
+</strong>:
+Given
+where
+Jill
+lives,
+PayToParty
+<del class="diff-old">offers
+her
+</del>
+<ins class="diff-chg">accepts
+</ins>
+payment
+by
+credit
+card,
+debit
+card,
+the
+PayToParty
+loyalty
+card,
+and
+PayPal,
+but
+not
+Jill's
+favorite
+cryptocurrency
+(which
+she
+uses
+on
+other
+sites).
+</li>
+<li>
+<strong>
+Selection
+of
+Payment
+Instruments
+</strong>:
+Jill
+pushes
+the
+"Pay
+Now
+to
+Party!"
+button
+and
+is
+presented
+with
+a
+number
+of
+options
+to
+pay,
+including
+her
+credit
+card,
+her
+PayToParty
+loyalty
+card
+(which
+is
+highlighted
+to
+remind
+her
+of
+the
+discount),
+and
+a
+PayPal
+account.
+There
+is
+also
+a
+gift
+card
+from
+PayToParty
+that
+she
+received
+for
+her
+birthday,
+but
+she
+chooses
+not
+to
+use
+it
+for
+this
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>.
+</li>
+<li>
+<strong>
+Authentication
+to
+Access
+Instruments
+</strong>:
+Jill
+selects
+the
+PayToParty
+loyalty
+card,
+<ins class="diff-new">the
+use
+of
+</ins>
+which
+<del class="diff-old">she
+enabled
+with
+theft-protection,
+</del>
+<ins class="diff-chg">is
+protected
+by
+two-factor
+authentication,
+</ins>
+and
+is
+asked
+to
+input
+a
+code
+that
+is
+sent
+to
+her
+phone
+before
+the
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>
+can
+be
+completed.
+</li>
+</ul>
+</section>
+<section id="payment-processing-1" typeof="bibo:Chapter" resource="#payment-processing-1" property="bibo:hasPart">
+<h3 id="h-payment-processing-1" resource="#h-payment-processing-1">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+4.3
+</span>
+Payment
+Processing
+</span>
+</h3>
+<ul>
+<li>
+<strong>
+Initiation
+of
+Processing
+</strong>.
+PayToParty
+receives
+a
+message
+from
+Jill's
+device
+authorizing
+the
+payment.
+PayToParty
+submits
+the
+message
+to
+their
+<a href="#dfn-payment-processor" class="internalDFN">
+payment
+processor
+</a>,
+requesting
+a
+proof
+of
+hold
+for
+the
+funds.
+</li>
+<li>
+<strong>
+Verification
+of
+Available
+Funds
+</strong>.
+PayToParty
+receives
+a
+proof
+of
+hold
+on
+Jill's
+funds
+for
+the
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>
+price
+of
+the
+goods.
+The
+PayToParty
+night-shift
+employees
+begin
+packing
+her
+purchased
+items
+for
+delivery
+the
+next
+day.
+</li>
+<li>
+<strong>
+Authorization
+of
+Transfer
+</strong>.
+Once
+Jill's
+package
+is
+ready
+to
+go,
+PayToParty
+exchanges
+the
+proof
+of
+hold
+for
+a
+proof
+of
+payment
+by
+re-submitting
+the
+request
+to
+the
+payment
+network.
+They
+receive
+a
+proof
+of
+payment
+from
+the
+<a href="#dfn-payment-processor" class="internalDFN">
+payment
+processor
+</a>.
+</li>
+<li>
+<strong>
+Completion
+of
+Transfer
+</strong>.
+Since
+Jill's
+PayToParty
+loyalty
+card
+operates
+as
+a
+credit
+card,
+PayToParty
+will
+receive
+the
+funds
+in
+their
+normal
+end
+of
+week
+settlement.
+</li>
+</ul>
+</section>
+<section id="delivery-of-product-receipt-and-refunds-1" typeof="bibo:Chapter" resource="#delivery-of-product-receipt-and-refunds-1" property="bibo:hasPart">
+<h3 id="h-delivery-of-product-receipt-and-refunds-1" resource="#h-delivery-of-product-receipt-and-refunds-1">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+4.4
+</span>
+Delivery
+of
+Product/Receipt
+and
+Refunds
+</span>
+</h3>
+<ul>
+<li>
+<strong>
+Delivery
+of
+Receipt
+</strong>.
+Jill's
+cloud-based
+wallet
+receives
+a
+detailed
+line-item
+digital
+receipt
+for
+the
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>.
+</li>
+<li>
+<strong>
+Delivery
+of
+Product
+</strong>.
+Jill's
+package
+goes
+out
+by
+courier
+the
+next
+morning
+and
+is
+on
+her
+doorstep
+before
+she
+leaves
+for
+work.
+</li>
+</ul>
+</section>
+</section>
+<section id="assumptions" typeof="bibo:Chapter" resource="#assumptions" property="bibo:hasPart">
+<h2 id="h-assumptions" resource="#h-assumptions">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+5.
+</span>
+Assumptions
+</span>
+</h2>
+<p>
+The
+use
+cases
+below
+rely
+on
+a
+number
+of
+assumptions
+that
+are
+not
+detailed
+in
+the
+use
+cases
+but
+that
+will
+be
+explored
+in
+more
+detail
+in
+the
+architecture
+and
+requirements
+documents.
+</p>
+<ul>
+<li>
+<strong>
+Connectivity
+</strong>.
+Connectivity
+requirements
+vary
+according
+to
+use
+case.
+The
+types
+of
+connections
+a
+device
+may
+<del class="diff-old">utilize
+</del>
+<ins class="diff-chg">use
+</ins>
+include
+Internet
+connectivity,
+proxied
+connections
+through
+short-range
+radio
+transmissions,
+and
+proximity
+connections
+over
+a
+technology
+such
+as
+Near-Field
+Communication
+(NFC)
+or
+Bluetooth
+Low
+Energy
+(BTLE).
+Some
+use
+cases
+assume
+no
+connectivity
+(e.g.,
+user
+is
+temporarily
+unable
+to
+connect
+to
+a
+mobile
+phone
+network
+or
+a
+WiFi
+hotspot).
+</li>
+<li>
+<strong>
+Registered
+Payment
+Instruments
+</strong>.
+In
+order
+for
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+to
+select
+and
+utilize
+<a title="payment instrument" href="#dfn-payment-instrument" class="internalDFN">
+payment
+instruments
+</a>,
+they
+must
+be
+registered
+in
+some
+way
+and
+discoverable
+by
+a
+browser,
+native
+application,
+or
+other
+software.
+</li>
+<li>
+<strong>
+Security
+</strong>.
+Keys,
+encryption,
+and
+other
+security
+technology
+must
+be
+used
+to
+secure
+sensitive
+information.
+It
+is
+important
+that
+sensitive
+information
+is
+not
+transmitted
+to
+parties
+that
+do
+not
+absolutely
+need
+to
+know
+the
+information
+in
+order
+to
+complete
+the
+<a href="#dfn-transaction" class="internalDFN">
+transaction
+</a>.
+</li>
+<li>
+<strong>
+Identity
+</strong>.
+There
+will
+be
+<del class="diff-old">a
+consistent,
+</del>
+<ins class="diff-chg">an
+</ins>
+interoperable
+identifier
+used
+to
+identify
+the
+participants
+and
+accounts
+in
+a
+Web
+Payments
+transaction.
+</li>
+</ul>
+</section>
+<section id="use-cases-1" typeof="bibo:Chapter" resource="#use-cases-1" property="bibo:hasPart">
+<h2 id="use-cases" resource="#use-cases">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+6.
+</span>
+Use
+Cases
+</span>
+</h2>
+<p>
+This
+section
+examines
+the
+phases
+of
+payment,
+and
+the
+steps
+involved
+in
+each
+phase,
+through
+a
+variety
+of
+use
+cases.
+The
+purpose
+of
+this
+section
+is
+to
+elaborate
+on
+the
+variety
+of
+scenarios
+present
+in
+each
+step
+of
+the
+payment
+process.
+</p>
+<div class="issue">
+<div class="issue-title" aria-level="3" role="heading" id="h-issue4">
+<span>
+Issue
+4
+</span>
+</div>
+<p class="">
+General
+feedback
+is
+requested
+related
+to
+the
+general
+structure
+of
+the
+use
+case
+snippets
+below.
+Are
+they
+focused
+enough
+to
+convey
+each
+topic
+listed?
+Is
+there
+information
+that
+should
+be
+added
+to
+each
+use
+case
+in
+general?
+Would
+more
+elaborate
+use
+cases
+be
+helpful?
+Would
+an
+attempt
+to
+minimize
+each
+existing
+use
+further
+be
+helpful
+in
+scanning
+the
+document
+more
+quickly?
+</p>
+</div>
+<section id="negotiation-of-payment-terms-1" typeof="bibo:Chapter" resource="#negotiation-of-payment-terms-1" property="bibo:hasPart">
+<h3 id="h-negotiation-of-payment-terms-1" resource="#h-negotiation-of-payment-terms-1">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+6.1
+</span>
+Negotiation
+of
+Payment
+Terms
+</span>
+</h3>
+<p>
+</p>
+<section id="discovery-of-offer" typeof="bibo:Chapter" resource="#discovery-of-offer" property="bibo:hasPart">
+<h4 id="h-discovery-of-offer" resource="#h-discovery-of-offer">
+<span property="xhv:role" resource="xhv:heading">
+<span class="secno">
+6.1.1
+</span>
+Discovery
+of
+Offer
+</span>
+</h4>
+<dl id="uc-website" class="dl-horizontal">
+<dt>
+Website
+</dt>
+<dd>
+Penny
+uses
+the
+HobbyCo
+website
+to
+select
+a
+$15
+model
+train
+for
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>.
+</dd>
+<dt>
+<del class="diff-old">Goals
+</del>
+<ins class="diff-chg">Roadmap
+phase
+</ins>
+</dt>
+<dd>
+<del class="diff-old">rapid,
+widespread
+adoption.
+</del>
+<ins class="diff-chg">1
+</ins>
+</dd>
+<dt>
+Motivation
+</dt>
+<dd>
+<del class="diff-old">This
+</del>
+<ins class="diff-chg">A
+human
+being
+seeing
+a
+visual
+offer
+of
+sale
+on
+a
+website
+</ins>
+is
+the
+most
+common
+<del class="diff-old">type
+of
+offer
+</del>
+<ins class="diff-chg">way
+offers
+are
+discovered
+</ins>
+on
+the
+Web
+<del class="diff-old">circa
+2015
+and
+is
+included
+for
+the
+sake
+of
+completeness.
+</del>
+<ins class="diff-chg">today
+(2015).
+</ins>
+</dd>
+</dl>
+<dl id="uc-pos-kiosk" class="dl-horizontal">
+<dt>
+Point
+of
+Sale
+Kiosk
+</dt>
+<dd>
+Cory
+shops
+for
+groceries
+at
+his
+local
+ChowMart,
+scans
+<ins class="diff-new">his
+loyalty
+card
+and
+</ins>
+all
+of
+the
+items
+he
+wants
+to
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>
+at
+the
+automated
+kiosk,
+<ins class="diff-new">requests
+a
+cash
+back
+amount,
+</ins>
+and
+is
+presented
+with
+a
+total
+amount.
+</dd>
+<dt>
+<del class="diff-old">Goals
+</del>
+<ins class="diff-chg">Roadmap
+phase
+</ins>
+</dt>
+<dd>
+<del class="diff-old">Improved
+user
+experience,
+and
+rapid,
+widespread
+adoption.
+</del>
+<ins class="diff-chg">Uncategorized
+</ins>
+</dd>
+<dt>
+Motivation
+</dt>
+<dd>
+Unifying
+<del class="diff-old">POS
+</del>
+<ins class="diff-chg">point
+of
+sale
+</ins>
+interaction
+w/
+the
+Web
+Payments
+architecture
+is
+vital
+for
+the
+success
+of
+this
+work.
+</dd>
+<dt>
+<ins class="diff-new">Accessibility
+</ins></dt><dd><ins class="diff-new">
+At
+present
+kiosks
+are
+rarely
+accessible
+to
+blind
+people,
+people
+with
+low
+vision,
+people
+who
+use
+wheelchairs,
+or
+people
+with
+restricted
+mobility
+that
+makes
+touch
+interaction
+difficult
+or
+impossible.
+They
+don’t
+tend
+to
+offer
+speech
+output,
+any
+ability
+to
+zoom
+or
+customise
+colours,
+may
+be
+difficult
+to
+reach
+from
+a
+wheelchair/sitting
+position,
+and
+do
+not
+accept
+voice
+commands.
+Enabling
+as
+much
+of
+the
+payment
+interaction
+to
+move
+to
+a
+customer-held
+device
+with
+accessibility
+features
+would
+help
+alleviate
+a
+number
+of
+barriers
+that
+exist
+today.
+</ins></dd><dt>
+Privacy
+</dt>
+<dd>
+Cory
+should
+exercise
+control
+over
+how
+much
+he
+wants
+the
+merchant
+to
+be
+able
+to
+track
+his
+activities.
+Programs
+like
+loyalty
+cards
+will
+likely
+involve
+agreement
+to
+more
+data
+with
+the
+merchant.
+<br>
+<ins class="diff-new">Making
+kiosks
+that
+are
+used
+for
+financial
+transactions
+accessible
+introduces
+several
+challenges.
+Speech
+output
+may
+be
+overheard
+by
+people
+nearby,
+increased
+text
+size
+and/or
+visibility
+of
+content
+may
+make
+it
+easier
+for
+other
+people
+to
+read,
+and
+voice
+commands
+may
+also
+be
+overheard.
+</ins>
+</dd>
+</dl>
+<dl id="uc-mobile" class="dl-horizontal">
+<dt>
+Mobile
+</dt>
+<dd>
+<del class="diff-old">Daniel
+</del>
+<ins class="diff-chg">A
+mobile
+device
+can
+be
+used
+to
+discover
+an
+offer
+in
+a
+variety
+of
+ways:
+</ins><ul><li><ins class="diff-chg">
+Hani
+</ins>
+takes
+a
+taxi
+from
+the
+airport
+to
+his
+hotel.
+The
+taxi
+driver
+displays
+the
+total
+with
+his
+mobile
+<del class="diff-old">device
+</del>
+<ins class="diff-chg">device.
+Hani
+</ins>
+and
+<del class="diff-old">offers
+</del>
+<ins class="diff-chg">the
+taxi
+driver
+touch
+their
+mobile
+devices
+to
+each
+other.
+The
+total
+appears
+on
+Hani's
+mobile
+device.
+</ins></li><li><ins class="diff-chg">
+There
+is
+</ins>
+a
+<del class="diff-old">tap-to-pay
+option.
+</del>
+<ins class="diff-chg">Quick
+Response
+Code
+(QR
+Code)
+printed
+on
+the
+bottom
+of
+a
+cup
+that
+Donna
+wants
+to
+buy.
+Donna
+uses
+her
+mobile
+phone
+app
+to
+capture
+the
+QR
+Code,
+view
+the
+price
+of
+the
+item,
+and
+add
+it
+to
+the
+list
+of
+items
+that
+she
+is
+buying
+from
+the
+store.
+</ins></li></ul>
+</dd>
+<dt>
+<del class="diff-old">Goals
+</del>
+<ins class="diff-chg">Roadmap
+phase
+</ins>
+</dt>
+<dd>
+<del class="diff-old">Improved
+user
+experience,
+Greater
+security,
+Innovation,
+Automatability,
+and
+rapid,
+widespread
+adoption.
+</del>
+<ins class="diff-chg">Uncategorized
+</ins>
+</dd>
+<dt>
+Motivation
+</dt>
+<dd>
+Unifying
+the
+way
+<del class="diff-old">tap-to-pay
+</del>
+<ins class="diff-chg">proximity
+mobile
+</ins>
+offers
+work
+with
+the
+Web
+Payments
+architecture
+would
+help
+ensure
+ubiquity.
+</dd>
+<dt>
+<ins class="diff-new">Accessibility
+</ins></dt><dd><ins class="diff-new">
+An
+auditory
+cue
+notifying
+people
+that
+have
+low
+vision
+or
+are
+blind
+that
+a
+payment
+offer/invoice
+is
+awaiting
+their
+response
+as
+well
+as
+providing
+guidance
+on
+how
+close
+their
+payment
+device
+is
+to
+the
+payment
+terminal
+would
+be
+helpful.
+</ins></dd><dt>
+Exceptions
+</dt>
+<dd>
+No
+mobile
+phone
+connectivity
+<del class="diff-old">(visiting
+</del>
+<ins class="diff-chg">(e.g.
+visiting
+</ins>
+a
+different
+<del class="diff-old">country,
+</del>
+<ins class="diff-chg">country
+or
+</ins>
+trip
+occurs
+outside
+the
+range
+of
+a
+mobile
+<del class="diff-old">network,
+etc.)
+</del>
+<ins class="diff-chg">network).
+</ins>
+</dd>
+</dl>
+<dl id="uc-freemium" class="dl-horizontal">
+<dt>
+Freemium
+</dt>
+<dd>
+<del class="diff-old">Ricki
+</del>
+<ins class="diff-chg">Chaoxiang
+</ins>
+plays
+his
+favorite
+native
+app
+game
+and
+wants
+to
+upgrade
+his
+avatar
+with
+a
+few
+extra
+<del class="diff-old">"power-ups."
+</del>
+<ins class="diff-chg">"power-ups".
+</ins>
+Clicking
+on
+a
+power-up
+displays
+the
+price.
+</dd>
+<dt>
+<del class="diff-old">Goals
+</del>
+<ins class="diff-chg">Roadmap
+phase
+</ins>
+</dt>
+<dd>
+<del class="diff-old">Improved
+user
+experience,
+Innovation,
+and
+Transparency.
+</del>
+<ins class="diff-chg">Uncategorized
+</ins>
+</dd>
+<dt>
+Motivation
+</dt>
+<dd>
+Many
+of
+the
+very
+successful
+games
+these
+days
+run
+on
+the
+freemium
+model,
+but
+are
+tied
+to
+specific
+app
+stores.
+Providing
+an
+app-store
+agnostic
+mechanism
+to
+pay
+for
+items
+in
+freemium
+games
+would
+give
+players
+and
+developers
+more
+choices.
+</dd>
+</dl>
+<del class="diff-old">6.1.1.1
+Non-Essential
+Use
+Cases
+</del>
+<dl id="uc-email" class="dl-horizontal">
+<dt>
+<del class="diff-old">E-mail
+</del>
+<ins class="diff-chg">Email
+</ins>
+</dt>
+<dd>
+A
+GroupBuyCo
+customer
+receives
+an
+offer
+by
+email
+to
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>
+the
+deal
+of
+the
+day.
+</dd>
+<dt>
+<del class="diff-old">Goals
+</del>
+<ins class="diff-chg">Roadmap
+phase
+</ins>
+</dt>
+<dd>
+<del class="diff-old">Improved
+user
+experience,
+and
+Automatability.
+</del>
+<ins class="diff-chg">Uncategorized
+</ins>
+</dd>
+<dt>
+Motivation
+</dt>
+<dd>
+Unifying
+how
+people
+initiate
+payments
+from
+email,
+at
+a
+<del class="diff-old">Point
+</del>
+<ins class="diff-chg">point
+</ins>
+of
+<del class="diff-old">Sale,
+</del>
+<ins class="diff-chg">sale,
+</ins>
+and
+via
+a
+Web
+site
+will
+help
+ensure
+the
+ubiquity
+of
+the
+Web
+payment
+technology
+platform.
+</dd>
+<dt>
+Privacy
+/
+Security
+</dt>
+<dd>
+It
+is
+important
+to
+recognize
+that
+initiating
+a
+payment
+from
+within
+an
+email
+application
+could
+lead
+to
+a
+wholly
+new
+category
+of
+phishing/fraud.
+</dd>
+</dl>
+<dl id="uc-hold-funds" class="dl-horizontal">
+<dt>
+Hold
+Funds
+</dt>
+<dd>
+Renne
+checks
+into
+a
+hotel
+and
+is
+asked
+for
+a
+deposit
+for
+any
+damages
+to
+the
+room.
+</dd>
+<dt>
+<del class="diff-old">Goals
+</del>
+<ins class="diff-chg">Roadmap
+phase
+</ins>
+</dt>
+<dd>
+<del class="diff-old">Improved
+user
+experience,
+Increased
+user
+choice,
+and
+rapid,
+widespread
+adoption.
+</del>
+<ins class="diff-chg">Uncategorized
+</ins>
+</dd>
+<dt>
+Motivation
+</dt>
+<dd>
+<del class="diff-old">By
+design,
+some
+</del>
+<ins class="diff-chg">Some
+</ins>
+<a title="transaction" href="#dfn-transaction" class="internalDFN">
+transactions
+</a>,
+<ins class="diff-chg">such
+as
+a
+hold
+of
+funds,
+</ins>
+do
+not
+<ins class="diff-new">always
+</ins>
+reach
+<del class="diff-old">completion.
+Some
+</del>
+<ins class="diff-chg">completion
+and
+</ins>
+are
+<del class="diff-old">merely
+there
+</del>
+<ins class="diff-chg">primarily
+used
+</ins>
+to
+protect
+the
+<a href="#dfn-payee" class="internalDFN">
+payee
+</a>
+<del class="diff-old">(e.g.,
+in
+</del>
+<ins class="diff-chg">from
+negligence
+on
+</ins>
+the
+<del class="diff-old">event
+</del>
+<ins class="diff-chg">part
+</ins>
+of
+<del class="diff-old">questionable
+judgment
+by
+</del>
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+<del class="diff-old">).
+</del>
+<ins class="diff-chg">(e.g.,
+such
+as
+a
+</ins><a href="#dfn-payer" class="internalDFN"><ins class="diff-chg">
+payer
+</ins></a><ins class="diff-chg">
+damaging
+a
+hotel
+room).
+</ins>
+</dd>
+<dt>
+Exceptions
+</dt>
+<dd>
+Software
+acting
+on
+the
+<a title="payer" href="#dfn-payer" class="internalDFN">
+payer's
+</a>
+behalf
+may
+keep
+track
+of
+exactly
+how
+much
+money
+the
+<a href="#dfn-payer" class="internalDFN">
+payer
+</a>
+has
+<ins class="diff-new">available
+</ins>
+and
+not
+allow
+them
+to
+process
+the
+offer.
+</dd>
+</dl>
+<dl id="uc-preauth" class="dl-horizontal">
+<dt>
+Pre-authorization
+</dt>
+<dd>
+<del class="diff-old">George
+</del>
+<ins class="diff-chg">Krishna
+</ins>
+pulls
+up
+to
+a
+pump
+at
+a
+petrol
+station.
+His
+in-vehicle
+application
+recognizes
+the
+station
+location
+and
+the
+pump.
+The
+pump
+communicates
+which
+fuels
+it
+has
+and
+their
+price
+in
+an
+offer.
+<del class="diff-old">George's
+</del>
+<ins class="diff-chg">Krishna's
+</ins>
+car
+asks
+if
+he
+wants
+to
+approve
+a
+fill
+up
+for
+up
+to
+€35.
+</dd>
+<dt>
+<del class="diff-old">Goals
+</del>
+<ins class="diff-chg">Roadmap
+phase
+</ins>
+</dt>
+<dd>
+<del class="diff-old">Improved
+user
+experience,
+Greater
+security,
+Innovation,
+Transparency,
+Automatability,
+and
+rapid,
+widespread
+adoption.
+</del>
+<ins class="diff-chg">Uncategorized
+</ins>
+</dd>
+<dt>
+Motivation
+</dt>
+<dd>
+Some
+offers
+are
+not
+aware
+of
+the
+final
+price
+but
+would
+rather
+set
+limits
+on
+the
+amount
+of
+the
+<a href="#dfn-purchase" class="internalDFN">
+purchase
+</a>
+before
+a
+particular
+metered
+good
+or
+service
+is
+delivered.
+</dd>
+<dt>
+Privacy
+</dt>
+<dd>
+Due
+to
+the
+sensitivity
+of
+location
+data,
+individuals
+should
+be
+able
+to
+make
+small
+fuel
+<a title="purchase" href="#dfn-purchase" class="internalDFN">
+purchases
+</a>
+in
+a
+way
+that
+respects
+their
+privacy.
+</dd>
+<dt>
+Security
+</dt>
+<dd>
+Automated
+<a title="purchase" href="#dfn-purchase" class="internalDFN">
+purchases
+</a>
+(e.g,.
+by
+a
+vehicle)
+<del class="diff-old">should
+</del>
+<ins class="diff-chg">may
+</ins>
+involve
+increased
+<ins class="diff-new">logging
+and
+</ins>
+security
+(e.g.,
+a
+second
+factor
+of
+authentication).
+</dd>
+<dt>
+<ins class="diff-new">Regulatory
+</ins></dt><dd><ins class="diff-new">
+If
+a
+pre-authorization
+is
+initiated
+by
+a
+software
+agent
+(such
+as
+a
+vehicle)
+due
+to
+a