remove reward-related APIs and design considerations

20 files changed, 40 insertions, 829 deletions

diff --git a/checklist-demo-upgrade.rst b/checklist-demo-upgrade.rst
index c45c1847..d8724030 100644
--- a/checklist-demo-upgrade.rst
+++ b/checklist-demo-upgrade.rst
@@ -136,7 +136,6 @@ Merchant SPA
 - |democheck| edit template to add TOTP device, set price to fixed, summary to be entered
 - |democheck| scan template QR code, edit summary and pay
 - |democheck| check displayed TOTP code matches TOTP app
-- |democheck| create reserve for rewards
 - |democheck| do manual wire transfer in bank to establish reserve funding
 - |democheck| check that partially refunded order is marked as awaiting wire transfer
 - |democheck| check bank wired funds to merchant (if needed, wait)
@@ -148,14 +147,6 @@ Merchant SPA
 - |democheck| check that orders are marked as completed
 
 
-Survey/Rewards
-^^^^^^^^^^^^^^
-
-- |democheck| Visit https://survey.demo.taler.net/ and receive a reward.
-- |democheck| Verify that the survey stats page (https://survey.demo.taler.net/survey-stats) is working,
-  and that the survey reserve has sufficient funds.
-
-
 P2P payments
 ^^^^^^^^^^^^
 
@@ -180,4 +171,3 @@ Shutdown
 - |democheck| enter bank account (if possible)
 - |democheck| wallet balance goes to zero
 - |democheck| specified bank account receives remaining balance
-
diff --git a/core/api-exchange.rst b/core/api-exchange.rst
index 0e79ae6b..f7d63d0e 100644
--- a/core/api-exchange.rst
+++ b/core/api-exchange.rst
@@ -198,7 +198,8 @@ possibly by using HTTPS.
 
       // Set to true if this exchange allows the use
       // of reserves for rewards.
-      rewards_allowed: boolean;
+      // @deprecated in protocol v18.
+      rewards_allowed: false;
 
       // EdDSA master public key of the exchange, used to sign entries
       // in ``denoms`` and ``signkeys``.
@@ -5071,12 +5072,12 @@ Reserve control
 ---------------
 
 This section describes the reserve control API which can be used to (1)
-prevent a reserve from expiring (which is useful if the reserve is used for
-rewards), to (2) pay an annual fee to allow a number of purses to be created
-for the respective reserve without paying a purse fee each time, to (3) obtain
-KYC information associated with a reserve to prove the identity of the person
-sending an invoice to the payer, and to (4) close a reserve before it would
-naturally expire and possibly (5) wire the funds to a designated account.
+prevent a reserve from expiring, to (2) pay an annual fee to allow a number of
+purses to be created for the respective reserve without paying a purse fee
+each time, to (3) obtain KYC information associated with a reserve to prove
+the identity of the person sending an invoice to the payer, and to (4) close a
+reserve before it would naturally expire and possibly (5) wire the funds to a
+designated account.
 
   .. note::
 
@@ -5084,7 +5085,7 @@ naturally expire and possibly (5) wire the funds to a designated account.
 
 .. http:post:: /reserves/$RESERVE_PUB/open
 
-  Request keeping a reserve open for rewards or invoicing.
+  Request keeping a reserve open for invoicing.
 
   **Request:**
 
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
index 652c7303..46392118 100644
--- a/core/api-merchant.rst
+++ b/core/api-merchant.rst
@@ -199,8 +199,7 @@ This section describes (public) endpoints that wallets must be able
 to interact with directly (without HTTP-based authentication). These
 endpoints are used to process payments (claiming an order, paying
 for the order, checking payment/refund status and aborting payments),
-process refunds (checking refund status, obtaining the refund),
-and to pick up rewards.
+and to process refunds (checking refund status, obtaining the refund).
 
 
 Claiming an order
@@ -837,111 +836,6 @@ the contract. Refunds must be approved by the merchant's business logic.
     }
 
 
