summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--api-bank.rst4
-rw-r--r--api-exchange.rst27
-rw-r--r--api-merchant.rst1
-rw-r--r--dev-merchant.rst1
-rw-r--r--dev-wallet-wx.rst2
-rw-r--r--example-essay-store.rst2
-rw-r--r--index.rst4
-rw-r--r--integration-bank.rst6
-rw-r--r--operate-exchange.rst (renamed from impl-exchange.rst)2
-rw-r--r--operate-merchant.rst (renamed from impl-merchant.rst)3
10 files changed, 27 insertions, 25 deletions
diff --git a/api-bank.rst b/api-bank.rst
index afb2ba2..48b7075 100644
--- a/api-bank.rst
+++ b/api-bank.rst
@@ -35,10 +35,10 @@ namely exchanges.
**Response:**
-:status 200 OK: The request has been correctly handled, so the funds have been transferred to
-the recipient's account
+:status 200 OK: The request has been correctly handled, so the funds have been transferred to the recipient's account
:status 400 Bad Request: The bank replies a `BankIncomingError`_ object
+
**Details:**
.. _BankDepositRequest:
diff --git a/api-exchange.rst b/api-exchange.rst
index 63ac477..3087a8e 100644
--- a/api-exchange.rst
+++ b/api-exchange.rst
@@ -233,8 +233,7 @@ Obtaining wire-transfer information
// A single /wire response can contain an arbitrary number of these
// string-object pairs. However, the keys must be unique.
string : Object;
-
- }
+ }
Possible encodings for the objects are right now the following:
@@ -242,7 +241,7 @@ Obtaining wire-transfer information
.. _tsref-type-WireTestResponse:
.. code-block:: tsref
- interface WireTestResponse {
+ interface WireTestResponse {
// Mandatory indicator that this is a TEST wire response.
type: "test";
@@ -251,14 +250,13 @@ Obtaining wire-transfer information
// URI of the bank
bank_uri: string;
-
}
- .. _WireSepaResponse:
+ .. _WireSepaResponse:
.. _tsref-type-WireSepaResponse:
.. code-block:: tsref
- interface WireSepaResponse {
+ interface WireSepaResponse {
// Mandatory indicator that this is a SEPA wire response.
type: "sepa";
@@ -271,13 +269,12 @@ Obtaining wire-transfer information
// BIC of the bank.
bic: string;
- // the EdDSA signature_ (binary-only) with purpose
+ // the EdDSA signature (binary-only) with purpose
// `TALER_SIGNATURE_EXCHANGE_PAYMENT_METHOD_SEPA` signing over the hash over the
// 0-terminated strings representing the receiver's name, IBAN and the BIC.
sig: EddsaSignature;
}
-
------------------
Withdrawal
------------------
@@ -445,9 +442,9 @@ exchange.
.. _deposit-par:
---------------------
+-------
Deposit
---------------------
+-------
Deposit operations are requested by a merchant during a transaction. For the
deposit operation, the merchant has to obtain the deposit permission for a coin
@@ -543,9 +540,9 @@ denomination.
has enough residual value that has not already been deposited or melted.
+ .. _DepositSuccess:
.. code-block:: tsref
- .. _DepositSuccess:
interface DepositSuccess {
// The string constant "DEPOSIT_OK"
status: string;
@@ -562,7 +559,7 @@ denomination.
// explicitly as the client might otherwise be confused by clock skew as to
// which signing key was used.
pub: EddsaPublicKey;
- }
+ }
.. _DepositDoubleSpendError:
.. code-block:: tsref
@@ -1150,10 +1147,10 @@ Refunds
}
+ .. _RefundSuccess:
.. code-block:: tsref
- .. _RefundSuccess:
- interface RefundSuccess {
+ interface RefundSuccess {
// The string constant "REFUND_OK"
status: string;
@@ -1167,7 +1164,7 @@ Refunds
// explicitly as the client might otherwise be confused by clock skew as to
// which signing key was used.
pub: EddsaPublicKey;
- }
+ }
------------------------------
Administrative API: Key update
diff --git a/api-merchant.rst b/api-merchant.rst
index ff34797..8815e75 100644
--- a/api-merchant.rst
+++ b/api-merchant.rst
@@ -228,6 +228,7 @@ The following API are made available by the merchant's `backend` to the merchant
:query id: ID of the transaction we want to trace (an integer)
:query receiver: identificative token for the merchant instance which is to be tracked (optional). See :ref:`instances`.
+
**Response:**
:status 200 OK:
diff --git a/dev-merchant.rst b/dev-merchant.rst
index bb80912..cb83465 100644
--- a/dev-merchant.rst
+++ b/dev-merchant.rst
@@ -22,6 +22,7 @@ Introduction
TBD
.. _merchant-arch:
+
------
Design
------
diff --git a/dev-wallet-wx.rst b/dev-wallet-wx.rst
index 5995226..8ba2997 100644
--- a/dev-wallet-wx.rst
+++ b/dev-wallet-wx.rst
@@ -170,12 +170,14 @@ Internationalisation
Strings in the JavaScript code are internationalised using the following functions:
- *i18n*: translate string with arbitrary arguments, the result is returned as string.
+
.. code-block:: js
i18n`You have ${n} coins.`
- *i18n.parts*: Interpolate i18nized values with arbitrary objects.
Useful for example to include HTML elements.
+
.. code-block:: js
i18n.parts`Visit ${link} to get more coins.`
diff --git a/example-essay-store.rst b/example-essay-store.rst
index 102e54d..2a240f8 100644
--- a/example-essay-store.rst
+++ b/example-essay-store.rst
@@ -41,7 +41,9 @@ offer URL returns a HTML page that can either show a pay-form in case Taler is n
in the user's browser or download the contract from the merchant.
If the user has Taler installed and wants to pay, the wallet will POST the coins to a URL
of the form:
+
`https://blog.demo.taler.net/pay?uuid=${contract_hashcode}`
+
The URL comes with the contract's hashcode because each contract is an entry in
the merchant's state, so it can mark it as ``payed`` whenever it receives coins.
diff --git a/index.rst b/index.rst
index 15b06e0..41e7bc0 100644
--- a/index.rst
+++ b/index.rst
@@ -53,8 +53,8 @@ It focuses on how to install, configure and run the required software.
global_licensing
configuration-basics
- impl-exchange
- impl-merchant
+ operate-exchange
+ operate-merchant
versioning
------------------------
diff --git a/integration-bank.rst b/integration-bank.rst
index b8e2493..1dc2ec8 100644
--- a/integration-bank.rst
+++ b/integration-bank.rst
@@ -26,11 +26,11 @@ As a result of the reserve creation request, the following steps will happen in
2. Upon confirmation, the wallet fetches the desired amount from the user-filled form and
prompts the user for the *exchange base URL*. Then ask the user to confirm creating the
reserve.
- 2. The wallet will create a key pair for the reserve.
- 3. The wallet will request the CAPTCHA page to the bank. In that request's parameters it
+ 3. The wallet will create a key pair for the reserve.
+ 4. The wallet will request the CAPTCHA page to the bank. In that request's parameters it
communicates the desired amount, the reserve's public key and the exchange base URL to the
bank
- 4. Upon successful resolution of the CAPTCHA by the user, the bank initiates the reserve
+ 5. Upon successful resolution of the CAPTCHA by the user, the bank initiates the reserve
creation according to the gotten parameters. Together with `200 OK` status code sent back
to the wallet, it gets also a `ReserveCreated`_ object.
diff --git a/impl-exchange.rst b/operate-exchange.rst
index ce2cb4d..b276d06 100644
--- a/impl-exchange.rst
+++ b/operate-exchange.rst
@@ -139,7 +139,7 @@ Sections specifying denomination (coin) information start with "coin\_". By con
Keys duration
-----------------------
-Both `signkeys` and `denom keys` have a :ref:`starting date <keys>` (see :ref:`how <keys-duration>` this date is calculated).
+Both `signkeys` and `denom keys` have a :ref:`starting date <keys-duration>`.
The option `lookahead_provide`, under section `[exchange_keys]`, is such that only keys whose starting date is
younger than `lookahead_provide` will be issued by the exchange.
diff --git a/impl-merchant.rst b/operate-merchant.rst
index 45c83ba..572c7d6 100644
--- a/impl-merchant.rst
+++ b/operate-merchant.rst
@@ -59,8 +59,7 @@ it is mandatory to supply the connection string (namely, the database name). Thi
possible in two ways:
* via an environment variable: `TALER_MERCHANTDB_POSTGRES_CONFIG`.
-* via configuration option `config`, under section `[merchantdb-BACKEND]`. For example,
-the demo merchant is configured as follows:
+* via configuration option `config`, under section `[merchantdb-BACKEND]`. For example, the demo merchant is configured as follows:
.. code-block:: text