remove reward-related APIs and design considerations

7 files changed, 25 insertions, 131 deletions

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
 =====
-