-Picking up rewards
-------------------
-
-Rewards are a way for wallets to obtain e-cash from
-a website.
-
-.. http:get:: [/instances/$INSTANCE]/rewards/$REWARD_ID
-
-  Handle request from wallet to provide details about a reward.
-
-  This endpoint typically also supports requests with the "Accept" header
-  requesting "text/html".  In this case, an HTML response suitable for
-  triggering the interaction with the wallet is returned. If the backend
-  installation does not include the required HTML templates, a 406 status
-  code is returned.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    A reward is being returned. The backend responds with a `RewardInformation`.
-  :http:statuscode:`404 Not found`:
-    The reward identifier is unknown.
-  :http:statuscode:`406 Not acceptable`:
-    The merchant backend could not load the template required to generate a reply in the desired format. (Likely HTML templates were not properly installed.)
-  :http:statuscode:`410 Gone`:
-    A reward has been fully claimed. The JSON reply still contains the `RewardInformation`.
-
-  .. ts:def:: RewardInformation
-
-    interface RewardInformation {
-
-      // Exchange from which the reward will be withdrawn. Needed by the
-      // wallet to determine denominations, fees, etc.
-      exchange_url: string;
-
-      // URL where to go after obtaining the reward.
-      next_url: string;
-
-      // (Remaining) amount of the reward (including fees).
-      reward_amount: Amount;
-
-      // Timestamp indicating when the reward is set to expire (may be in the past).
-      // Note that rewards that have expired MAY also result in a 404 response.
-      expiration: Timestamp;
-    }
-
-
-.. http:post:: [/instances/$INSTANCE]/rewards/$REWARD_ID/pickup
-
-  Handle request from wallet to pick up a reward.
-
-  **Request:**
-
-  The request body is a `RewardPickupRequest` object.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    A reward is being returned. The backend responds with a `RewardResponse`.
-  :http:statuscode:`401 Unauthorized`:
-    The reward amount requested exceeds the reward.
-  :http:statuscode:`404 Not found`:
-    The reward identifier is unknown.
-  :http:statuscode:`409 Conflict`:
-    Some of the denomination key hashes of the request do not match those currently available from the exchange (hence there is a conflict between what the wallet requests and what the merchant believes the exchange can provide).
-  :http:statuscode:`410 Gone`:
-    The reward has expired.
-
-  .. ts:def:: RewardPickupRequest
-
-    interface RewardPickupRequest {
-
-      // List of planchets the wallet wants to use for the reward.
-      planchets: PlanchetDetail[];
-    }
-
-  .. ts:def:: PlanchetDetail
-
-    interface PlanchetDetail {
-      // Hash of the denomination's public key (hashed to reduce
-      // bandwidth consumption).
-      denom_pub_hash: HashCode;
-
-      // Coin's blinded public key.
-      coin_ev: CoinEnvelope;
-    }
-
-  .. ts:def:: RewardResponse
-
-    interface RewardResponse {
-
-      // Blind RSA signatures over the planchets.
-      // The order of the signatures matches the planchets list.
-      blind_sigs: BlindSignature[];
-    }
-
-  .. ts:def:: BlindSignature
-
-    interface BlindSignature {
-
-      // The (blind) RSA signature. Still needs to be unblinded.
-      blind_sig: BlindedRsaSignature;
-    }
-
-
 -------------------
 Instance management
 -------------------
@@ -2698,439 +2592,6 @@ once we got a reply from the exchange.
     The transfer cannot be deleted anymore.
 
 
