diff --git a/proposals/paymentapps/payment-apps.html b/proposals/paymentapps/payment-apps.html
index 18b4221..d5b6818 100644
--- a/proposals/paymentapps/payment-apps.html
+++ b/proposals/paymentapps/payment-apps.html
@@ -456,7 +456,7 @@ <h4>Discussion Notes on Registration</h4>
        <ul>
 	 <li>At each registration, the browser <span class='rfc2119'>MUST</span> replace all previous registration information with the new registration information. Payment apps  <span class='rfc2119'>MAY</span> use this feature to provide updates.</li>
 	 <li>Todo: Confirm that is the registration approach we wish to take. HTTP or JavaScript? What is the role of service workers?</li>
-	 <li><strong>Question</strong>. Should the registration data also include details about payment instruments? This would allow the browser to display more detail and facilitate selection. The details might not be "all the information" but enough (e.g., "last four digits of the card") to guide user selection. The browser might also use this information to improve per-instrument pricing.</li>
+	 <li><strong>Question</strong>. Should the registration data also include details about payment instruments? This would allow the browser to display more detail and facilitate selection. The details might not be "all the information" but enough (e.g., a user-provided label) to guide user selection. The browser might also use this information to improve per-instrument pricing.</li>
 	 <li><strong>Question</strong>: What, if anything, should we say about registering native payment apps? Should we publish separate "good practices" documents for different platforms?</li>
        </ul>
      </section>
@@ -491,7 +491,18 @@ <h3>Selectable App Information Display</h3>
       <li>The browser <span class='rfc2119'>MAY</span> allow the user to configure the display of matching payment apps.</li>
       <li>The browser <span class='rfc2119'>MUST</span> display matching payment apps in an order that corresponds to the order of supported payment methods supplied by the payee, except where the browser enables the user to override this order.</li>
       <li>The browser <span class='rfc2119'>SHOULD</span> display any payee-recommended apps in the order specified by the payee.</li>
-      <li><strong>Question</strong> What information is needed by the browser to display selectable apps?</li>
+      <li><strong>Question</strong> What information is needed by the browser to display selectable apps? Should instrument-specific information (e.g., mnemonic labels) be passed through to help with selection?</li>
+      <li><strong>Question</strong> Which of these scenarios do we expect to support through the set of technologies, and should we seek to harmonize the user experience across them?
+	<ol>
+	  <li>User has no registered payment apps.</li>
+	  <li>User has apps with supported but no enabled payment methods.</li>
+	  <li>User has apps with supported but no enabled payment methods.</li>
+	  <li>User has apps with supported and enabled payment methods.</li>
+	  <li>Merchant wishes to recommend a payment app to the user.</li>
+	  <li>Browser wishes to recommend a payment app that supports a payment method for which the user does not currently have a supporting payment app.</li>
+	</ol>
+	Current ideas for supporting 4 and 5 include (1) using the "recommended payment apps" approach of this spec (2) using payment method identifiers to designated recommended payment apps</li>
+      </li>
     </ul>
 
     <section>
@@ -591,6 +602,21 @@ <h4>Discussion Notes on Payment App Invocation</h4>
       <ul>
 	<li>Todo: Review the approach to invoking payment apps. HTTP or JS? Role of service workers?</li>
 	<li><strong>Question</strong>: What, if anything, should we say about launching native payment apps? Should we publish separate "good practices" documents for different platforms?</li>
+	<li><strong>Question</strong>: Communication mail fail at various points in the flow, including between server and payment app:
+	  <ul>
+	    <li>Payment server to payment app</li>
+	    <li>Payment app to browser</li>
+	    <li>Payee Web app to payee server</li>
+	  </ul>
+	  What sort of guarantees should we endeavor to provide, if any, for any of these points in the flow? If, for examle, a proof of payment is lost
+	  along the communication flow, then, for instance, a merchant might not shiop goods. Some observations:
+	  <ul>
+	    <li>Today, backchannel communications are often used (e.g., between payment server and payee server).</li>
+	    <li>The payee could provide a callback URL (identified as such in a standard way). This would allow (but not require) the payment app to communicate with the payee server until such time as all parties are satisfied they share the same view of the payment response.</li>
+	    <li>An alternative is to ensure that the payment app and the browser have a channel so that communication continues until all aprties are satisfied they share the same view of the payment response. This might involve caching payment responses.</li>
+	    <li>What happens in Payment Request API if the browser closes before the promise resolves?</li>
+	  </ul>
+	</li>
       </ul>
     </section>
   </section>