summaryrefslogtreecommitdiff
path: root/api-merchant.rst
diff options
context:
space:
mode:
authorJeff Burdges <burdges@gnunet.org>2015-10-30 11:23:20 +0100
committerJeff Burdges <burdges@gnunet.org>2015-10-30 11:23:20 +0100
commit31aa125199afacf57c31e789545ec715d3637333 (patch)
treea9777f9d31a41bae8d45251187edb281adc080e1 /api-merchant.rst
parent471489d6d9e1683971136e60831b3835a125607a (diff)
downloaddocs-31aa125199afacf57c31e789545ec715d3637333.tar.gz
docs-31aa125199afacf57c31e789545ec715d3637333.tar.bz2
docs-31aa125199afacf57c31e789545ec715d3637333.zip
Yet more minor changes, this time to the merchant
Diffstat (limited to 'api-merchant.rst')
-rw-r--r--api-merchant.rst16
1 files changed, 8 insertions, 8 deletions
diff --git a/api-merchant.rst b/api-merchant.rst
index 3705cf36..6881d150 100644
--- a/api-merchant.rst
+++ b/api-merchant.rst
@@ -16,8 +16,8 @@ necessary, the merchant assures this by limiting the time for which
the offer is valid.
Taler also assumes that the wallet and the merchant can agree on the
-current time (similar to what is required to connect to Tor or
-validate TLS certificates). The wallet may rely on the timestamp
+current time; similar to what is required to connect to Tor or
+validate TLS certificates. The wallet may rely on the timestamp
provided in the HTTP "Date:" header for this purpose, but the customer
is expected to check that the time is approximately correct.
@@ -29,12 +29,12 @@ Architecture's Overview
In our settlement, the "merchant" is divided in two independent
compontents, the `frontend` and the `backend`.
-The `frontend` is the (usually pre-existing) shopping portal of the
-merchant. The architecture tries to minimize the amount of
-modifications necessary to the `frontend` as well as the trust that
-needs to be placed into the `frontend` logic. Taler requires the
-frontend to facilitate two JSON-based interactions between the
-wallet and the `backend`, and one of those is trivial.
+The `frontend` is the existing shopping portal of the merchant.
+The architecture tries to minimize the amount of modifications necessary
+to the `frontend` as well as the trust that needs to be placed into the
+`frontend` logic. Taler requires the frontend to facilitate two
+JSON-based interactions between the wallet and the `backend`, and
+one of those is trivial.
The `backend` is a standalone C application intended to implement all
the cryptographic routines required to interact with the Taler wallet