merchant

commit b27076a33a946cdb702a59468b018c8e949ce14a
parent f25e493210a1cb16b686c20e0358b3ac31d571e1
Author: Marcello Stanisci <marcello.stanisci@inria.fr>
Date:   Mon, 24 Oct 2016 20:18:45 +0200

up to mentioning fulfillment page

Diffstat:
M
doc/manual.texi
 | 
11
+++++++++++

1 file changed, 11 insertions(+), 0 deletions(-)
diff --git a/doc/manual.texi b/doc/manual.texi
@@ -413,6 +413,17 @@ echo $response->body;
 As said, @code{taler.offerContractFrom} will hand the contract to the wallet,
 which then will prompt the user a formatted version of it.
 
+The next step for the frontend is to accept the payment from the wallet,
+whenever the user will accept the contract. In Taler terminology, this action
+is managed by two pages: the @emph{fulfillment} and @emph{pay} page.
+
+By design, Taler payments @emph{can} be implemented in DB-less frontends, so the
+frontend needs a way to recall basic informations about a contract (e.g. which product,
+which price, the timestamp, etc.) before proceeding with the actual payment.
+That is achieved by @emph{reconstructing} the contract using the fulfillment page's
+parameters@footnote{the fulfillment URL equipped with all the parameters is included
+in the contract}.
+
 @section Backend configuration
 
 @subsection Wireformat