--- a/latest/use-cases/index.html Mon Dec 15 01:15:54 2014 -0500
+++ b/latest/use-cases/index.html Mon Jan 12 00:44:00 2015 -0500
@@ -22,7 +22,7 @@
// previousMaturity: "CG-DRAFT",
// if there a publicly available Editor's Draft, this is the link
- //edDraftURI: "https://web-payments.org/specs/source/use-cases",
+ edDraftURI: "https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
@@ -34,18 +34,20 @@
// editors, add as many as you like
// only "name" is required
editors: [
- { name: "Pat Doe", url: "http://patdoe.example.com/",
- company: "ACME", companyURL: "http://acme.example.com/" },
+ { name: "Manu Sporny", url: "https://manu.sporny.org/",
+ company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
- //authors: [
- // { name: "Your Name", url: "http://example.org/",
- // company: "Your Company", companyURL: "http://example.com/" },
- //],
+ authors: [
+ { name: "David Ezell", url: "http://example.org/",
+ company: "NACS", companyURL: "http://www.nacsonline.com/" },
+ { name: "Manu Sporny", url: "https://manu.sporny.org/",
+ company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
+ ],
// maximum level of table of contents
maxTocLevel: 2,
@@ -75,13 +77,25 @@
<body>
<section id='abstract'>
<p>
-Abstract goes here.
+This document outlines and prioritizes desired functionality that the Open
+Web Platform should provide in the area of Web Payments. The purpose of this
+document is to provide future W3C Working Groups with specific requirements
+and functionality that should be achievable with new features that they
+add to the Open Web Platform.
</p>
</section>
<section id='sotd'>
<p>
-Custom Status of the Document language goes here.
+This document is a work in progress and is being released early and often
+using an agile process; it is incomplete.
+ </p>
+The Web Payments IG has only had the opportunity to review a handful of the
+40+ use cases, 120+ requirements, and 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. Expect this document to be rapidly iterated upon.
</p>
</section>
@@ -93,6 +107,254 @@
</section>
<section>
+ <h2>High Priority Use Cases</h2>
+ <p>
+The following use cases have been identified by the Web Payments Interest
+Group as high-priority items.
+ </p>
+
+ <section>
+ <h3>Purchase Request</h3>
+ <p>
+A buyer selects a product or service to purchase on a website. The website
+generates a payment request that is sent to the buyer's payment processor
+for processing.
+ </p>
+
+ <section>
+ <h4>Examples</h4>
+ <ul>
+ <li>
+Customer POV: Penny logs into the HobbyCo website, providing her payment
+processor credential in the process. Penny selects a model train for purchase.
+The store generates a payment request which is then forwarded to her preferred
+payment processor.
+ </li>
+ <li>
+Merchant POV: A FarmCo customer selects a 10 kg bag of grass seed for purchase.
+FarmCo performs a few database lookups to determine the current market price
+of grass seed and generates an invoice for the purchase of the selected
+product. The invoice is transmitted to the customer's Payment Agent, which
+then transmits the invoice to the customer's payment processor for processing.
+ </li>
+ <li>
+Payment Processor POV: A PayCo customer receives a payment request to send
+funds to RetailCo. Upon approval by the customer, the transmission of funds
+are initiated from the customer's financial account to RetailCo's
+financial account.
+ </li>
+ </ul>
+ </section>
+
+ <section>
+ <h4>Details</h4>
+ <p>
+All payments start somewhere and they typically follow the same basic flow:
+1) a payer requests a product or service, 2) the payee advertises the final
+price for the product or service, and 3) the payer initiates payment to the
+payee. This use case explores the initiation of a payment from the customer,
+merchant, and payment processor perspectives.
+ </p>
+ <p>
+A payment request contains all of the details necessary to perform a purchase
+including: 1) an optional list of requested products or services,
+2) the exchange value (price) for the products/services, 3) the acceptable
+payment instruments, and 4) a cryptographically verifiable signature on
+the important data in the request. The payment request is an extensible,
+cryptographically verifiable, self-contained document that can be used
+interchangeably with any payment processor.
+ </p>
+ </section>
+
+ <section>
+ <h4>Requirements</h4>
+ <ul>
+ <li>
+A messaging format that can encapsulate a list of goods and services being
+sold and the current value required to acquire the goods and services.
+ </li>
+ <li>
+The messaging format should be extensible (e.g. Linked Data, JSON-LD).
+ </li>
+ <li>
+The messaging format should be cryptographically verifiable (e.g. via
+digital signatures, PKI).
+ </li>
+ <li>
+The messaging format should enable the receiver of funds to specify
+acceptable payment instruments.
+ </li>
+ <li>
+A protocol that is capable of transmitting the payment request from the
+origination point of the payment request to the payer's payment processor.
+ </li>
+ <li>
+A protocol that is capable of discovering the payer's payment processor(s).
+ </li>
+ <li>
+A protocol that is capable of discovering the payer's payment instrument(s).
+ </li>
+ </ul>
+ </section>
+ </section>
+
+ <section>
+ <h3>Choice of Payment Instrument</h3>
+ <p>
+When a payee intends to make a payment, they are given a choice to pick among
+the intersection of the payment instruments they have available to them and
+the payment instruments that are accepted by the merchant/payee.
+ </p>
+
+ <section>
+ <h4>Examples</h4>
+ <ul>
+ <li>
+Daniel wants to pay the taxi fare with his credit card. The cab company promotes
+the payment via its web site which offers, on Daniel's smartphone, to choose
+between several instruments offering different payment means: 1) the basic
+credit card (Visa, MasterCard, etc.) channel; 2) or an indirect aggregators
+(PayPal, Google checkout); 3) or the personal wallet detected as available on
+Daniel's phone.
+ </li>
+ <li>
+Amantha downloads the latest version of her favorite game. It's only a couple
+of euros that she'd like to pay on top of her telecom operator's bill. The game
+store web site accepts payment via credit card and operator billing. Amantha
+selects the "operator billing" payment option.
+ </li>
+ </ul>
+ </section>
+
+ <section>
+ <h4>Details</h4>
+ <ul>
+ <li>
+Each payment instrument is registered with a set of attributes in order to
+filter, sort, and display them.
+ </li>
+ <li>
+Each payment processor is registered and 'subscribes' to a the payment
+instrument it is able to provide.
+ </li>
+ <li>
+Each merchant provides a list of acceptable payment instruments.
+ </li>
+ <li>
+Over time, each buyer iteratively builds a list of preferred payment
+instruments for their commonly used merchants.
+ </li>
+ </ul>
+ </section>
+
+ <section>
+ <h4>Requirements</h4>
+ <ul>
+ <li>
+The browser and the host are able to negotiate a payment instrument with
+respect to their preferences and support capabilities.
+ </li>
+ </ul>
+ </section>
+ </section>
+
+ <section>
+ <h3>Push-based Payments</h3>
+ <p>
+When a customer wants to make a purchase, the merchant presents the customer
+with an electronic invoice which in turn can be presented to a payment
+processor. The payment processor then provides a validated proof-of-payment
+to the merchant.
+ </p>
+
+ <section>
+ <h4>Examples</h4>
+ <ul>
+ <li>
+Customer POV: John goes to CandyCart.com and clicks “buy” to purchase
+chocolates. John is redirected to the CandyCart.com’s payment processor's
+website which presents him with a payment UI. John completes the purchase,
+and is redirected to CandyCart.com’s website, to which he can now post a
+digital receipt confirming the purchase.
+ </li>
+ <li>
+Customer POV: Francis purchases items in a local novelty store. The store
+system notifies his mobile application what methods of purchase can be used,
+and also sends his mobile application an electronic invoice for the
+transaction. The mobile app presents Frances with options for payment, and
+Frances chooses to pay with his tokenized credit card. The token and invoice
+are sent to the payment processor from the mobile app. The payment processor
+responds with a signed proof of payment electronic document.
+ </li>
+ <li>
+Merchant POV: A customer scans or clicks 5 items to purchase. The merchant
+system presents an electronic invoice (either total only or with a breakdown
+of the transaction), including the merchant's identifier, to the customer's
+device. The customer's device returns a digest of the invoice, having been
+created with the payment processor's private key.
+ </li>
+ <li>
+Payment Processor POV: A customer sends an electronic invoice, including
+the merchant and customer identifiers, to the payment processor. The payment
+processor checks the customer and merchant for validity, posts the requested
+amount to the merchant's acquirer, which returns a digest on the
+merchant/customer/amount/time tuple for proof of payment. The payment
+processor then returns a signed digest of the invoice plus the acquirer
+digest proving payment to the customer's device, which it in turn posts to
+the merchant system to prove payment.
+ </li>
+ </ul>
+ </section>
+
+ <section>
+ <h4>Details</h4>
+ <p>
+For this use case, the customer asks the payment processor for payment
+directly, preventing the need for sensitive customer information to be shared
+with the merchant, keeping the merchant out of "PCI scope." No direct
+communication between merchant and payment provider is required for this use
+case. It may be possible to create an electronic receipt format that satisfies
+the requirements for this use case as well as others.
+ </p>
+ </section>
+
+ <section>
+ <h4>Requirements</h4>
+ <ul>
+ <li>
+All acquirers must have an available public key.
+ </li>
+ <li>
+All payment processors must have an available public key.
+ </li>
+ <li>
+All merchants must have a global identifier.
+ </li>
+ <li>
+All customers must be recognized by the payment processor.
+ </li>
+ </ul>
+ </section>
+ </section>
+
+ </section>
+
+ <section>
+ <h2>Medium Priority Use Cases</h2>
+ <p>
+
+ </p>
+ </section>
+
+ <section>
+ <h2>Low Priority Use Cases</h2>
+ <p>
+
+ </p>
+ </section>
+
+
+ <section>
<h2>Acknowledgements</h2>
<p>