-.. _api-rewards:
-
------------------------
-Backend: Giving rewards
------------------------
-
-.. note::
-
-  This API is deprecated as of protocol v8.
-
-Rewards are a way for websites to give small amounts of e-cash to visitors (for
-example as a financial reward for providing information or viewing
-advertisements).  Rewards are non-contractual: neither merchant nor consumer
-have any contractual information about the other party as a result of the
-reward.
-
-
-Create reserve
---------------
-
-.. note::
-
-  This API is deprecated as of protocol v8.
-
-Reserves are basically funds a merchant has provided to an exchange for a
-rewards campaign. Each reserve has a limited lifetime (say 2--4 weeks). Any
-funds not used to reward customers will automatically be wired back from the
-exchange to the originating account.
-
-Before handing out rewards, a merchant must tell the backend to set up a
-reserve. The backend will return a reserve public key which must be used as
-the wire transfer subject when wiring the reward campaign funds to the
-exchange.
-
-.. http:post:: [/instances/$INSTANCE]/private/reserves
-
-  Create a reserve for rewards.
-
-  This request is **not** idempotent.  However, while repeating
-  it will create another reserve, that is generally pretty harmless
-  (assuming only one of the reserves is filled with a wire transfer).
-  Clients may want to eventually delete the unused reserves to
-  avoid clutter.
-
-  **Request:**
-
-  The request body is a `ReserveCreateRequest` object.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    The backend is waiting for the reserve to be established. The merchant
-    must now perform the wire transfer indicated in the `ReserveCreateConfirmation`.
-  :http:statuscode:`408 Request timeout`:
-    The exchange did not respond on time.
-  :http:statuscode:`409 Conflict`:
-    The exchange does not support the requested wire method or does not allow rewards.
-  :http:statuscode:`502 Bad gateway`:
-    We could not obtain ``/wire`` details from the specified exchange base URL.
-  :http:statuscode:`504 Gateway timeout`:
-    The merchant's interaction with the exchange took too long.
-    The client might want to try again later.
-
-  .. ts:def:: ReserveCreateRequest
-
-    interface ReserveCreateRequest {
-      // Amount that the merchant promises to put into the reserve.
-      initial_balance: Amount;
-
-      // Exchange the merchant intends to use for rewards.
-      exchange_url: string;
-
-      // Desired wire method, for example "iban" or "x-taler-bank".
-      wire_method: string;
-    }
-
-  .. ts:def:: ReserveCreateConfirmation
-
-    interface ReserveCreateConfirmation {
-      // Public key identifying the reserve.
-      reserve_pub: EddsaPublicKey;
-
-      // Wire accounts of the exchange where to transfer the funds.
-      accounts: WireAccount[];
-    }
-
-.. http:get:: [/instances/$INSTANCE]/private/reserves
-
-  Obtain list of reserves that have been created for rewards.
-
-  **Request:**
-
-  :query after: *Optional*.  Only return reserves created after the given timestamp in milliseconds.
-  :query active: *Optional*.  Only return active/inactive reserves depending on the boolean given.
-  :query failures: *Optional*.  Only return reserves where we disagree with the exchange about the initial balance.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    Returns a list of known reward reserves.
-    The body is a `RewardReserveStatus`.
-
-  .. ts:def:: RewardReserveStatus
-
-    interface RewardReserveStatus {
-      // Array of all known reserves (possibly empty!).
-      reserves: ReserveStatusEntry[];
-    }
-
-  .. ts:def:: ReserveStatusEntry
-
-     interface ReserveStatusEntry {
-      // Public key of the reserve.
-      reserve_pub: EddsaPublicKey;
-
-      // Timestamp when it was established.
-      creation_time: Timestamp;
-
-      // Timestamp when it expires.
-      expiration_time: Timestamp;
-
-      // Initial amount as per reserve creation call.
-      merchant_initial_amount: Amount;
-
-      // Initial amount as per exchange, 0 if exchange did
-      // not confirm reserve creation yet.
-      exchange_initial_amount: Amount;
-
-      // Amount picked up so far.
-      pickup_amount: Amount;
-
-      // Amount approved for rewards that exceeds the pickup_amount.
-      committed_amount: Amount;
-
-      // Is this reserve active (false if it was deleted but not purged)?
-      active: boolean;
-    }
-
-
-Query funds remaining
----------------------
-
-.. http:get:: [/instances/$INSTANCE]/private/reserves/$RESERVE_PUB
-
-  Obtain information about a specific reserve that have been created for rewards.
-
-  **Request:**
-
-  :query rewards: *Optional*. If set to "yes", returns also information about all of the rewards created.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    Returns the `ReserveDetail`.
-  :http:statuscode:`404 Not found`:
-    The reward reserve is not known.
-  :http:statuscode:`502 Bad gateway`:
-    We are having trouble with the request because of a problem with the exchange.
-    Likely returned with an "exchange_code" in addition to a "code" and
-    an "exchange_http_status" in addition to our own HTTP status. Also usually
-    includes the full exchange reply to our request under "exchange_reply".
-    This is only returned if there was actual trouble with the exchange, not
-    if the exchange merely did not respond yet or if it responded that the
-    reserve was not yet filled.
-  :http:statuscode:`504 Gateway timeout`:
-    The merchant's interaction with the exchange took too long.
-    The client might want to try again later.
-
-  .. ts:def:: ReserveDetail
-
-    interface ReserveDetail {
-      // Timestamp when it was established.
-      creation_time: Timestamp;
-
-      // Timestamp when it expires.
-      expiration_time: Timestamp;
-
-      // Initial amount as per reserve creation call.
-      merchant_initial_amount: Amount;
-
-      // Initial amount as per exchange, 0 if exchange did
-      // not confirm reserve creation yet.
-      exchange_initial_amount: Amount;
-
-      // Amount picked up so far.
-      pickup_amount: Amount;
-
-      // Amount approved for rewards that exceeds the pickup_amount.
-      committed_amount: Amount;
-
-      // Array of all rewards created by this reserves (possibly empty!).
-      // Only present if asked for explicitly.
-      rewards?: RewardStatusEntry[];
-
-      // Is this reserve active (false if it was deleted but not purged)?
-      active: boolean;
-
-      // Array of wire accounts of the exchange that could
-      // be used to fill the reserve, can be NULL
-      // if the reserve is inactive or was already filled
-      accounts?: WireAccount[];
-
-      // URL of the exchange hosting the reserve,
-      // NULL if the reserve is inactive
-      exchange_url: string;
-    }
-
-  .. ts:def:: RewardStatusEntry
-
-    interface RewardStatusEntry {
-
-      // Unique identifier for the reward.
-      reward_id: HashCode;
-
-      // Total amount of the reward that can be withdrawn.
-      total_amount: Amount;
-
-      // Human-readable reason for why the reward was granted.
-      reason: string;
-    }
-
-
-Authorizing rewards
--------------------
-
-.. note::
-
-  This API is deprecated as of protocol v8.
-
-.. http:post:: [/instances/$INSTANCE]/private/reserves/$RESERVE_PUB/authorize-reward
-
-  Authorize creation of a reward from the given reserve.
-
-  **Request:**
-
-  The request body is a `RewardCreateRequest` object.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    A reward has been created. The backend responds with a `RewardCreateConfirmation`.
-  :http:statuscode:`404 Not found`:
-    The instance or the reserve is unknown to the backend.
-  :http:statuscode:`412 Precondition failed`:
-    The reward amount requested exceeds the available reserve balance for rewards.
-
-  .. ts:def:: RewardCreateRequest
-
-    interface RewardCreateRequest {
-      // Amount that the customer should be rewarded.
-      amount: Amount;
-
-      // Justification for giving the reward.
-      justification: string;
-
-      // URL that the user should be directed to after receiving the reward,
-      // will be included in the reward_token.
-      next_url: string;
-    }
-
-  .. ts:def:: RewardCreateConfirmation
-
-    interface RewardCreateConfirmation {
-      // Unique reward identifier for the reward that was created.
-      reward_id: HashCode;
-
-      // taler://reward URI for the reward.
-      taler_reward_uri: string;
-
-      // URL that will directly trigger processing
-      // the reward when the browser is redirected to it.
-      reward_status_url: string;
-
-      // When does the reward expire?
-      reward_expiration: Timestamp;
-    }
-
-
-.. http:post:: [/instances/$INSTANCE]/private/rewards
-
-  Authorize creation of a reward, with
-  automatic selection of a working reserve of the instance by the
-  backend. Intentionally otherwise identical to the ``/authorize-reward``
-  endpoint given above.
-
-  **Request:**
-
-  The request body is a `RewardCreateRequest` object.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    A reward has been created. The backend responds with a `RewardCreateConfirmation`.
-  :http:statuscode:`404 Not found`:
-    The instance is unknown to the backend.
-  :http:statuscode:`412 Precondition failed`:
-    The reward amount requested exceeds the available reserve balance for rewards
-    in all of the reserves of the instance.
-
-
-Deleting reserves
------------------
-
-.. note::
-
-  This API is deprecated as of protocol v8.
-
-.. http:delete:: [/instances/$INSTANCE]/private/reserves/$RESERVE_PUB
-
-  Delete information about a reserve.  Fails if the reserve still has
-  committed to rewards that were not yet picked up and that have not yet
-  expired.
-
-  **Request:**
-
-  :query purge: *Optional*. If set to YES, the reserve and all information
-      about rewards it issued will be fully deleted.
-      Otherwise only the private key would be deleted.
-
-  **Response:**
-
-  :http:statuscode:`204 No content`:
-    The backend has successfully deleted the reserve.
-  :http:statuscode:`404 Not found`:
-    The backend does not know the instance or the reserve.
-  :http:statuscode:`409 Conflict`:
-    The backend refuses to delete the reserve (committed rewards awaiting pickup).
-
-
-Checking reward status
-----------------------
-
-.. note::
-
-  This API is deprecated as of protocol v8.
-
-.. http:get:: [/instances/$INSTANCE]/private/rewards/$REWARD_ID
-
-  Obtain information about a particular reward.
-
-  **Request:**
-
-  :query pickups: *Optional*. If set to "yes", returns also information about all of the pickups.
-  :query min_amount: *Optional*. Minimum pick-up amount the client is interested in.
-  :query timeout_ms=NUMBER: *Optional.*  If specified, the merchant backend will
-    wait up to ``timeout_ms`` milliseconds for rewards of at least min_pick_up to be
-    picked up.  A client must never rely on this behavior, as the
-    merchant backend may return a response immediately.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    The reward is known. The backend responds with a `RewardDetails` message.
-  :http:statuscode:`404 Not found`:
-    The reward is unknown to the backend.
-
-  .. ts:def:: RewardDetails
-
-    interface RewardDetails {
-      // Amount that we authorized for this reward.
-      total_authorized: Amount;
-
-      // Amount that was picked up by the user already.
-      total_picked_up: Amount;
-
-      // Human-readable reason given when authorizing the reward.
-      reason: string;
-
-      // Timestamp indicating when the reward is set to expire (may be in the past).
-      expiration: Timestamp;
-
-      // Reserve public key from which the reward is funded.
-      reserve_pub: EddsaPublicKey;
-
-      // Array showing the pickup operations of the wallet (possibly empty!).
-      // Only present if asked for explicitly.
-      pickups?: PickupDetail[];
-    }
-
-  .. ts:def:: PickupDetail
-
-    interface PickupDetail {
-      // Unique identifier for the pickup operation.
-      pickup_id: HashCode;
-
-      // Number of planchets involved.
-      num_planchets: Integer;
-
-      // Total amount requested for this pickup_id.
-      requested_amount: Amount;
-    }
-
-
-.. http:get:: [/instances/$INSTANCE]/private/rewards
-
-  Return the list of all rewards.
-
-  **Request:**
-
-  :query include_expired: *Optional*. If set to "yes", the result includes expired rewards also. Otherwise, only active rewards are returned.
-
-  :query limit: *Optional*. At most return the given number of results. Negative for descending in database row id, positive for ascending in database row id.
-
-  :query offset: *Optional*. Starting ``row_id`` for an iteration.
-
-  **Response:**
-
-  :http:statuscode:`200 OK`:
-    The backend has successfully found the list of rewards. The backend responds
-    with a `RewardsResponse`.
-
-  .. ts:def:: RewardsResponse
-
-    interface RewardsResponse {
-
-      // List of rewards that are present in the backend.
-      rewards: Reward[];
-    }
-
-  .. ts:def:: Reward
-
-     interface Reward {
-
-      // ID of the reward in the backend database.
-      row_id: number;
-
-      // Unique identifier for the reward.
-      reward_id: HashCode;
-
-      // (Remaining) amount of the reward (including fees).
-      reward_amount: Amount;
-    }
-
 -----------
 OTP Devices
 -----------
