--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/WD/use-cases/2015-04-16/index.html Fri Apr 03 00:52:22 2015 -0400
@@ -0,0 +1,2837 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document " 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</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+
+
+
+ <style type="text/css">
+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" 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</h1>
+
+ <h2 id="w3c-first-public-working-draft-16-april-2015"><abbr title="World Wide Web Consortium">W3C</abbr> First Public Working Draft <time property="dcterms:issued" class="dt-published" datetime="2015-04-16">16 April 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-20150416/">http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/</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>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"><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"><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="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 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>
+ This document was published by the <a href="http://www.w3.org/blog/wpig/">Web Payments Interest Group</a> as a First Public Working Draft.
+
+ This document is intended 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@w3.org">public-webpayments-comments@w3.org@w3.org</a>
+ (<a href="mailto:public-webpayments-comments@w3.org-request@w3.org?subject=subscribe">subscribe</a>,
+ <a href="http://lists.w3.org/Archives/Public/public-webpayments-comments@w3.org/">archives</a>).
+
+
+
+
+
+
+ All comments are welcome.
+
+
+ </p>
+
+
+
+ <p>
+ Publication as a First Public 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="#how-this-document-is-organized" class="tocxref"><span class="secno">1.2 </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><ul class="toc"></ul></li><li class="tocline"><a href="#agreement-on-terms" class="tocxref"><span class="secno">6.1.2 </span>Agreement on Terms</a><ul class="toc"></ul></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><ul class="toc"></ul></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><ul class="toc"></ul></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><ul class="toc"></ul></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-cheque-payment" class="tocxref"><span class="secno">7.5 </span>Electronic Cheque Payment</a></li><li class="tocline"><a href="#credit-transfer-direct-debit" class="tocxref"><span class="secno">7.6 </span>Credit Transfer / Direct Debit</a></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 on the Web. This will help achieve
+greater interoperability among merchants and their customers,
+payment providers, software vendors, mobile operators, 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 cheques, 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 pay cheque to pay cheque, do
+not have access to savings accounts or low-fee cheque 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="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.2 </span>How this Document is Organized</span></h3>
+
+ <p>
+This document is organized as follows:
+ </p>
+
+ <ul>
+ <li>
+Section 2 defines basic payment terms.
+ </li>
+ <li>
+Section 3 describes a common payment flow at a high
+level. The group expects to work on additional
+payment flows in future work.
+ </li>
+ <li>
+Section 4 is a specific narrative, labeled according
+to the steps of section 3. Section 7 describes
+additional familiar narratives to give a more complete picture
+of how the payment phases apply.
+ </li>
+ <li>
+Section 6 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>
+Goals. How the use case advances one or more of the
+<a href="https://www.w3.org/Payments/IG/wiki/ExecSummary#Goals">goals
+for an interoperable Web payments framework</a>.
+ </li>
+ <li>
+Motivation. This is commentary 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>
+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>
+ <li>
+Accessibility. Accessibility considerations (e.g., in multi-factor
+authentication, management of biometrics in the case of users with some
+disabilities).
+ </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>
+
+ <p>
+The Interest Group (currently) regards some of the use cases as "essential" to
+addressing their
+<a href="https://www.w3.org/Payments/IG/wiki/ExecSummary#Goals">goals</a> and
+others as "non-essential."
+ </p>
+
+ <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>
+ <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>
+ <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-payee">payee</dfn></dt>
+ <dd>
+An <a href="#dfn-entity" class="internalDFN">entity</a> that receives funds as required by a
+<a href="#dfn-transaction" class="internalDFN">transaction</a>.
+ </dd>
+ <dt><dfn id="dfn-payer">payer</dfn></dt>
+ <dd>
+An <a href="#dfn-entity" class="internalDFN">entity</a> that provides a source of funds as required by a
+<a href="#dfn-transaction" class="internalDFN">transaction</a>.
+ </dd>
+ <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, an Alipay account, etc.
+ </dd>
+ <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.
+ </dd>
+ <dt><dfn id="dfn-purchase">purchase</dfn></dt>
+ <dd>
+Activities surrounding and including a <a href="#dfn-transaction" class="internalDFN">transaction</a> (e.g., discovery of
+an offer, negotiation of terms, selection of <a href="#dfn-payment-instrument" class="internalDFN">payment instrument</a>,
+delivery, etc.).
+ </dd>
+ <dt><dfn id="dfn-transaction">transaction</dfn></dt>
+ <dd>
+An exchange of value (e.g., buying or selling something)
+ </dd>
+ </dl>
+
+ <div class="note"><div class="note-title" aria-level="3" role="heading" id="h-note2"><span>Note</span></div><p class="">
+There are a number of financial industry standards (such as
+ISO20022, ISO12812, various X9 standards, PCI DSS, and 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 a goal that these use cases may be understood by both
+payment industry professionals and the broader Web community. Thus, our
+definitions are simplified and few in number here, but the group is
+also developing a
+<a href="https://www.w3.org/Payments/IG/wiki/GlossaryReference">more complete glossary</a>
+with detailed definitions and mappings to industry-defined terms.
+ </p></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
+payer 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-payee" class="internalDFN">payee</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-payee" class="internalDFN">payee</a> may
+need to provide a proof of funds or a proof of hold to the <a href="#dfn-payer" class="internalDFN">payer</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>, encrypted line-item receipt, etc.).
+ </li>
+ <li>
+<strong>Refunds</strong>. At time exceptions may occur (e.g., defective
+product, application of store return policy, etc.). 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 as to whether or not this section is helpful in
+grounding the payment phases and steps in a real world use case is helpful this
+early in the document. An alternative would be removing this section
+entirely if the preceding section suffices, or moving this narrative to section 7 with 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 blue with black stripes or white
+with gold stripes, 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
+preferred 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 offers her a discount of 10% if she uses the store's
+loyalty card to pay.
+ </li>
+ <ul>
+ </ul></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 offers her 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, which she enabled with theft-protection,
+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>
+ </ul></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>
+ </ul></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>
+ </ul></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 utilize 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 a consistent, 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 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>Goals</dt>
+ <dd>
+rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+This is the most common type of offer on the Web circa 2015 and is included
+for the sake of completeness.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Point of Sale Kiosk</dt>
+ <dd>
+Cory shops for groceries at his local ChowMart, scans all of the items he
+wants to <a href="#dfn-purchase" class="internalDFN">purchase</a> at the automated kiosk, and is presented with a
+total amount.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience, and rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+Unifying POS interaction w/ the Web Payments architecture is vital for the
+success of this work.
+ </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.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Mobile</dt>
+ <dd>
+Daniel takes a taxi from the airport to his hotel. The taxi driver
+displays the total with his mobile device and offers a tap-to-pay option.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience, Greater security, Innovation, Automatability, and
+rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+Unifying the way tap-to-pay offers work with the Web Payments architecture
+would help ensure ubiquity.
+ </dd>
+ <dt>Exceptions</dt>
+ <dd>
+No mobile phone connectivity (visiting a different country, trip occurs
+outside the range of a mobile network, etc.)
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Freemium</dt>
+ <dd>
+Ricki 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>Goals</dt>
+ <dd>
+Improved user experience, Innovation, and Transparency.
+ </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>
+
+ <section id="non-essential-use-cases" typeof="bibo:Chapter" resource="#non-essential-use-cases" property="bibo:hasPart">
+ <h5 id="h-non-essential-use-cases" resource="#h-non-essential-use-cases"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.1.1.1 </span>Non-Essential Use Cases</span></h5>
+
+ <dl class="dl-horizontal">
+ <dt>E-mail</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>Goals</dt>
+ <dd>
+Improved user experience, and Automatability.
+ </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 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>Goals</dt>
+ <dd>
+Improved user experience, Increased user choice, and rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+By design, some <a title="transaction" href="#dfn-transaction" class="internalDFN">transactions</a> do not reach
+completion. Some are merely there to protect the <a href="#dfn-payee" class="internalDFN">payee</a> (e.g., in the
+event of questionable judgment by the <a href="#dfn-payer" class="internalDFN">payer</a>).
+ </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 and not allow them to
+process the offer.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Pre-authorization</dt>
+ <dd>
+George 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. George's car asks if he wants to
+approve a fill up for up to €35.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience, Greater security, Innovation, Transparency,
+Automatability, and rapid, widespread adoption.
+ </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) should involve increased security (e.g., a second factor of authentication).
+ </dd>
+ </dl>
+
+ <dl 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>Goals</dt>
+ <dd>
+Increased user choice, Improved user experience, Innovation, Lower Costs,
+Transparency, Automatability, Portability, Monetization,
+and rapid, widespread adoption.
+ </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 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>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Innovation,
+Transparency, and
+Automatability
+ </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>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Trial-ware</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>Goals</dt>
+ <dd>
+Improved user experience,
+Monetization,
+and rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+There is a fairly large trial-ware 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 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>Goals</dt>
+ <dd>
+Improved user experience,
+Innovation,
+Monetization,
+and rapid, widespread adoption.
+ </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 distract the driver of the vehicle. Voice controls and other
+techniques can be used to reduce driver distraction.
+ </dd>
+ </dl>
+
+ </section>
+ </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 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>Goals</dt>
+ <dd>
+Improved user experience,
+Greater security,
+Regulatory acceptance,
+Innovation,
+Transparency,
+Automatability, and
+Portability.
+ </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>Exceptions</dt>
+ <dd>A <a href="#dfn-transaction" class="internalDFN">transaction</a> may fail if a required credential is not available.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Privacy Protection</dt>
+ <dd>
+Tibor orders assorted chocolates from CandyCo. CandyCo only needs Tibor's
+verified shipping address to send him the chocolates. With Tibor's
+authorization, his payment software transmits only his shipping address to
+CandyCo. Tibor's privacy is protected from the candy store, which did not
+require Tibor's name, email address, or any other personally identifying
+information to complete the <a href="#dfn-transaction" class="internalDFN">transaction</a>.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience, and Greater security.
+ </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 class="dl-horizontal">
+ <dt>Need to Know</dt>
+ <dd>
+PayCo 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>Goals</dt>
+ <dd>
+Greater security, and Regulatory acceptance.
+ </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 class="dl-horizontal">
+ <dt>One-time Payment</dt>
+ <dd>
+Jamie wishes to pay for a single article from a market analyst.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience
+ </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 class="dl-horizontal">
+ <dt>Invoices</dt>
+ <dd>
+Will 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 Will.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience,
+Greater security,
+Transparency,
+Automatability,
+Portability, and
+Monetization.
+ </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>
+
+ <section id="non-essential-use-cases-1" typeof="bibo:Chapter" resource="#non-essential-use-cases-1" property="bibo:hasPart">
+ <h5 id="h-non-essential-use-cases-1" resource="#h-non-essential-use-cases-1"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.1.2.1 </span>Non-essential Use Cases</span></h5>
+
+ <dl class="dl-horizontal">
+ <dt>Subscription</dt>
+ <dd>
+Jeff subscribes to a site that provides a monthly analysis of the world
+of finance.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience,
+Transparency, and
+Automatability.
+ </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>
+ </dl>
+
+ <dl 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>
+Benny 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>Goals</dt>
+ <dd>
+Improved user experience,
+Greater security,
+Innovation, and
+Automatability
+ </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>
+ </dl>
+
+ <dl 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>Goals</dt>
+ <dd>
+Improved user experience.
+ </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>
+
+ <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 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>Goals</dt>
+ <dd>
+Automatability and Portability.
+ </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 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>Goals</dt>
+ <dd>
+Improved user experience and Portability.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+Loyalty cards may be used at multiple locations to effect the price of a
+particular good.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Store Credit</dt>
+ <dd>
+When Rick arrives as the self-checkout kiosk,
+he scans five dress shirts and two new pairs of slacks.
+The kiosk mentions that Rick could save 15% off of his <a href="#dfn-purchase" class="internalDFN">purchase</a>
+if he makes the <a href="#dfn-purchase" class="internalDFN">purchase</a> using store credit. He accepts the offer and
+a new store credit card is placed in his payment application on his mobile
+phone.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Automatability,
+Portability,
+Monetization,
+and rapid, widespread adoption.
+ </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 class="dl-horizontal">
+ <dt>Ubiquitous Schemes</dt>
+ <dd>
+A game store Web site accepts payment via credit card, e-cheque, and
+operator billing.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Minimal standardization,
+Lower Costs,
+Automatability,
+and rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>We have a goal for the Web payment architecture
+ to support existing ubiquitous <a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a> without changes to how they operate.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Emerging Schemes</dt>
+ <dd>
+CrowdFundCo supports Bitcoin, Ripple, Google Wallet, and PayPal.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Minimal standardization,
+Lower Costs,
+Automatability,
+and rapid, widespread adoption.
+ </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 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>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Automatability,
+Portability,
+and rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+A <a href="#dfn-payer" class="internalDFN">payer</a> will most likely use multiple payment services over
+time. It is important to ensure that the payment services presented
+to them are consistent across devices, even ones that they have never used
+before.
+ </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 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>
+ </ul>
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Innovation,
+Transparency,
+Portability,
+and rapid, widespread adoption.
+ </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 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>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Innovation,
+Lower Costs,
+Transparency,
+Automatability,
+and rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>Payment solutions providers can make payments easier and faster through automation.
+ </dd>
+ </dl>
+
+ <dl 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>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Innovation, and
+Monetization.
+ </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>
+
+ </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 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>
+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>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Greater security,
+Minimal standardization,
+Regulatory acceptance,
+Innovation,
+and rapid, widespread adoption.
+ </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
+ biometric verification to improve accessibility.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
+ <dt>Regulatory Blocks</dt>
+ <dd>
+PayCo must ensure that their customers do not appear on any regulatory
+blacklists when performing <a href="#dfn-transaction" class="internalDFN">transaction</a>s above a certain monetary amount.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Regulatory acceptance, and Automatability.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+Easing compliance with Know Your Customer (KYC) and
+Anti-Money Laundering (AML) regulations
+will ensure safer and faster <a title="payment scheme" href="#dfn-payment-scheme" class="internalDFN">payment schemes</a>.
+ </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>
+
+ <section id="non-essential-use-cases-2" typeof="bibo:Chapter" resource="#non-essential-use-cases-2" property="bibo:hasPart">
+ <h5 id="h-non-essential-use-cases-2" resource="#h-non-essential-use-cases-2"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.3.1 </span>Non-essential Use Cases</span></h5>
+ <dl 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>
+Sarah 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>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Greater security,
+Minimal standardization,
+Regulatory acceptance,
+Innovation,
+and rapid, widespread adoption.
+ </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
+ biometric verification to improev accessibility.
+ </dd>
+ </dl>
+ </section>
+
+ </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-note3"><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 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>
+ </ul>
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Automatability, and rapid, widespread adoption.
+ </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 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 Vladamir (in Moscow) using
+his Ripple client, which converts the currency from US Dollars to Rubels in
+transit.
+ </li>
+ </ul>
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience,
+Greater security,
+Innovation, and
+Automatability.
+ </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>
+ </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 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>Goals</dt>
+ <dd>
+Improved user experience, and Transparency.
+ </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>
+
+ <section id="non-essential-use-cases-3" typeof="bibo:Chapter" resource="#non-essential-use-cases-3" property="bibo:hasPart">
+ <h5 id="h-non-essential-use-cases-3" resource="#h-non-essential-use-cases-3"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.3.2.1 </span>Non-essential Use Cases</span></h5>
+ <dl 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>Goals</dt>
+ <dd>
+Greater security and Transparency.
+ </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 engaging the
+<a href="#dfn-payer" class="internalDFN">payer</a> may be costly.
+ </dd>
+ </dl>
+
+ </section>
+ </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 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>
+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>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Greater security,
+Regulatory acceptance,
+Innovation,
+Transparency,
+Automatability, and rapid, widespread adoption.
+ </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 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>
+Sophie 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 cheque 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>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Transparency,
+Automatability,
+and rapid, widespread adoption.
+ </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>
+
+ <section id="non-essential-use-cases-4" typeof="bibo:Chapter" resource="#non-essential-use-cases-4" property="bibo:hasPart">
+ <h5 id="h-non-essential-use-cases-4" resource="#h-non-essential-use-cases-4"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.3.4.1 </span>Non-essential Use Cases</span></h5>
+ <dl class="dl-horizontal">
+ <dt>Notifications</dt>
+ <dd>
+Gavin sends an electronic cheque 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>Goals</dt>
+ <dd>
+Innovation,
+Automatability,
+and rapid, widespread adoption.
+ </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>
+
+ <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 class="dl-horizontal">
+ <dt>Physical Goods</dt>
+ <dd>
+Giralt orders a bicycle for his daughter through BikeSmart online. The
+bicycle is delivered a few days later with a QRCode attached to the package
+that only Giralt can access.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+rapid, widespread adoption.
+ </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 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>Goals</dt>
+ <dd>
+Improved user experience,
+Greater security,
+Minimal standardization,
+Innovation,
+Automatability,
+Portability, and
+Monetization.
+ </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>
+
+ </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 class="dl-horizontal">
+ <dt>Electronic Receipts</dt>
+ <dd>
+George pulls up to a pump at a petrol station. He pays electronically using a
+credit card (via his phone). An electronic receipt for the <a href="#dfn-purchase" class="internalDFN">purchase</a>
+from the gas station is displayed on his phone.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Improved user experience,
+Greater security,
+Innovation,
+Automatability, and
+Portability.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+Electronic receipts will 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 / Security</dt>
+ <dd>
+Many merchants want to ensure that receipts are not readable by any party
+between them and their customer.
+ </dd>
+ </dl>
+
+ <dl 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>Goals</dt>
+ <dd>
+Improved user experience,
+Innovation,
+Portability,
+and rapid, widespread adoption.
+ </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 class="dl-horizontal">
+ <dt>Common Refunds</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 they 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>Goals</dt>
+ <dd>
+Improved user experience,
+Greater security,
+Regulatory acceptance,
+Innovation,
+Automatability,
+Portability,
+and rapid, widespread adoption.
+ </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>
+ </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="#phase-example">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 4 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
+points card that 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, Square, etc.
+ </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, Inc. 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, Anna 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>: Anna 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>: Anna 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>: Anna chooses Alipay for
+payment.
+ </li>
+
+ <li>
+<strong>Authentication to Access Instruments</strong>: Anna logs in the Alipay
+with her account name and password. Anna is told that she will pay for the
+airline ticket with 600RMB and she confirms it. Anna 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>: Anna'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 Anna'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 Anna'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
+Anna 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-cheque-payment" typeof="bibo:Chapter" resource="#electronic-cheque-payment" property="bibo:hasPart">
+ <h3 id="h-electronic-cheque-payment" resource="#h-electronic-cheque-payment"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.5 </span>Electronic Cheque Payment</span></h3>
+ <p><em>To be completed</em>.</p>
+ </section>
+
+ <section id="credit-transfer-direct-debit" typeof="bibo:Chapter" resource="#credit-transfer-direct-debit" property="bibo:hasPart">
+ <h3 id="h-credit-transfer-direct-debit" resource="#h-credit-transfer-direct-debit"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.6 </span>Credit Transfer / Direct Debit</span></h3>
+ <p><em>To be completed</em>.</p>
+ </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>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>
\ No newline at end of file