summaryrefslogtreecommitdiff
path: root/integration-merchant.rst
diff options
context:
space:
mode:
authorMarcello Stanisci <marcello.stanisci@inria.fr>2016-07-06 18:14:20 +0200
committerMarcello Stanisci <marcello.stanisci@inria.fr>2016-07-06 18:14:20 +0200
commit9ea30f41d0b9e1688fc62089b135b8b1e1aafa66 (patch)
tree9e7753254a50e4e1b11a2a9a38b4f9b9940969d1 /integration-merchant.rst
parent36c085b4766cb4ca84da4c65c5cd8e0c16046961 (diff)
downloaddocs-9ea30f41d0b9e1688fc62089b135b8b1e1aafa66.tar.gz
docs-9ea30f41d0b9e1688fc62089b135b8b1e1aafa66.tar.bz2
docs-9ea30f41d0b9e1688fc62089b135b8b1e1aafa66.zip
contract description as of #4118
Diffstat (limited to 'integration-merchant.rst')
-rw-r--r--integration-merchant.rst27
1 files changed, 24 insertions, 3 deletions
diff --git a/integration-merchant.rst b/integration-merchant.rst
index 999fe41..a035089 100644
--- a/integration-merchant.rst
+++ b/integration-merchant.rst
@@ -50,9 +50,11 @@ Payment details
---------------
A payment process is triggered whenever the user visits a fulfillment URL and he has no rights
-in the session state to get the items accounted in the fulfillment URL. Since each fulfillment
-URL carries all the details useful to reconstruct a contract, the merchant reconstructs the contract
-and sends back to the user's browser a `taler-execute-payment` DOM event, defined as follows:
+in the session state to get the items accounted in the fulfillment URL. Note that when the user is
+not visiting a fulfillment URL he got from someone else, it is the wallet which points the browser
+to a fulfillment URL after the user accepts the contract. Since each fulfillment URL carries all the
+details useful to reconstruct a contract, the merchant reconstructs the contract and sends back to
+the user's browser a `taler-execute-payment` DOM event, defined as follows:
.. code-block:: tsref
@@ -76,3 +78,22 @@ state for the claimed item(s) to ``payed`` and now the wallet can point again th
fulfillment URL and finally get the claimed item(s). It's worth noting that each deposit permission
is associated with a contract and the wallet can reuse the same deposit permission to get the item(s)
mentioned in the contract without spending new coins.
+
+------------
+The contract
+------------
+
+As said, the offering URL is a location where the user must pass by in order to get a contract, and
+the contract is handed by the merchant to the browser by the mean of a `taler-confirm-contract` DOM
+event, defined as follows:
+
+ .. code-block:: tsref
+
+ {
+ // The contract as returned by the merchant backend,
+ // having the following fields:
+ // 'contract': the contract itself (FIXME link this definition to where contract is defined)
+ // 'H_contract': the hash of 'contract'
+ // 'merchant_sig': the signature over the contract made by the merchant
+ contract_wrapper: Object;
+ }