diff --git a/design-documents/014-merchant-backoffice-ui.rst b/design-documents/014-merchant-backoffice-ui.rst
index eaf435a4..1f744a15 100644
--- a/design-documents/014-merchant-backoffice-ui.rst
+++ b/design-documents/014-merchant-backoffice-ui.rst
@@ -139,11 +139,3 @@ Story #4: Manage inventory
 - change product description / price / etc.
 
 - delete products from inventory
-
-
-Story #5: Manage rewards
-------------------------
-
-- set up reward reserve
-
-- check reward reserve status
diff --git a/design-documents/020-backoffice-rewards-management.rst b/design-documents/020-backoffice-rewards-management.rst
index 1eef39b1..8345a3b9 100644
--- a/design-documents/020-backoffice-rewards-management.rst
+++ b/design-documents/020-backoffice-rewards-management.rst
@@ -1,4 +1,4 @@
-DD 20: Backoffice Rewards Management
+XX 20: Backoffice Rewards Management
 ####################################
 
 Summary
diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst
index 4d8f2cbc..d34241d7 100644
--- a/design-documents/023-taler-kyc.rst
+++ b/design-documents/023-taler-kyc.rst
@@ -40,7 +40,7 @@ Taler needs to run KYC checks in the following circumstances:
 
   * key: IBAN (encoded as payto:// URI)
 
-* Reserve is "opened" for invoicing or rewards.
+* Reserve is "opened" for invoicing.
 
   * key: reserve (=KYC account) long term public key per wallet (encoded as payto:// URI)
 
diff --git a/design-documents/031-invoicing.rst b/design-documents/031-invoicing.rst
index cfe776ed..0fcc88fd 100644
--- a/design-documents/031-invoicing.rst
+++ b/design-documents/031-invoicing.rst
@@ -4,9 +4,7 @@ DD 31: Invoicing
 Summary
 =======
 
-This document proposes new endpoints to support invoicing,
-that incidentally also address the long-standing rewards
-reserve expiration problem.
+This document proposes new endpoints to support invoicing.
 
 
 Motivation
@@ -36,10 +34,7 @@ Requirements
   * Reasonable UX and overall design impact.
 
   * Wallets may want to pay for the reserve with coins
-    (reserve fresh, not created via bank transfer), while
-    rewarding merchants likely want to pay from the reserve
-    balance itself. So both styles of payment should be
-    supported.
+    (reserve fresh, not created via bank transfer).
 
 Unclear in the current proposal are:
 
@@ -62,12 +57,10 @@ charge the ``account_fee``, bump the number of open purses threshold in the
 ``reserves`` table and stop auto-closing of the reserve. This will ensure that
 the users can withdraw the reserve balance into their wallet even after a
 longer time period. This helps if the invoice is paid after a significant
-delay, and also addresses the unwanted reward reserve closure
-problem. Introduce a way to force an immediate closure of a reserve, allowing
+delay. Introduce a way to force an immediate closure of a reserve, allowing
 P2P reserve from invoices to be send to a bank account (this allows a wallet
 to be used for convenient invoicing and not strictly require the wallet to
-receive the funds) and also allowing the user to recover funds from a reward
-reserve after rewards are no longer issued.
+receive the funds).
 
 The solution needs three new tables for:
 
diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst
index 9d749595..7a8cfacd 100644
--- a/design-documents/037-wallet-transactions-lifecycle.rst
+++ b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -525,64 +525,6 @@ the same as if the double-spending transaction had been deleted by the user.
 .. image:: ../images/transaction-refresh-states.png
 
 
-
-Transaction Type: Reward
-------------------------
-
-* ``pending(user)``
-
-  We have downloaded the metadata for the reward.  This is the initial state for a
-  reward transaction. The user needs to accept/refuse the reward.
-
-  * ``[reward-expired] => expired``
-  * ``[action:accept] => pending(pickup)``
-
-* ``pending(pickup)``
-
-  We are picking up the reward.
-
-  * ``[failure] => failed``: any type of failure, including expiration.
-  * ``[processed-kyc-required] => pending(kyc-required)``
-  * ``[success] => done``
-  * ``[action:suspend] => suspended(pickup)``
-
-* ``suspended(pickup)``
-
-  The user suspended the operation while the reward was being picked up.
-
-  * ``[reward-expired] => failed``
-  * ``[action:resume] => pending(pickup)``
-
-* ``pending(kyc)``
-
-  The user needs to perform a KYC check to continue. This usually should only
-  happen if the wallet balance exceeds some threshold.
-
-  * ``[poll-success] => pending(pickup)``
-  * ``[action:suspend] => suspended(kyc)``
-
-* ``suspended(kyc)``
-
-  The user suspended the KYC operation.  Note that we do not time out here if
-  the reward expires, as the wallet balance threshold KYC likely applies even
-  without the reward.
-
-  * ``[action:resume] => pending(kyc)``
-
-* ``done``
-
-  The reward operation completed.
-
-  * ``[action:delete] => deleted``
-
-* ``deleted``
-
-  All memory of the reward operation is lost, but of course the resulting fresh
-  coins are preserved.
-
-.. image:: ../images/transaction-reward-states.png
-
-
 Transaction Type: Deposit
 -------------------------
 
diff --git a/design-documents/041-wallet-balance-amount-definitions.rst b/design-documents/041-wallet-balance-amount-definitions.rst
index 1c89d634..9943d482 100644
--- a/design-documents/041-wallet-balance-amount-definitions.rst
+++ b/design-documents/041-wallet-balance-amount-definitions.rst
@@ -245,20 +245,6 @@ REFUND
     Is there a way that the merchant can initiate a refund of purchase + refund_fee so
     the wallet will get the same effective_amount?
 
-REWARD
-  raw amount is the amount that the merchant send as reward
-
-  ``instructed_amount`` = reward.amount
-
-  ``raw_amount`` = instructed_amount + withdrawal_fee
-
-  ``effective_amount`` = instructed_amount
-
-  .. note::
-    We should not show fee for rewards in the wallet since the merchant is the one choosing
-    the exchange and we can assume that those rewards are paid by the merchant.
-    So the wallet only care about the effective.
-
 Coin selection algorithm
 ------------------------
 
diff --git a/design-documents/053-wallet-ui.rst b/design-documents/053-wallet-ui.rst
index 5891eb37..5b5ba22d 100644
--- a/design-documents/053-wallet-ui.rst
+++ b/design-documents/053-wallet-ui.rst
@@ -4,7 +4,7 @@ DD 53: Wallet UI Design
 Summary
 =======
 
-This document proposes designs wallet UI. It defines what Android, iOS and 
+This document proposes designs wallet UI. It defines what Android, iOS and
 WebExtension should follow in order to have a coherent UI between platforms.
 
 Motivation
@@ -12,8 +12,8 @@ Motivation
 
 We want user to be able to help each others independent of the implementation
 they are using.
-We want user to be able to capitalize the effort of learning how to use one 
-wallet and be able to use a different one without the need to learn 
+We want user to be able to capitalize the effort of learning how to use one
+wallet and be able to use a different one without the need to learn
 anything new.
 Currently development of different platform specific implementation are independent
 and every developer needs to choose the layout, texts and buttons and navigation.
@@ -25,7 +25,7 @@ Every screen MUST be defined in a document with the following information:
 
 * **Identifiable UI screens**: every UI should have an unique identifier that will
   be use for development discussion and bug reports. There should be an option
-  in the application to enable an active rendering of the id. 
+  in the application to enable an active rendering of the id.
 
 * **Description**: the reason to be of the screen, should help to define what will
   be included into, what is going to left for other screens and when and from
@@ -41,24 +41,24 @@ properties is defined in the spec the implementation must implement it. The spec
 should be minimal to achieve the objective in the description.
 
 * **Info**: Spec of information that the user should have access. The type of info
-  could be a field (id and value) or a banner (information and instructions). 
-  The spec will help to reuse the text for i18n across apps and defined 
+  could be a field (id and value) or a banner (information and instructions).
+  The spec will help to reuse the text for i18n across apps and defined
 
 * **Inputs**: Spec of information need to provide in current screen. The type of input,
   range of values and validation should be defined if necessary.
 
-* **Actions**: Spec of buttons and interactable elements that will have a significant 
+* **Actions**: Spec of buttons and interactable elements that will have a significant
   change in the current state. It should also mention navigation when applicable.
-  
+
 * **Layout**: Spec position of elements when needed. The spec should be "soft" in a sense
-  that elements should be easy to find following directions like "close to X" or 
+  that elements should be easy to find following directions like "close to X" or
   "at the start/end of the screen".
 
-Screen should be defined using the most relaxed definition that are good enough to 
+Screen should be defined using the most relaxed definition that are good enough to
 be clear for the user. Platform will use this definition and adapt to the differences
 on the platform taking advantange of platform API and screen sizes.
 
-When a screen have multiple uses for the same purpose, a substate section should be 
+When a screen have multiple uses for the same purpose, a substate section should be
 included with the difference with the main definition.
 
 Part of the screens that are reused shoud also be defined in this document as screen.
@@ -84,11 +84,11 @@ fee, restrictions and ETA should be clear for the user.
  * exchange to be used showing the URL
  * table of details of the operation: use the ``operation-table-details`` screen
  * starting currency: if the exchange has the currency conversion service enabled user should be able to the details based on the wire transfer currency
- * taler URI: show copy button or QR to complete the operation with another device 
+ * taler URI: show copy button or QR to complete the operation with another device
 
 ``Inputs``:
  * age restriction: allow the selection of the restriction in the age group possible by the exchange
- * service provider: allow the selection of different exchange 
+ * service provider: allow the selection of different exchange
 
 ``Actions``:
  * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed
@@ -111,10 +111,10 @@ fee, restrictions and ETA should be clear for the user.
  * order summary
  * table of details of the operation: use the ``operation-table-details`` screen
  * receipt: order id
- * payment deadline: absolute time before the claimed order expires 
- * taler URI: show copy button or QR to complete the operation with another device 
+ * payment deadline: absolute time before the claimed order expires
+ * taler URI: show copy button or QR to complete the operation with another device
  * cant pay desc: if the user has enough balance but unable to use it
- * payment status: if the 
+ * payment status: if the
 
 ``Actions``:
  * confirm operation: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed
@@ -156,7 +156,7 @@ fee, restrictions and ETA should be clear for the user.
 ``Inputs``:
  * subject: short description of the transaction
  * expiration: absolute time/date after which the invoice is not valid anymore
- * service provider: allow the selection of different exchange 
+ * service provider: allow the selection of different exchange
 
 ``Actions``:
  * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed
@@ -225,24 +225,6 @@ fee, restrictions and ETA should be clear for the user.
  * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen
  * cancel: user will be redirected to ``balance``
 
-cta-reward
------------
-
-``Description``: this screen is used for the confirmation of the acceptance of
-a reward from a merchant.
-the success of this operation will be an will decrease the balance in the wallet.
-fee, restrictions and ETA should be clear for the user.
-
-``Info``:
- * amount: effective amount to receive
- * exchange: from where this money comes from
- * merchant: offering the reward
-
-``Actions``:
- * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed
- * review and confirm ToS: if the current selected exchange has a version  of ToS that the user didn't yet accepted, use the ``accept-tos`` screen
- * cancel: user will be redirected to ``balance``
-
 
 operation-table-details
 -----------------------
@@ -252,12 +234,12 @@ the initial amount and the final amount with all the items related to the operat
 
 ``labels``: initial amount of the operation, and final amount are always shown.
 Fee should be shown as an extra row in the table if it is non-zero.
-Converted amount should be shown as an extra row if initial amount currency is not the same 
+Converted amount should be shown as an extra row if initial amount currency is not the same
 as the final amount currency.
 
 Initial amount label by operation:
 
- * payment -> Price 
+ * payment -> Price
  * deposit -> Send
  * peer-pull-credit -> Invoice
  * peer-pull-debit -> Invoice
@@ -286,4 +268,3 @@ user already accepted ToS)
 
 Q / A
 =====
