diff options
-rw-r--r-- | api-bank.rst | 4 | ||||
-rw-r--r-- | api-exchange.rst | 27 | ||||
-rw-r--r-- | api-merchant.rst | 1 | ||||
-rw-r--r-- | dev-merchant.rst | 1 | ||||
-rw-r--r-- | dev-wallet-wx.rst | 2 | ||||
-rw-r--r-- | example-essay-store.rst | 2 | ||||
-rw-r--r-- | index.rst | 4 | ||||
-rw-r--r-- | integration-bank.rst | 6 | ||||
-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 afb2ba28..48b7075e 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 63ac477c..3087a8e8 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 ff347979..8815e750 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 bb809128..cb834659 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 5995226e..8ba29975 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 102e54db..2a240f86 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. @@ -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 b8e24937..1dc2ec8d 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 ce2cb4d7..b276d06d 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 45c83baf..572c7d6d 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 |