clarification

articles/ui/ui.tex

@@ -684,16 +684,15 @@ Taler also allows the Web shop to detect
 the presence of a Taler wallet (Figure~\ref{listing:presence}), so
 that the selection of other payment methods can be skipped
 if a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}).
-If Taler was detected or selected, the Web shop sends a digitally
+
-signed {\em contract proposal} to the wallet extension
+Web pages can initiate payments by sending a \emph{contract proposal} to the
-(Figure~\ref{listing:contract}).  The wallet then presents the
+wallet, either via the status code HTTP 402 Payment Required, or via a
-contract to the user.  The format of the contract is in an extensible
+JavaScript API.  The wallet then presents the contract to the user.  The format
-JSON-based format defined by Taler and not HTML, as the
+of the contract is in an extensible JSON-based format defined by Taler and not
-rendering of the contract is done by the wallet to ensure correct
+HTML, as the rendering of the contract is done by the wallet to ensure correct
 % FIXME(dold): specify what we mean by "correct visual representation"!
-visual representation.  In case that transaction fees need to be
+visual representation.  In case that transaction fees need to be covered by the
-covered by the customer, these are shown together with the rest of the
+customer, these are shown together with the rest of the proposed contract.
-proposed contract.
 
 If the customer approves the contract by clicking the ``Confirm
 Payment'' button (Figure~\ref{subfig:payment}), their wallet signs the
@@ -701,8 +700,6 @@ contract with enough coins to cover the contract's cost, stores all of
 the information in its local database, and redirects the browser to a
 {\em fulfillment} URL provided by the merchant
 (Figure~\ref{subfig:fulfillment}).
-% FIXME: technically this is not entirely true, if you
-% allow CORS ...
 
 \subsection{Browser security}
 
@@ -742,11 +739,15 @@ cross-browser extension API, provides.
 
 % design that allows merchant to not store any information
 
-A purchase that was made by a customer is uniquely identified by a URL, called
+A purchase by customer, completed or in progress, is uniquely identified by a URL, called
-the \emph{fulfillment URL}.  When a customer completed a purchase, navigating
+the \emph{fulfillment URL}.  The information contained in the fulfillment
-to this URL in a browser should show the resource associated with the purchase.
+URL must allow the merchant to restore the full contract that was associated
-This resource can be a digital good such as a news article, or simply a
+with purchase, either directly or indirectly from an identifier in a database.
-confirmation for products that are delivered by other means.
+
+When a customer completed a purchase, navigating to this URL in a browser
+will show the resource associated with the purchase.  This resource can be a
+digital good such as a news article, or simply a confirmation for products that
+are delivered by other means.
 
 In order to ensure that only the paying customer has access to the web
 resources behind the fulfillment URL, the web store's server must check the
@@ -757,6 +758,10 @@ signed coins that are associated with the contract for the fulfillment URL to
 the merchant.  This process can be triggered via a JavaScript API for the
 wallet, or by a \emph{HTTP 402 Payment Required} status code.
 
+When a user visits a fulfillment URL without having the associated contract
+in their wallet, the wallet redirects the browser to the offer URL for that
+purchase, if applicable.
+
 Note that due to the limited WebExtensions API, the session
 state can only be acquired when the browser navigates to
 the fulfillment URL (without session state), since the session