-
diff --git a/images/Makefile b/images/Makefile
index 3a7fdab9..ad7a695d 100644
--- a/images/Makefile
+++ b/images/Makefile
@@ -1,4 +1,4 @@
-diagrams: regional-arch.png arch-api.png coin.png deposit.png reserve.png transaction-common-states.png transaction-withdrawal-states.png transaction-payment-states.png transaction-refund-states.png transaction-refresh-states.png transaction-reward-states.png transaction-deposit-states.png transaction-push-debit-states.png transaction-push-credit-states.png transaction-pull-credit-states.png transaction-pull-debit-states.png challenger.png
+diagrams: regional-arch.png arch-api.png coin.png deposit.png reserve.png transaction-common-states.png transaction-withdrawal-states.png transaction-payment-states.png transaction-refund-states.png transaction-refresh-states.png transaction-deposit-states.png transaction-push-debit-states.png transaction-push-credit-states.png transaction-pull-credit-states.png transaction-pull-debit-states.png challenger.png
 
 arch-api.png: arch-api.dot
 	dot -Tpng arch-api.dot > arch-api.png
@@ -16,8 +16,6 @@ transaction-refund-states.png: transaction-refund-states.dot
 	dot -Tpng transaction-refund-states.dot > transaction-refund-states.png
 transaction-refresh-states.png: transaction-refresh-states.dot
 	dot -Tpng transaction-refresh-states.dot > transaction-refresh-states.png
