--- a/latest/use-cases/index.html Thu Mar 19 21:37:12 2015 -0400
+++ b/latest/use-cases/index.html Fri Mar 20 00:01:11 2015 -0400
@@ -827,6 +827,59 @@
</p>
<dl class="dl-horizontal">
+ <dt>Credentials</dt>
+ <dd>
+At times it is necessary to transmit personally identifiable information in
+order to be cleared to make a purchase:
+ <ul>
+ <li>
+PharmCo will not sell regulated drugs to you unless you send proof that you
+have an active pharmacists license.
+ </li>
+ <li>
+WineCo will not let you ship wine to your home unless you send proof that you
+are over the age of 21.
+ </li>
+ <li>
+BoomCo will not ship industrial explosives to your business unless you
+send your construction permits, contractors license, and explosives handling
+license to the site.
+ </li>
+ <li>
+HomeLoanCo will not finalize a quote for a home mortgage until you provide
+them with 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 purchases that cannot be initated without
+a proper set of credentials. While this isn't fundamental to the payment
+process, it is an integral part of some transaction processes.
+ </dd>
+ <dt>Privacy / Security</dt>
+ <dd>
+The credential recipient must be in control of when and how the credential
+is shared at all times.
+ </dd>
+ <dt>Exceptions</dt>
+ <dd>
+If a required credential isn't available, the transaction is not allowed to
+proceed.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
<dt>Privacy Protection</dt>
<dd>
Tibor orders assorted chocolates from CandyCo. CandyCo only needs Tibor's
@@ -887,6 +940,30 @@
</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 payment schemes, the <tref>payer</tref> will have to provide the
+payment service with a detailed digital invoice from the <tref>payee</tref>
+in order to initiate payment to the <tref>payee</tref>.
+ </dd>
+ </dl>
+
<section>
<h5>Non-essential Use Cases</h5>
@@ -975,6 +1052,30 @@
</dd>
</dl>
+ <dl class="dl-horizontal">
+ <dt>Store Credit</dt>
+ <dd>
+Rick scans five dress shirts and two new pair of slacks at the self-checkout
+kiosk. The kiosk mentions that he could save 15% off of his purchase if he
+makes the purchase 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>
@@ -1041,6 +1142,35 @@
</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 purchase.
+ </dd>
+ <dt>Goals</dt>
+ <dd>
+Increased user choice,
+Improved user experience,
+Automatability,
+Portability,
+and Rapid, widespread adoption.
+ </dd>
+ <dt>Motivation</dt>
+ <dd>
+A <tref>payer</tref> will most likely use multiple payment services throughout
+their lifetime. 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 that
+privacy is enhanced.
+ </dd>
+ </dl>
+
+ <dl class="dl-horizontal">
<dt>Manual Selection</dt>
<dd>
<ul>
@@ -1092,6 +1222,11 @@
<dd>
<ul>
<li>
+Jonny's payment software on his smart watch picks the payment instrument that
+will provide him with the biggest cost savings for each purchase 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 transaction fee for PayCo), she will get a
discount.
@@ -1632,6 +1767,49 @@
</dd>
</dl>
+ <dl class="dl-horizontal">
+ <dt>Refunds</dt>
+ <dd>
+At times, it becomes necessary to refund a <tref title="payer">payer's</tref>
+payment:
+ <ul>
+ <li>
+Pele buys a slice of pizza 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 that 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>
+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 payment processors 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 transactions are the result of human error or fault. In these cases, it is
+helpful to be able to reverse the transaction and provide a refund to the
+customer.
+ </dd>
+ </dl>
+
</section>
</section>
@@ -1692,909 +1870,6 @@
</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>Initiating a Payment</h3>
- <p>
-A <tref>customer</tref> selects a product or service to purchase on a website.
-The website generates a payment request that is sent to the customer's
-<tref>payment agent</tref> for processing.
- </p>
- <section>
- <h4>Basic Flow</h4>
- <ol style="float: left;">
- <li>
-<tref>Payer</tref> selects product or service to purchase.
- </li>
- <li>
-<tref>Payee</tref> generates payment request.
- </li>
- <li>
-Payment request sent to <tref>payment agent</tref>.
- </li>
- </ol>
- <img style="display: block; max-height:100%; min-width: 40em; max-width:60%;" src="images/payment-initiation.svg"></img>
- </section>
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: Penny uses the HobbyCo website to select a model train for
-purchase. The store generates a payment request which is then forwarded to
-her <tref>payment agent</tref>. For more information on what happens
-next, see the <a href="#choosing-a-payment-instrument">
-choosing a payment instrument</a> use case.
- </li>
- <li>
-Merchant POV: A FarmCo <tref>customer</tref> 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 a <tref>payment request</tref>
-for the final amount of the selected product. The payment request
-is transmitted to the customer’s <tref>payment agent</tref>.
- </li>
- <li>
-Payment Processor POV (<tref>payer</tref>-initiated payment):
-A PayCo <tref title="customer">customer's</tref> <tref>payment agent</tref>
-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>
- <li>
-Payment Processor POV (<tref>payee</tref>-initiated payment): A MerchCo
-<tref>merchant</tref> receives a
-<a href="#proof-of-payment-hold-or-funds">proof of hold</a> from a
-<tref title="customer">customer's</tref> <tref>payment agent</tref>.
-The proof of hold proves that the customer has a valid
-<tref>payment instrument</tref> for a recognized
-<tref>payment scheme</tref>, and also proves that the customer has
-given consent for the payment. The merchant forwards the message to MerchCo.
-The transmission of funds are initiated from the customer's financial account
-to the merchant's financial account.
-<span class="issue">this flow isn't represented in the basic flow above,
-is that ok? Or should we have all possible alternate flows for the use
-case documented?</span>
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
- <p>
-All payments start somewhere and they typically follow the same basic flow:
-1) a <tref>payer</tref> requests a product or service, 2) the
-<tref>payee</tref> 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 <tref>customer</tref>, <tref>merchant</tref>,
-and <tref>payment processor</tref> perspectives.
- </p>
- <p>
-A payment request contains all of the details necessary to perform a purchase
-including:
- </p>
- <ol>
- <li>
-an optional list of requested products or services (see the Offers use case
-<span class="issue">not yet integrated</span>),
- </li>
- <li>
-the exchange value (price) for the products/services
-(see the Offers use case <span class="issue">not yet integrated</span>),
- </li>
- <li>
-the acceptable
-<tref title="payment scheme">payment schemes</tref> (see the
-<a href="#choice-of-payment-instrument">choice of payment instrument</a>
-use case), and
- </li>
- <li>
-a cryptographically verifiable signature on the important data in the
-payment request (see Digital Signatures use case
-<span class="issue">not yet integrated</span>).
- </li>
- </ol>
- <p>
-The payment request is an extensible, cryptographically verifiable,
-self-contained document that can be used interchangeably with any
-<tref>payment agent</tref> and <tref>payment processor</tref>.
- </p>
- <p class="issue">
-Stephane Boyera has raised a concern that this use case pulls in a bit too
-much about the choice of payment instrument and the type of payments (push-based,
-token-based, credit-card info exchange). He suggests that it may be better to
-break this into a meta-use case.
- </p>
-
- </section>
-
- <section>
- <h4>Pre-conditions</h4>
- <ul>
- <li>
-The <tref>customer</tref> has access to one or more of their
-<tref title="payment agent">payment agents</tref>.
- </li>
- <li>
-The <tref>customer</tref> and <tref>merchant</tref> have a communication
-channel over which they can pass messages.
- </li>
- <li>
-The <tref>customer</tref> has a mechanism that they can use to initiate
-the payment process with the <tref>merchant</tref>.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Post-conditions</h4>
- <ul>
- <li>
-The <tref>merchant</tref> has delivered a payment request to the
-<tref title="customer">customer's</tref> <tref>payment agent</tref>, or
- </li>
- <li>
-The <tref title="customer">customer's</tref> <tref>payment agent</tref> has
-delivered a
-<a href="#proof-of-payment-hold-or-funds">proof of hold</a> or
-<a href="#proof-of-payment-hold-or-funds">proof of funds</a>
-to the <tref>merchant</tref>.
- </li>
- </ul>
- </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 <tref>payee</tref> to specify
-acceptable payment schemes.
- </li>
- <li>
-A protocol that is capable of transmitting the payment request from the
-origination point of the payment request to the payer's
-<tref>payment agent</tref> and eventually to a <tref>payment processor</tref>.
- </li>
- <li>
-A protocol that is capable of discovering the
-<tref title="payer">payer's</tref>
-<tref title="payment agent">payment agent(s)</tref>.
- </li>
- <li>
-A protocol that is capable of discovering the <tref title="payer">payer's</tref>
-<tref title="payment instrument">payment instrument(s)</tref> and the
-corresponding <tref title="payment scheme">payment scheme(s)</tref>.
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Partially Omitting Personal Information</h3>
- <p>
-Leveraging variable degrees of pseudo-anonymity based on the requirements of the
-payment transaction.
- </p>
-
- <section>
- <h4>Examples</h4>
-
- <ul>
- <li>
-Customer POV: Tibor orders assorted chocolates from an online candy store. The store only needs Tibor's verified shipping address and a proof of payment to send him the chocolates. The verified shipping address and the proof of payment are made in a single request to Tibor's Payment Agent and both are delivered to the online candy store. 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 transaction.
- </li>
- <li>
-Merchant POV: An online candy store gets an order for assorted chocolates. The store requests a verified shipping address and a proof of payment from the customer in order to send the goods. After receiving both, the store ships the goods to the customer, not exposing themselves to any risk of accidentally leaking their customer's personal information of payment data.
- </li>
- <li>
-Payment Processor POV: PayCo is required to keep a certain amount of information on their customers for anti-money laundering / know your customer regulatory purposes. When a customer performs a transaction with a merchant, they would like to reduce the amount of information that's transmitted to the merchant while ensuring that they stay compliant with regulations. This enables the customer to stay pseudo-anonymous when dealing with merchants, but ensure that law enforcement have recourse in the event of illegal activity.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
- <p>
-Protecting an individual's privacy when performing transactions on the Web is an important concern. This use case attempts to ensure that transaction privacy is a fundamental part of any Web-based payment mechanism.
- </p>
- </section>
-
- <section>
- <h4>Requirements</h4>
-
- <ul>
- <li>
-A payment protocol that is capable of transmitting a proof of purchase that does not contain any personally identifiable information.
- </li>
- <li>
-A credential protocol that is capable of transmitting the minimum aspects of an entity's identity, such as a shipping address, or e-mail address, to complete a transaction.
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Choosing a Payment Instrument</h3>
- <p>
-When a <tref>payer</tref> intends to make a payment, they are given a choice
-to pick among the intersection of the
-<tref title="payment instrument">payment instruments</tref> they have available
-to them and the payment instruments that are accepted by the
-<tref>payee</tref>. When a selection is made, the payment request is routed
-to the appropriate <tref>payment agent</tref>.
- </p>
-
- <section>
- <h4>Basic Flow</h4>
- <img style="display: block; margin-left: auto; margin-right: auto;
- max-height:100%; max-width:75%;" src="images/instrument-selection.svg">
- </section>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: 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 options offering different payment instruments: 1) the basic
-credit card (Visa, MasterCard, etc.) schemes provided by his
-cloud-based credit card wallet; 2) or an indirect aggregator
-(PayPal, Google checkout) installed as a native phone application; 3) or
-a locally installed cryptocurrency wallet application.
- </li>
- <li>
-Customer POV: 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>
- <li>
-Merchant POV: A CrowdFundCo customer has just approved a donation to a
-third party. To complete the donation, CrowdFundCo provides its
-available payment instruments; Bitcoin and PayPal. The customer has
-a VISA credit card and a MasterCard credit card in a single payment agent
-as well as a Bitcoin payment agent. The payment request is forwarded
-to the Bitcoin payment agent.
- </li>
- <li class="issue">
-The following example is marked for removal because it conflates offering
-a new payment instrument w/ the selection of a payment instrument:
-
-Ricardo would like to pay for clothes at ThreadCo, a brick-and-mortar retailer,
-using software on his mobile phone. He taps his phone to checkout and notices
-that the purchase would be less expensive if he uses a department store
-digital credit card to complete the purchase. He applies for the card using a
-provided link, is approved for the digital credit card card, and completes the
-checkout process using his new card.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
-
- <p>
-In order to ensure a level playing field and a vibrant ecosystem of
-<tref title="payment agent">payment agents</tref> and
-<tref title="payment instrument">payment instruments</tref>, it's important that
-a mechanism exists to enable the <tref>payer</tref> to easily select between a
-variety of competing options.
- </p>
-
- <p class="issue">
-The rest of the text in this section aren't really motivations, they're more
-like details about the things that should be provided by a payment
-instrument selection mechanism.
- </p>
-
- <ul>
- <li>
-Each <tref>payment instrument</tref> is registered with a set of attributes in
-order to filter, sort, and display them including the
-<tref>payment scheme</tref> with which it is associated.
- </li>
- <li>
-Each <tref>payment agent</tref> registers the
-<tref title="payment instrument">payment instruments</tref> and
-associated <tref title="payment scheme">payment schemes</tref> it is able to
-provide.
- </li>
- <li>
-The payment initiation process can discover the locally registered
-<tref title="payment agent">payment agents</tref> and their
-supported <tref title="payment instrument">payment instruments</tref>
-and <tref title="payment scheme">payment schemes</tref>.
- </li>
- <li>
-Optionally, new payment instruments may be offered to the <tref>payer</tref> by
-the <tref>payee</tref> and provided as options by their
-<tref>payment agent</tref>.
- </li>
- <li>
-Each <tref>merchant</tref> provides a list of acceptable
-<tref title="payment scheme">payment schemes</tref>, and if applicable,
-specific <tref title="payment instrument">payment instruments</tref>
-within each scheme (such as Visa and MasterCard only).
- </li>
- <li>
-A <tref>payment agent</tref> may attempt to optimize payment instruments on
-behalf of the <tref>customer</tref> by selecting for payment speed,
-loyalty benefits, price, or other conveniences.
- </li>
- <li>
-Over time, each <tref>customer</tref> iteratively builds a list of preferred
-payment instruments for their commonly used
-<tref title="merchant">merchants</tref>.
- </li>
- </ul>
-
- <p class="issue">
-How are multiple payment instruments handled? Is there such a thing? There are
-two main approaches so far. The first is to treat loyalty cards, coupons,
-discount cards, and other similar items as types of
-<tref title="credential">credentials</tref> and the
-<tref>payment instrument</tref> as the mechanism that moves the value. The
-second is to explore how multiple payment instruments may be mixed together
-from different providers to complete a transaction.
- </p>
- </section>
-
- <section>
- <h4>Pre-conditions</h4>
- <ul>
- <li>
-A payment request is provided to the software that was used to initiate the
-payment.
- </li>
- <li>
-A number of <tref title="payment agent">payment agents</tref> are available
-to the device inititating the payment such that they are able to respond to
-queries related to their supported
-<tref title="payment instrument">payment instruments</tref> and
-associated <tref title="payment scheme">payment schemes</tref>.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Post-conditions</h4>
- <ul>
- <li>
-A <tref>payment agent</tref> capable of utilizing the selected
-<tref>payment instrument</tref> is selected to process the payment request.
- </li>
- </ul>
- </section>
-
- <!-- section>
- <h4>Requirements</h4>
- <ul>
- <li>
-The <tref>payer</tref>, via the software that initiated the payment
-(such as the user agent coupled with the payment agent),
-and the <tref>payee</tref> are able to negotiate a
-<tref>payment instrument</tref> with respect to their preferences and
-support capabilities.
- </li>
- <li>
-A data format, which would be a part of the payment request, that expresses
-the list of available payment instruments that the
-<tref>merchant</tref> accepts.
- </li>
- <li>
-A protocol that enables the <tref>payment agent</tref> to suggest new
-<tref>payment instruments</tref> to the <tref>customer</tref> based on
-customer preferences (speed, points, price, etc.).
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Making a Payment Without Registering</h3>
- <p>
-A <tref>payer</tref> goes to a <tref>payee</tref> storefront and initiates a payment without having to go through any registration process. During the payment process, the <tref>payer</tref> chooses which information to share with the <tref>payee</tref> which the <tref>payee</tref> then uses to identify the <tref>payer</tref> if future payments are made.
- </p>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: Lilith finds a song that she really likes through one of her favorite music blogs. Without registering with the blog, or the artists website, she initiates a purchase and is sent to the artist's website to show the proof of purchase and download the song. At no point did Lilith have to register for a user account, enter her credit card number, or email address.
- </li>
- <li>
-Merchant POV: A proof of purchase for a song is shown to a merchant website. The proof of purchase is validated and the merchant website provides a download for the customer.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
- <p>
-There are a large number of "paywall" websites on the Web that require registration to use. 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.
- </p>
- </section>
-
- <section>
- <h4>Requirements</h4>
- <ul>
- <li>
-A Web-native data format that can express a proof of purchase / digital receipt.
- </li>
- <li>
-The data format should be extensible (e.g. Linked Data, JSON-LD).
- </li>
- <li>
-The data format should be cryptographically verifiable so that merchants can be certain that funds have or will be transferred and that the receipt is valid.
- </li>
- <li>
-A data format for expressing credentials that may need to be a part of the delivery of a proof of purchase. For example, a proof of purchase coupled with a shipping address.
- </li>
- <li>
-A protocol for requesting a proof of purchase from a payer.
- </li>
- <li>
-A protocol for delivering a proof of purchase to a payee.
- </li>
- <li>
-A protocol for transmitting credentials that works in concert with the delivery of a proof of purchase.
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Payer-initiated Funds Transfer</h3>
- <p>
-When a <tref>customer</tref> wants to make a purchase, the
-<tref>merchant</tref> presents the customer with an electronic invoice which
-in turn can be presented to a <tref>payment processor</tref>. The payment
-processor then provides a validated proof-of-payment to the merchant via
-the customer's device or directly to the merchant.
- </p>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: John goes to CandyCart.com and clicks “buy” to purchase
-chocolates. His browser re-directs him to his <tref>payment processor</tref>
-which asks him to approve the purchase. He approves the purchase, his
-payment processor transmits the funds to the receiving account, and his
-browser is re-directed back to CandyCart.com with the proof of payment.
- </li>
- <li>
-Merchant POV: A <tref>customer</tref> selects 5 items to purchase.
-The <tref>merchant</tref> system presents an electronic invoice (either a total
-only or with a breakdown of the transaction), including the merchant's
-identifier, to the <tref title="customer">customer's</tref> device.
-The customer's device returns a proof of payment that is digitally signed
-with the customer's
-<tref title="payment processor">payment processor's</tref> private key.
- </li>
- <li>
-3-Corner Payment Processor POV: A <tref>customer</tref> sends an electronic invoice,
-including the <tref>merchant</tref> and customer identifiers, to the
-<tref>payment processor</tref>. The customer and the merchant use the
-same payment processor. The payment processor checks the customer and
-merchant for validity, posts the requested amount to the merchant's account,
-and then generates a proof of payment for the merchant. The payment processor
-then returns a signed digest of the invoice plus a digest of the proof of
-payment to the customer's device. The customer's device delivers the
-proof-of-payment to the merchant system to prove that funds have been
-transferred.
- </li>
- <li>
-4-Corner Payment Processor POV: A <tref>customer</tref> sends an electronic
-invoice, including the <tref>merchant</tref> and customer identifiers, to the
-<tref>payment processor</tref>. The customer and the merchant use different
-payment processors. The payment processor checks the customer and
-merchant for validity, and initiates a transfer of the requested amount
-to the merchant's account via a payment clearing mechanism. Once the
-payment processor has received a verification that the payment message was
-received by the acquirer, it then generates a proof of payment for the merchant.
-The payment processor then returns a signed digest of the invoice plus a digest
-of the proof of payment to the customer's device. The customer's device
-delivers the proof-of-payment to the merchant system to prove that funds
-have been transferred.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
- <p>
-For this use case, the <tref>customer</tref> asks the
-<tref>payment processor</tref> to initiate payment to the <tref>merchant</tref>
-directly, preventing the need for sensitive customer information to be shared
-with the <tref>merchant</tref>, which keeps 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 <tref title="payment processor">payment processors</tref> must have an
-available public key.
- </li>
- <li>
-All <tref title="merchant">merchants</tref> must have a global identifier.
- </li>
- <li>
-All <tref title="customer">customers</tref> must be recognized by the
-<tref>payment processor</tref>.
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Payee-initiated Processing</h3>
- <p>
-When a <tref>customer</tref> wants to make a purchase, the <tref>merchant</tref> requests
-from the <tref title="customer">customer's</tref> <tref>payment agent</tref> an Instrument Proof.
-The <tref>merchant</tref> sends this proof to its <tref>payment processor</tref> to initiate the
-funds transfer. The <tref>payment processor</tref> can return a Payment Proof to the <tref>merchant</tref>.
- </p>
-
- <section>
- <h4>Basic Flow</h4>
- <ol>
- <li>
-Payment Request is sent to Payment Agent via User Agent.
- </li>
- <li>
-Payment Agent sends Instrument Proof to Payee (via User Agent or 2' direct callback).
- </li>
- <li>
-Payee sends payment details and Instrument Proof to its Processor.
- </li>
- <li>
-Processor returns a Payment Proof to the merchant.
- </li>
- </ol>
- <img style="display: block; max-height:100%; min-width: 40em; max-width:60%;" src="images/payee-initiated-processing.svg"></img>
- </section>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: John goes to CandyCart.com and clicks “buy” to purchase chocolates.
-After selecting his bank's virtual card, his browser re-directs him to his bank's wallet, which acts as a payment agent.
-John approves the payment and his virtual card generates an Instrument Proof cryptogram that signs the transaction and
-captures his content. The cryptogram is sent to the merchant, which completes the purchase after verification.
- </li>
- <li>
-Merchant POV: CandyCart.com presents John with an array of chocolates to buy.
-After John has approved his cart and selected his bank's virtual card to pay with, CandyCart.com generates a
-Payment Request and sends it to John's Payment Agent. It receives an Instrument Proof from the payment agent
-and forwards it to CardProcessingCo, along with payment details, for processing the payment.
-It gets a Payment Proof from CardProcessingCo in return, which completes the purchase.
- </li>
- <li>
-Payment Processor POV: CardProcessingCo receives a payment processing request from CandyCart.com.
-Because it is using standard Instrument Proof cryptograms, CardProcessingCo can handle the request as
-any other card payment.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
- <p>
-In this use case, the merchant triggers the payment processing using its processor.
-This flow is the closest to legacy card scheme flows (also, the one used in brick and mortar stores),
-and it is expected that supporting it will ease integration in current merchant systems.
- </p>
- <p>
-An Instrument Proof in this use case is intended has a guarantee of possession by the customer of a valid,
-compatible payment instrument and that the customer has given consent for the payment. For comparison, a
-Payment Proof guarantees that the customer holds the corresponding funds and the funds will be transferred.
-These guarantees are typically provided by a Payment Scheme, therefore the format for these proofs will
-have to be scheme extensible.
- </p>
- </section>
-
- <section>
- <h4>Pre-conditions</h4>
- <ul>
- <li>
-A number of payment agents are available on the customer device and at least one is supported by the merchant.
- </li>
- <li>
-A payment agent and payment instrument has been selected by the customer, and a payment request has been sent
-to the payment agent.
- </li>
- </ul>
- <h4>Post-conditions</h4>
- <ul>
- <li>
-The payment agent has delivered an Instrument Proof (or a payment refusal).
- </li>
- <li>
-The merchant has obtained a Payment Proof from its processor.
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Limiting Payee-initiated Payments</h3>
- <p>
-A payer visits a payee's website and initiates a payment. The payer's payment processor presents them with an option to assign a pay-as-you-go token with a specific spending limit (and/or other limitations) for future purchases with the payee. An option is also presented to require the display of a receipt when a purchase occurs (and/or other interactions), or to perform the purchase in the background with no interactive purchase process required.
- </p>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: Yanos visit's his favorite financial news site, which requires articles to be purchased if the customer does not have a subscription. Yanos initiates a purchase. The website, in the payment request, requests a multi-use payment token from Yanos' payment processor to spend up to $15 a month on Yanos' behalf when he purchases certain for-pay articles. Yanos' payment processor asks him if he would just like to perform a one-time purchase, or grant the payment token to the news site. Yanos doesn't want to be bothered to approve a $0.50 purchase, as he does many of them on the website, so he authorizes the initial payment and also authorizes the multi-use payment token. The multi-use payment token is delivered to the financial news site along with proof-of-purchase for the initial article he intended to buy.
- </li>
- <li>
-Merchant POV: An online video game company following a freemium business model would like to enable in-app purchases for their content. In order to do so, they would like to request a multi-use payment token from their customer. They enable a button in their game that requests a multi-use payment token and when a customer approves it, the company stores it in their systems. The multi-use payment token is only good for 3 months and has a spending limit that is set by the customer.
- </li>
- <li>
-Payment Processor POV: A payee's payment processor receives a request for a multi-use payment token from a payer via the payee's device. The payment processor ensures that the details of the payment token are acceptable to the payee, enables them to add constraints to the payment token, and upon approval, grants a unique identifier for the payment token to be returned to the merchant. The payment token is always linked between a payer's source account and a payee's destination account such that the theft of the payment token does not result in the ability of the thief to move money from the payer's source account to an arbitrary payee.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
-
- <p>
-There are a number of types of purchases that don't require the full attention of the payer when they happen. For example, an in-game purchase for an item that costs $0.05 is not necessary until a pre-set limit set by the payer is reached. It is important to not make the payment experience cumbersome for markets that perform micro-payments, or require the processing of many repetitive payments. If the payment authorization step can be automated to the point of disappearing without creating a bad customer experience or generating fraud, then it should be eliminated.
- </p>
- </section>
-
- <section>
- <h4>Requirements</h4>
- <ul>
- <li>
-A data format to express a request for a multi-use payment token that is capable of expressing an amount, a recharge frequency, and an optional expiration date.
- </li>
- <li>
-A data format to express a multi-use payment token that is capable of expressing a unique id, an optional amount, a recharge frequency, and an optional expiration date.
- </li>
- <li>
-A protocol to request a multi-use payment token from a payment processor.
- </li>
- <li>
-A protocol to specify that a payment request should be fulfilled using a multi-use payment token (or perhaps we don't have the merchant deal with this information at all - which would be preferable.)
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Proof of Payment, Hold, or Funds</h3>
- <p>
-A <tref>payer</tref> intiates a transaction for a good or service from a <tref>payee</tref> resulting in a standardized, cryptographically signed, machine-readable proof-of-payment, proof-of-hold, or proof-of-funds. Entities involved in the transaction (<tref>payer</tref> or any <tref>payee</tref>) may then use the proof to assess whether or not the <tref>payer</tref> should have access to the good or service.
- </p>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: Jeff buys a lot of heavy metal music through the "Buy this track" function on his car radio. When he buys a new car, he wants to transfer his collection and provides all of the proof-of-payment data to show that he has already paid for the songs.
- </li>
- <li>
-Customer POV: Willie buys e-tickets for a football game, but his mobile phone is stolen while standing in the queue. Since he has a receipt and identifies himself, he can still get in to watch the match.
- </li>
- <li>
-Customer POV: 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.
- </li>
- <li>
-Merchant POV: Rockinradio, smoothSounds, and classicClassic are independent specialised music retailers. They accept proof-of-purchase from each other to provide a track that is in their online catalogue even if it was originally bought from another provider.
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Refunds</h3>
- <p>
-The funds that are transmitted from <tref>payer</tref> to <tref>payee</tref> are reversed after a decision by a <tref>merchant</tref>, <tref>regulatory authority</tref>, or <tref>payment processor</tref>.
- </p>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: Pele buys a slice of pizza 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>
-Merchant POV: A customer claims that a blender that 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>
-Regulator POV: 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 payment processors to reverse all payments sent to the fake identities.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Requirements</h4>
- <ul>
- <li>
-A protocol for transmitting a proof of purchase/hold/funds and reversing the transmission of funds when requested by a proper authority.
- </li>
- <li>
-A way of identifying a particular individual, organization, or financial account and reversing all transactions to that entity.
- </li>
- </ul>
- </section>
- </section>
-
- </section>
-
- <section>
- <h2>Medium Priority Use Cases</h2>
- <p>
-The following use cases have been identified by the Web Payments Interest
-Group as medium-priority items.
- </p>
-
- <section>
- <h3>Applying Coupons and Loyalty Cards to a Payment</h3>
- <p>
-A <tref>payee</tref> can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits.
- </p>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: Cory shops for groceries at his local ChowMart. When he starts the checkout process via the automated kiosk, the machine asks him to tap his phone to transmit his ChowSavingsCard info to get discounts on items he's purchasing. He taps his phone, selects his card and taps his phone again to transmit the card information to the kiosk, which shows him how much of a discount he is receiving because of the card.
- </li>
- <li>
-Merchant POV: ChickenHut requests loyalty cards from frequent customers in order to provide discounts. When customers tap their phone, a cryptographically verifiable token that was issued by ChickenHut is transmitted from the phone to the point of sale device and verified for authenticity.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
- <p>
-Coupons and loyalty cards are two discount mechanisms that may be used by a customer before performing a final payment. While coupons and loyalty cards vary wildly in their associated benefits, a merchant or manufacturer must ensure that each one is authentic. In order to ensure the authenticity of a coupon, loyalty card, or information stored therein, it is important that all information is cryptographically verifiable. It is also important for the point-of-sale devices to be able to add information to the locally-stored loyalty cards for use in off-line scenarios.
- </p>
- </section>
-
- <section>
- <h4>Requirements</h4>
- <ul>
- <li>
-A data format for expressing a coupon.
- </li>
- <li>
-A data format for expressing a loyalty card.
- </li>
- <li>
-The data format should be extensible (e.g. Linked Data, JSON-LD).
- </li>
- <li>
-The data format should be cryptographically verifiable (e.g. via digital signatures, PKI).
- </li>
- <li>
-A protocol for transmitting the coupon or loyalty card from the payer to the payee.
- </li>
- <li>
-A protocol for adding cryptographically verifiable information to a loyalty card.
- </li>
- </ul>
- </section>
- </section>
-
- <section>
- <h3>Performing a Payment in Multiple Phases</h3>
- <p>
-<tref title="transaction">Transactions</tref> over a certain amount may require
-a preliminary check on the availability of funds to complete the transaction.
-These transactions may also have a provision to perform a hold on the funds
-until the product or service is delivered and the transaction is complete.
- </p>
-
- <section>
- <h4>Examples</h4>
- <ul>
- <li>
-Customer POV: George pulls up to a pump at a petrol station. His in-vehicle
-application recognizes the station location and the pump, and asks if he wants
-to approve a fill up. He answers "yes" and is prompted for which method of
-payment he would like to use. He makes his selection, exits the vehicle,
-lifts the nozzle, selects the grade of fuel, and fills his car. When he
-returns to his vehicle, an electronic receipt for the purchase is displayed
-by his in-vehicle application.
- </li>
- <li>
-Customer POV: Doris uses her mobile application to approve fuel fill-up for
-her van. She realizes after exiting her vehicle that the site is not ADA
-compliant, and so she cannot access the pumps. She uses her mobile application
-to cancel the transaction.
- </li>
- <li>
-Merchant POV: FuelCo's in-store control system gets a message from a
-<tref>payment processor</tref> that pump 14 should be approved for a fill-up.
-The message includes a single use cryptogram that can be used to prove
-authorization. The equipment arms the pump and allows the fueling to proceed.
-On completion, the merchant system sends the actual amount to pay along with
-the single use cryptogram back to the payment processor.
- </li>
- </ul>
- </section>
-
- <section>
- <h4>Motivations</h4>
- <p>
-Delivering services or products that are difficult to "undo", such
-as performing an oil change, dispensing fuel, or renting a car, are examples
-of situations which may require a two-part transaction.
- </p>
- <p>
-This use case highlights the need for a two part transaction. The
-first part either checks availability or reserves funds, and the second
-completes the transaction with the actual amount. There are many different
-ways these two segments can be completed.
- </p>
- </section>
-
- <section>
- <h4>Requirements</h4>
- <ul>
- <li>
-A protocol and data format that enables a device to directly send a
-pre-authorization request to a <tref>customer</tref>, process it through
-the customer's <tref>payment processor</tref>, and receive the proof of
-pre-authorization from either the customer device or the customer's
-payment processor.
- </li>
- <li>
-A protocol and data format that enables the pre-authorization request to be
-processed entirely with the <tref title="merchant">merchant's</tref> payment
-processing system.
- </li>
- <li>
-A protocol that enables the merchant to request a specific hold amount, the
-amount to be approved or denied by the customer, and the hold of the funds to
-be either approved of denied by the <tref>payment processor</tref>.
- </li>
- </ul>
- </section>
- </section>
-
- </section>
-
- <section>
- <h2>Low Priority Use Cases</h2>
- <p>
-
- </p>
- </section-->
-
<section>
<h2>Acknowledgements</h2>