[taler-docs] branch master updated: remove rewards, fix links

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 8daac5d9 remove rewards, fix links
8daac5d9 is described below

commit 8daac5d9293a6bb7ad80bd646cca211079234e38
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Feb 8 16:42:28 2024 +0100

    remove rewards, fix links
---
 core/api-auditor.rst      |  14 +++---
 core/api-common.rst       |   2 +-
 taler-merchant-manual.rst |   3 +-
 taler-user-guide.rst      | 109 ----------------------------------------------
 4 files changed, 10 insertions(+), 118 deletions(-)

diff --git a/core/api-auditor.rst b/core/api-auditor.rst
index dcb39864..61e448b8 100644
--- 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
index 863d3099..5dc0c791 100644
--- 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
index dcf518e7..04aadb5d 100644
--- 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
index a88faae3..8b7a5ed1 100644
--- 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.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.