commit 8daac5d9293a6bb7ad80bd646cca211079234e38
parent ab72f7349e965768ade45b5edd68c31d1cf8298a
Author: Christian Grothoff <christian@grothoff.org>
Date: Thu, 8 Feb 2024 16:42:28 +0100
remove rewards, fix links
Diffstat:
4 files changed, 10 insertions(+), 118 deletions(-)
diff --git a/core/api-auditor.rst b/core/api-auditor.rst
@@ -351,14 +351,14 @@ This API is used to obtain a list of all the balances that are stored by the aud
**Details:**
- .. ts:def:: Balances
+ .. ts:def:: BalanceList
interface BalanceList {
// Total amount reported
- auditor_total_reported_balance: taler_amount;
+ auditor_total_reported_balance: Amount;
// Amount potentially missing
- auditor_missing_balance: taler_amount;
+ auditor_missing_balance: Amount;
//...
}
@@ -402,16 +402,16 @@ This API is used by the auditor to obtain a list of pending denominations
interface PendingDenomination {
// Balance of denomination.
- denom_balance: taler_amount;
+ denom_balance: Amount;
// Amount that was lost due to failures by the exchange.
- denom_loss: taler_amount;
+ denom_loss: Amount;
// Amount at risk of loss due to recoup operations.
- denom_risk: taler_amount;
+ denom_risk: Amount;
// Amount actually lost due to recoup operations after a revocation.
- recoup_loss: taler_amount;
+ recoup_loss: Amount;
}
.. note::
diff --git a/core/api-common.rst b/core/api-common.rst
@@ -1043,7 +1043,7 @@ within the
};
-.. _TALER_DepositRequestPS:
+.. _taler_depositrequestps:
.. sourcecode:: c
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
@@ -152,11 +152,12 @@ main Taler configuration (especially the accepted *currency* and *exchanges*).
acceptable to consider instances to be the "users" or "accounts" of a
merchant backend and the bearer token is equivalent to a passphrase.
+.. _instance-bank-account:
Instance Bank Accounts
----------------------
-.. index:: instance-bank-account
+.. index:: Bank account
To receive payments, an instance must have configured one or more bank
*accounts*. When configuring the bank account of an instance, one should
diff --git a/taler-user-guide.rst b/taler-user-guide.rst
@@ -322,112 +322,3 @@ Mustach templating engine:
* reason: the reason entered by the merchant staff for granting the refund;
be careful, you probably want to inform your staff if a webhook may expose
this information to the consumer
-
-
-.. _Rewarding-visitors:
-
-Rewarding visitors
-==================
-
-.. index:: rewards
-
-Taler can also be used to reward digital cash to Web site visitors. For
-example, you may be running an online survey, and you want to reward those
-people that have dutifully completed the survey. If they have installed a
-Taler wallet, you can provide them with a reward for their deeds. This section
-describes how to setup the Taler merchant backend for rewarding.
-
-There are three basic steps that must happen to reward a visitor.
-
-.. _Fund-the-reserve:
-
-Fund the reserve
-----------------
-
-.. index:: reserve
-
-First, the reserve must be setup in the merchant backend. A reserve
-is always tied to a particular instance. To create a reserve with
-10 KUDOS at instance ``default`` using the demo exchange, use:
-
-.. code-block:: console
-
- $ taler-merchant-setup-reserve \
- -a KUDOS:10 \
- -e https://exchange.demo.taler.net/ \
- -m http://localhost:8888/instances/default
-
-The above command assumes that the merchant runs on localhost on
-port 8888.
-For more information, including how to transmit authentication information
-to the backend, see :doc:`manpages/taler-merchant-setup-reserve.1`.
-
-The command will output a ``payto://`` URI which specifies where to
-wire the funds and which wire transfer subject to use.
-
- .. note::
-
- FIXME: add full example output.
-
-In our example, the output for the wire transfer subject is:
-
-.. code-block:: none
-
- QPE24X8PBX3BZ6E7GQ5VAVHV32FWTTCADR0TRQ183MSSJD2CHNEG
-
-You now need to make a wire transfer to the exchange’s bank account
-using the given wire transfer subject.
-
-Make your wire transfer and (optionally) check at
-“https://exchange/reserves/QPE24X...” whether your transfer has arrived at the
-exchange.
-
-Once the funds have arrived, you can start to use the reserve for
-rewarding.
-
-Note that an exchange will typically close a reserve after four weeks, wiring
-all remaining funds back to the sender’s account. Thus, you should plan to
-wire funds corresponding to a campaign of about two weeks to the exchange
-initially. If your campaign runs longer, you should setup another reserve
-every other week to ensure one is always ready.
-
-.. _Authorize-a-reward:
-
-Authorize a reward
-------------------
-
-When your frontend has reached the point where a client is supposed to receive
-a reward, it needs to first authorize the reward. For this, the frontend must use
-a POST to ``/private/reserves/$RESERVE_PUB/authorize-reward``. To authorize a
-reward, the frontend has to provide the following information in the body of the
-POST request:
-
-- The amount of the reward
-
-- The justification (only used internally for the back-office)
-
-- The URL where the wallet should navigate next after the reward was
- processed
-
-- The reward-pickup URL (see next section)
-
-In response to this request, the backend will return a reward token, an
-expiration time and the exchange URL. The expiration time will indicate
-how long the reward is valid (when the reserve expires). The reward token is
-an opaque string that contains all the information needed by the wallet
-to process the reward. The frontend must send this reward token to the browser
-in a special “402 Payment Required” response inside the ``Taler``
-header.
-
-The frontend should handle errors returned by the backend, such as
-misconfigured instances or a lack of remaining funds for rewarding.
-
-.. _Picking-up-of-the-reward:
-
-Picking up of the reward
-------------------------
-
-The wallet will POST a JSON object to the shop’s
-``/rewards/$REWARD_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.