-transaction-reward-states.png: transaction-reward-states.dot
-	dot -Tpng transaction-reward-states.dot > transaction-reward-states.png
 transaction-deposit-states.png: transaction-deposit-states.dot
 	dot -Tpng transaction-deposit-states.dot > transaction-deposit-states.png
 transaction-push-debit-states.png: transaction-push-debit-states.dot
diff --git a/images/transaction-reward-states.dot b/images/transaction-reward-states.dot
deleted file mode 100644
index 476c8c74..00000000
--- a/images/transaction-reward-states.dot
+++ /dev/null
@@ -1,11 +0,0 @@
-digraph G {
-  initial[label="", shape="circle"];
-  dialog_user[label="dialog(user)"];
-  pending_pickup[label="pickup"];
-  done[label="done", shape="box"];
-
-  initial -> dialog_user;
-  
-  dialog_user -> pending_pickup [color=blue, label="OK"];
-  pending_pickup -> done [color=green];
-}
diff --git a/manpages/taler-wallet-cli.1.rst b/manpages/taler-wallet-cli.1.rst
index 2d35bb87..dad790f5 100644
--- a/manpages/taler-wallet-cli.1.rst
+++ b/manpages/taler-wallet-cli.1.rst
@@ -46,8 +46,6 @@ for testing.
 
 **withdraw-uri** URI
 
