diff options
| -rw-r--r-- | core/api-exchange.rst | 20 | ||||
| -rw-r--r-- | core/api-merchant.rst | 4 | ||||
| -rw-r--r-- | design-documents/016-backoffice-order-management.rst | 44 | ||||
| -rw-r--r-- | design-documents/018-contract-json.rst | 6 | ||||
| -rw-r--r-- | taler-auditor-manual.rst | 4 | ||||
| -rw-r--r-- | taler-mcig.rst | 24 | ||||
| -rw-r--r-- | taler-merchant-manual.rst | 7 |
7 files changed, 55 insertions, 54 deletions
diff --git a/core/api-exchange.rst b/core/api-exchange.rst index e427e42f..3d8d8b7e 100644 --- a/core/api-exchange.rst +++ b/core/api-exchange.rst @@ -991,7 +991,7 @@ This part of the API is for the use by auditors interacting with the exchange. The auditor signature is invalid. :http:statuscode:`404 Not found`: The denomination key for which the auditor is providing a signature is unknown. - The response will be a `DenominationUnkownMessage`. + The response will be a `DenominationUnknownMessage`. :http:statuscode:`410 Gone`: This auditor is no longer supported by the exchange. :http:statuscode:`412 Precondition failed`: @@ -1389,7 +1389,7 @@ exchange. The denomination key or the reserve are not known to the exchange. If the denomination key is unknown, this suggests a bug in the wallet as the wallet should have used current denomination keys from ``/keys``. - In this case, the response will be a `DenominationUnkownMessage`. + In this case, the response will be a `DenominationUnknownMessage`. If the reserve is unknown, the wallet should not report a hard error yet, but instead simply wait for up to a day, as the wire transaction might simply not yet have completed and might be known to the exchange in the near future. @@ -1434,7 +1434,7 @@ exchange. // What kind of operation was requested that now // failed? - oper: String; + oper: string; } @@ -1580,7 +1580,7 @@ denomination. Either the denomination key is not recognized (expired or invalid), or the wire type is not recognized. If the denomination key is unknown, the response will be - a `DenominationUnkownMessage`. + a `DenominationUnknownMessage`. :http:statuscode:`409 Conflict`: The deposit operation has either failed because the coin has insufficient residual value, or because the same public key of the coin has been @@ -1975,7 +1975,7 @@ denomination. purse_pub: EddsaPublicKey; // Signature by the exchange over a - // `TALER_CoinPurseRefundConfirmationPS` + // ``TALER_CoinPurseRefundConfirmationPS`` // of purpose ``TALER_SIGNATURE_EXCHANGE_CONFIRM_PURSE_REFUND``. exchange_sig: EddsaSignature; @@ -2022,7 +2022,7 @@ the API during normal operation. The exchange does not recognize the denomination key as belonging to the exchange, or it has expired. If the denomination key is unknown, the response will be - a `DenominationUnkownMessage`. + a `DenominationUnknownMessage`. :http:statuscode:`409 Conflict`: The operation is not allowed as the coin has insufficient residual value, or because the same public key of the coin has been @@ -2315,14 +2315,14 @@ in using this API. The denomination key is unknown, or the blinded coin is not known to have been withdrawn. If the denomination key is unknown, the response will be - a `DenominationUnkownMessage`. + a `DenominationUnknownMessage`. :http:statuscode:`409 Conflict`: The operation is not allowed as the coin has insufficient residual value, or because the same public key of the coin has been previously used with a different denomination. Which case it is can be decided by looking at the error code (``TALER_EC_EXCHANGE_RECOUP_COIN_BALANCE_ZERO`` or - ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``). + ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``). The response is a `DepositDoubleSpendError`. :http:statuscode:`410 Gone`: The requested denomination key is not yet or no longer valid. @@ -2490,7 +2490,7 @@ typically also view the balance.) **Request:** - :query merchant_sig: EdDSA signature of the merchant made with purpose ``TALER_SIGNATURE_MERCHANT_TRACK_TRANSACTION`` over a `TALER_DepositTrackPS`, affirming that it is really the merchant who requires obtaining the wire transfer identifier. + :query merchant_sig: EdDSA signature of the merchant made with purpose ``TALER_SIGNATURE_MERCHANT_TRACK_TRANSACTION`` over a ``TALER_DepositTrackPS``, affirming that it is really the merchant who requires obtaining the wire transfer identifier. **Response:** @@ -2773,7 +2773,7 @@ Wallet-to-wallet transfers previously used with a different denomination. Which case it is can be decided by looking at the error code (``TALER_EC_EXCHANGE_DEPOSIT_INSUFFICIENT_FUNDS`` or - ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``). + ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``). The fields of the response are the same in both cases. The request should not be repeated again with this coin. In this case, the response is a `PurseDepositDoubleSpendError`. diff --git a/core/api-merchant.rst b/core/api-merchant.rst index cb59314a..ea2ca0b3 100644 --- a/core/api-merchant.rst +++ b/core/api-merchant.rst @@ -1478,7 +1478,7 @@ Reserving inventory // UUID that identifies the frontend performing the lock // Must be unique for the lifetime of the lock. - lock_uuid: String; + lock_uuid: string; // How long does the frontend intend to hold the lock? duration: RelativeTime; @@ -1602,7 +1602,7 @@ Creating orders // be used in case different UUIDs were used for different // products (i.e. in case the user started with multiple // shopping sessions that were combined during checkout). - lock_uuids: String[]; + lock_uuids: string[]; // Should a token for claiming the order be generated? // False can make sense if the ORDER_ID is sufficiently diff --git a/design-documents/016-backoffice-order-management.rst b/design-documents/016-backoffice-order-management.rst index 583661c1..00250cd2 100644 --- a/design-documents/016-backoffice-order-management.rst +++ b/design-documents/016-backoffice-order-management.rst @@ -38,7 +38,7 @@ Listing orders 4 tabs will be show for a easy access to common filter, click on any of this and search will reset all filter except date -* paid (default) +* paid (default) * refunded * not wired * all (empty filter box) @@ -78,7 +78,7 @@ this form is divided into 4 sections * ``payment``: where some default of the payment processing can be changed * ``extra``: where the merchant can add extra information in JSON format - + Create order: Product section ............................. @@ -95,7 +95,7 @@ The first part will add/remove product from the current stock. The second part will add non inventory product. To add a product a :ref:`create product <backoffice-create-product>` form will be shown. The product in the list -can be edited or deleted from the list. +can be edited or deleted from the list. In both cases, the total unit and price of the products will be calculated and shown in the bottom of the section. If the merchant collapse one of the product @@ -107,7 +107,7 @@ list a line with a resume of the total price and units will be shown. Create order: Price section ........................... -This section has 2 scenarios. +This section has 2 scenarios. The fist one is without products being added: the ``order price`` and ``summary`` inputs will be shown. @@ -115,7 +115,7 @@ The fist one is without products being added: the ``order price`` and If there is at least one product added, the ``total products price`` as the sum of all products prices will be shown. The ``order price`` will default to ``total products price``. The ``products taxes`` and ``profit`` will be shown -since ``order price`` cannot be less that ``product taxes``. +since ``order price`` cannot be less that ``product taxes``. .. image:: ../backoffice-order-create.price-section.svg :width: 800 @@ -126,7 +126,7 @@ Create order: Payment section This section show optional values that can be overwritten by the merchant * ``refund deadline``: calendar type of input. default from instance - + * ``pay deadline``: calendar type of input. default from instance * ``auto refund deadline``: calendar type of input. default empty, optional. @@ -155,12 +155,12 @@ An example of how all section in a page will be shown. Creation order success -********************** +...................... A success message showing the amount, summary and the order id. Additionally the -taler_pay_uri can be shown to be copied to send to the customer. +taler_pay_uri can be shown to be copied to send to the customer. -action buttons that allow the following: +action buttons that allow the following: * create another payment: go to the create payment page again * view details: show details of the payment (see page) @@ -177,11 +177,11 @@ indicated: * refunded: red Header -^^^^^^ +...... This is a resume of most important information -* big status with color +* big status with color * date * total @@ -194,9 +194,9 @@ This is a resume of most important information * actions: refund (if not refunded), add note, copy order_status_url Timeline of events -^^^^^^^^^^^^^^^^^^ +.................. -Event of status changed over time describe vertically. +Event of status changed over time describe vertically. Sorted from newest to oldest. On line per status updated, with datetime and a short description. @@ -216,7 +216,7 @@ Info taken from: Error status -^^^^^^^^^^^^ +............ This section is not going to be shown if there is no error @@ -227,7 +227,7 @@ This section is not going to be shown if there is no error and exchange_hc Payment details -^^^^^^^^^^^^^^^ +............... If the order was claimed @@ -238,9 +238,9 @@ If the order was claimed * net (deposit_total - refund_amount) * current status - + Contract Terms -^^^^^^^^^^^^^^ +.............. collapsed as default. show disabled if unpaid @@ -271,7 +271,7 @@ collapsed as default. show disabled if unpaid refund popup ------------- +............ If there is any refund: @@ -284,7 +284,7 @@ Warn if there is a pending refund when ``refund_pending`` is true Ask for: * amount: default 0, show max amount refundable (order amount - already - refunded) + refunded) * reason: concatenation of the next values @@ -320,7 +320,7 @@ Alternatives pagination ------------ +---------- order list was originally thought with pagination footer .. image:: ../backoffice-order-list.pagination.svg @@ -363,11 +363,11 @@ Discussion / Q&A Is there any other case? Is this taking into account auto_refund? * Field left out in the order creation: - + * contractTerm.summary_i18n: it makes the UI complex * contractTerm.order_id: should be created by the backend * contractTerm.timestamp: defined by backend * contractTerm.merchant_pub: filled by the backend * contractTerm.merchant_base_url: filled by the backend * contractTerm.h_wire: defined by the backend - * contractTerm.nonce: not used
\ No newline at end of file + * contractTerm.nonce: not used diff --git a/design-documents/018-contract-json.rst b/design-documents/018-contract-json.rst index 2162d6ed..d7f78257 100644 --- a/design-documents/018-contract-json.rst +++ b/design-documents/018-contract-json.rst @@ -63,7 +63,7 @@ parent object. .. code-block:: json { - "delivery_address": ..., + "delivery_address": "...", "$forgettable": { "delivery_address": "<salt>" }, @@ -96,7 +96,7 @@ member of the parent object. { ...props, - "delivery_address": ..., + "delivery_address": "...", "$forgettable": { "delivery_address": "<memb_salt>" }, @@ -174,7 +174,7 @@ a minimal interoperability test: Hashing the above contract results in the following Crockford base32 encoded hash -``287VXK8T6PXKD05W8Y94QJNEFCMRXBC9S7KNKTWGH2G2J2D7RYKPSHNH1HG9NT1K2HRHGC67W6QM6GEC4BSN1DPNEBCS0AVDT2DBP5G''. +``287VXK8T6PXKD05W8Y94QJNEFCMRXBC9S7KNKTWGH2G2J2D7RYKPSHNH1HG9NT1K2HRHGC67W6QM6GEC4BSN1DPNEBCS0AVDT2DBP5G``. Note that typically the salt values must be chosen at random, only for this test we use static salt values. diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst index 6a7a3028..58dc9463 100644 --- a/taler-auditor-manual.rst +++ b/taler-auditor-manual.rst @@ -332,7 +332,7 @@ The ``helper`` user that is used to download information from the exchange needs to know details about the exchange. Similarly, the ``offline`` user needs to check signatures signed with the exchange's offline key. Hence, you need to obtain the ``MASTER_PUBLIC_KEY`` from the exchange operator (they need -to run `taler-exchange-offline setup`) and the REST endpoint of the exchange +to run ``taler-exchange-offline setup``) and the REST endpoint of the exchange and configure these: .. code-block:: console @@ -370,7 +370,7 @@ is to extract the public key: This public key must then be provided in the configuration file of the ``auditor`` user in the ``[auditor]]`` configuration section: -- ``PUBLIC_KEY``: Public key of the auditor, in Base32 encoding. +- ``PUBLIC_KEY``: Public key of the auditor, in Base32 encoding. Set from value printed by ``taler-auditor-offline setup``. You can set this configuration value using: diff --git a/taler-mcig.rst b/taler-mcig.rst index e7c89a67..d1247aee 100644 --- a/taler-mcig.rst +++ b/taler-mcig.rst @@ -67,20 +67,21 @@ This guide assumes you and the customer agree to use the Taler payment system. At this point, you generate a *contract* and present it to the customer for authorization. The contract includes: + - the total amount due; - a short summary; - a *fulfillment URI*; -- the *duration* of the offer - (how long the customer has to authorize before timeout); -- (optional) an itemized product list, with +- the *duration* of the offer (how long the customer has to authorize before timeout); +- (optional) an itemized product list, with: + - (optional) some kind of identification for the selected product(s); + - (optional) applicable taxes and fee limits; - (optional) an order ID (if omitted, the backend will auto-generate one); - (optional) information which details are *forgettable*; - (optional) a *claim token* that the customer can use later; - (optional) information on the *refund deadline*; -- (optional) information on the the *auto-refund period* (how long does - the wallet check for refunds without user prompting for it). +- (optional) information on the the *auto-refund period* (how long does the wallet check for refunds without user prompting for it). If the customer does nothing (timeout / the contract expires), the merchant backend automatically *unlocks* the product(s), @@ -400,12 +401,11 @@ M: :http:post:`/instances/default/private/orders` } Notes: + - There is no ``refund_delay`` field (no refunds possible). -- We show the ``create_token`` field with value ``true`` even though - that is the default (for illustrative purposes). +- We show the ``create_token`` field with value ``true`` even though that is the default (for illustrative purposes). - The ``order`` value is actually a ``MinimalOrderDetail`` object. -- The ``fulfillment_URI`` value includes the product ID and the literal - string ``${ORDER_ID}``, to be replaced by the backend-generated order ID. +- The ``fulfillment_URI`` value includes the product ID and the literal string ``${ORDER_ID}``, to be replaced by the backend-generated order ID. The backend returns ``200 OK`` with the body: @@ -436,10 +436,10 @@ W: :http:post:`/orders/G93420934823/claim` } Notes: + - The ``nonce`` value is a randomly-generated string. - The POST endpoint includes the order ID ``G93420934823``. -- The ``token`` value is the claim token ``TEUFHEFBQALK`` - received in the ``PostOrderResponse``. +- The ``token`` value is the claim token ``TEUFHEFBQALK`` received in the ``PostOrderResponse``. The backend returns ``200 OK`` with body: @@ -483,6 +483,7 @@ The backend returns ``200 OK`` with body: } Notes: + - The backend determined both fees to be 0.015 KUDOS. Because the amortization is 1 (one), both fees (processing and wire transfer) are included in full. @@ -535,6 +536,7 @@ W: :http:post:`/orders/G93420934823/pay` } Notes: + - There is no session ID in the ``PayRequest`` object. - The total of the contribution is 8.0 + 2.0 = 10.0 KUDOS, which is enough to cover the purchase price (9.900 KUDOS diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst index 9a3c94f4..5301cc28 100644 --- a/taler-merchant-manual.rst +++ b/taler-merchant-manual.rst @@ -806,7 +806,7 @@ Setup ------ With the knowledge of the ``payto://``-URI, instances can be configured by POSTing -a request to :http:post:`/management/instances`. To create a first instance, +a request to ``/management/instances``. To create a first instance, create a file ``instance.json`` with an `InstanceConfigurationMessage` .. code-block:: json @@ -1241,8 +1241,7 @@ Authorize a tip When your frontend has reached the point where a client is supposed to receive a tip, it needs to first authorize the tip. For this, the frontend must use -the :http:post:`/private/reserves/$RESERVE_PUB/authorize-tip` -API of the backend. To authorize a +a POST to ``/private/reserves/$RESERVE_PUB/authorize-tip``. To authorize a tip, the frontend has to provide the following information in the body of the POST request: @@ -1272,7 +1271,7 @@ Picking up of the tip --------------------- The wallet will POST a JSON object to the shop’s -:http:post:`/tips/$TIP_ID/pickup` handler. +``/tips/$TIP_ID/pickup`` handler. The frontend must then forward this request to the backend. The response generated by the backend can then be forwarded directly to the wallet. |