--- a/latest/use-cases/index.html	Tue Feb 17 22:05:27 2015 -0500
+++ b/latest/use-cases/index.html	Wed Feb 18 00:13:28 2015 -0500
@@ -149,7 +149,7 @@
       <dt><tdef>payment scheme</tdef></dt>
       <dd>
 Sets of rules and technical standards for the execution of payment transactions
-that have to be followed by adhering entities 
+that have to be followed by adhering entities
 (<tref title="payment processor">payment processors</tref>,
 <tref title="payer">payers</tref> and <tref title="payee">payees</tref>).
       </dd>
@@ -194,31 +194,44 @@
       <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 processor</tref> for processing.
+<tref>payment agent</tref> for processing.
       </p>
 
       <section>
         <h4>Examples</h4>
         <ul>
           <li>
-Customer POV: Penny logs into the HobbyCo website, providing her
-<tref>payment processor</tref> <tref>credential</tref> 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.
+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</a>.
           </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 an invoice for the purchase
-of the selected product. The invoice is transmitted to the customer's
-<tref>payment agent</tref>, which then transmits the invoice to the
-customer's <tref>payment processor</tref> for processing.
+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: A PayCo <tref>customer</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.
+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.
           </li>
         </ul>
       </section>
@@ -248,7 +261,7 @@
           </li>
           <li>
 the acceptable
-<tref title="payment instrument">payment instruments</tref> (see the
+<tref title="payment scheme">payment schemes</tref> (see the
 <a href="#choice-of-payment-instrument">choice of payment instrument</a>
 use case), and
           </li>
@@ -261,7 +274,7 @@
         <p>
 The payment request is an extensible, cryptographically verifiable,
 self-contained document that can be used interchangeably with any
-<tref>payment processor</tref>.
+<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
@@ -272,7 +285,7 @@
 
       </section>
 
-      <section>
+      <!-- section>
         <h4>Requirements</h4>
         <ul>
           <li>
@@ -288,24 +301,25 @@
           </li>
           <li>
 The messaging format should enable the <tref>payee</tref> to specify
-acceptable payment instruments.
+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 processor</tref>.
+<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 processor">payment processor(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>.
+<tref title="payment instrument">payment instrument(s)</tref> and the 
+corresponding <tref title="payment scheme">payment scheme(s)</tref>.
           </li>
         </ul>
-      </section>
+      </section -->
     </section>
 
     <section>
@@ -320,10 +334,10 @@
 
         <ul>
           <li>
-Customer POV: Tibor orders 3 pounds of 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.
+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 3 pounds of chocolate. 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.
+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.