-**reward-uri** URI
-
 **refund-uri** URI
 
 **pay-uri** [**-y** | **--yes**] URI
diff --git a/manpages/taler.conf.5.rst b/manpages/taler.conf.5.rst
index 191c7e59..115dee8a 100644
--- a/manpages/taler.conf.5.rst
+++ b/manpages/taler.conf.5.rst
@@ -162,13 +162,6 @@ AML_THRESHOLD
 KYC_AML_TRIGGER
   Program to run on KYC attribute data to decide whether we should immediately flag an account for AML review. Program must return 0 if a manual AML review is not needed, and non-zero to trigger an AML review. The KYC attribute data of the new user will be passed on standard-input.
 
-ENABLE_REWARDS
-  This option can be used to announce that an exchange does not allow
-  the use of the reserves for rewards. The default is YES which means
-  that rewards are allowed.  The option merely announces that
-  rewards is enabled or disabled, and protocol-compliant merchant
-  backends will then enable or disable the feature accordingly.
-
 STEFAN_ABS
   Absolte amount to add as an offset in the STEFAN fee approximation
   curve (see DD47).  Defaults to CURRENCY:0 if not specified.
diff --git a/orphaned/taler-nfc-guide.rst b/orphaned/taler-nfc-guide.rst
index aa961d31..d025d347 100644
--- a/orphaned/taler-nfc-guide.rst
+++ b/orphaned/taler-nfc-guide.rst
@@ -231,8 +231,8 @@ to dereference the ``taler://pay`` URI from the example above:
   # success response with no data
   m<-w 9000
 
-(Note that this process works analogously for communication between a bank/ATM
-terminal or "reward provider".)
+(Note that this process works analogously for communication with a bank/ATM
+terminal.)
 
 
 Request tunneling
diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst
index 184c6592..ce0e600f 100644
--- a/taler-developer-manual.rst
+++ b/taler-developer-manual.rst
@@ -93,8 +93,7 @@ overview:
     sending invoices or payments to other wallets.
 
   * taler-merchant-demos: various demonstration services operated at
-    'demo.taler.net', including a simple shop, donation page and a
-    survey with reward functionality.
+    'demo.taler.net', including a simple shop and a donation page.
 
 There are other important repositories without code, including:
 
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
index 79455fec..64c2a7d9 100644
--- a/taler-exchange-manual.rst
+++ b/taler-exchange-manual.rst
@@ -967,7 +967,7 @@ Taler permits an exchange to require KYC data under the following circumstances:
   * Wallet receives (via refunds) money resulting in a balance over a threshold
   * Wallet receives money via P2P payments over a threshold
   * Merchant receives money over a threshold
-  * Reserve is "opened" for invoicing or rewards (**planned feature**)
+  * Reserve is "opened" for invoicing (**planned feature**)
 
 Any of the above requests can trigger the KYC process,
 which can be illustrated as follows:
diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst
index 739cf07f..87fee9ca 100644
--- a/taler-merchant-api-tutorial.rst
+++ b/taler-merchant-api-tutorial.rst
@@ -63,10 +63,6 @@ If you want to look at some simple, running examples, check out these:
    that accepts donations for software projects and gives donation
    receipts.
 
--  The
-   `survey <https://git.taler.net/taler-merchant-demos.git/tree/talermerchantdemos/survey>`__
-   that gives users who answer a question a small reward.
-
 -  The `WooCommerce plugin <https://git.taler.net/gnu-taler-payment-for-woocommerce.git/>`__
    which is a comprehensive integration into a Web shop including the refund business
    process.
@@ -413,69 +409,6 @@ considered to identify a resource you can pay for and thus do not have to be
 unique.
 
 
-.. _Giving-Customers-Rewards:
-.. index:: rewards
-
-Giving Customers Rewards
-========================
-
-GNU Taler allows Web sites to grant digital cash directly to a visitor. The
-idea is that some sites may want incentivize actions such as filling out a
-survey or trying a new feature. It is important to note that receiving rewards is
-not enforceable for the visitor, as there is no contract.  It is simply a
-voluntary gesture of appreciation of the site to its visitor. However, once a
-reward has been granted, the visitor obtains full control over the funds provided
-by the site.
-
-The merchant backend of the site must be properly configured for rewards, and
-sufficient funds must be made available for rewards. See the :ref:`Taler User
-Guide <Rewarding-visitors>` for details.
-
-To check if rewards are configured properly and if there are sufficient
-funds available for granting rewards, query the ``/private/reserves`` endpoint:
-
-.. code-block:: python
-
-   >>> import requests
-   >>> requests.get("https://backend.demo.taler.net/private/reserves",
-   ...              headers={"Authorization": "Bearer secret-token:sandbox"})
-   <Response [200]>
-
-Check that a reserve exists where the ``merchant_initial_amount`` is below the
-``committed_amount`` and that the reserve is ``active``.
-
-.. _authorize-reward:
-
-To authorize a reward, ``POST`` to ``/private/rewards``. The following fields
-are recognized in the JSON request object:
-
--  ``amount``: Amount that should be given to the visitor as a reward.
-
--  ``justification``: Description of why the reward was granted. Human-readable
-   text not exposed to the customer, but used by the Back Office.
-
--  ``next_url``: The URL that the user’s browser should be redirected to by
-   the wallet, once the reward has been processed.
-
-The response from the backend contains a ``taler_reward_url``. The
-customer’s browser must be redirected to this URL for the wallet to pick
-up the reward.
-
-.. _pick-up-reward:
-
-This code snipped illustrates giving a reward:
-
-.. code-block:: python
-
-   >>> import requests
-   >>> reward_req = dict(amount="KUDOS:0.5",
-   ...                justification="User filled out survey",
-   ...                next_url="https://merchant.com/thanks.html")
-   >>> requests.post("https://backend.demo.taler.net/private/rewards", json=reward_req,
-   ...              headers={"Authorization": "Bearer secret-token:sandbox"})
-   <Response [200]>
-
-
 .. _Advanced-topics:
 
 Advanced topics
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index 04aadb5d..9ed7ea3e 100644
--- a/taler-merchant-manual.rst
+++ b/taler-merchant-manual.rst
@@ -332,50 +332,6 @@ and the amount that was received. Given this information, the backend can
 detect and report any irregularities that might arise.
 
 
-.. _rewards:
-
-Rewards
--------
-
-.. index:: reward
-.. index:: pick up
-
-Taler does not only allow a Website to be paid, but also to make voluntary,
-non-contractual payments to visitors, called *rewards*.  Such rewards could be
-granted as a reward for filling in surveys or watching advertizements. For
-rewards, there is no contract, rewards are always voluntary actions by the Web
-site that do not arise from a contractual obligation.  Before a Web site
-can create rewards, it must establish a reserve.  Once a reserve has been
-established, the merchant can *grant* rewards, allowing wallets to *pick up*
-the reward.
-
-.. note::
-
-    Rewards are an optional feature, and exchanges may disable rewards (usually
-    if they see compliance issues). In this case, the reward feature will
-    not be available.
-
-.. _merchant-reserves:
-
-
-Reserves
---------
-
-.. index:: reserve
-.. index:: close
-
-A *reserve* is a pool of electronic cash at an exchange under the control of
-a private key.  Merchants withdraw coins from a reserve when granting
-rewards.  A reserve is established by first generating the required key material
-in the merchant backend, and then wiring the desired amount of funds to the
-exchange.
-
-An exchange will automatically *close* a reserve after a fixed period of time
-(typically about a month), wiring any remaining funds back to the merchant.
-While exchange APIs exists to (1) explicitly *open* a reserve to prevent it
-from being automatically closed and to (2) explicitly *close* a reserve at any
-time, the current merchant backend does not make use of these APIs.
-
 Webhooks
 --------
 
diff --git a/taler-wallet.rst b/taler-wallet.rst
index 3ea1dbea..62dca80d 100644
--- a/taler-wallet.rst
+++ b/taler-wallet.rst
@@ -431,7 +431,6 @@ Things we still need tests for:
   Or when the merchant is not reachable?  Or the bank?
   This can be tested by temporarily killing those services.
 * How does the wallet deal with processing the same ``taler://(pay|withdraw)`` URI twice?
-* Test rewards (accepting/refusing a reward)
 * Test refunds
 * Test for :ref:`session-based payments <repurchase>`
 * Test case for auto-refunds