8 files changed, 44 insertions, 44 deletions
diff --git a/design-documents/005-wallet-backup-sync.rst b/design-documents/005-wallet-backup-sync.rst
index 73a09b76..cce04742 100644
--- a/design-documents/005-wallet-backup-sync.rst
+++ b/design-documents/005-wallet-backup-sync.rst
@@ -44,7 +44,7 @@ The managed entities are:
 * set of reserves together with reserve history
 * set of accepted bank withdrawal operations
 * set of coins together with coin history and blinding secret (both for normal withdrawal and refresh)
-  and coin source info (refresh operation, tip, reserve)
+  and coin source info (refresh operation, reward, reserve)
 * set of purchases (contract terms, applied refunds, ...)
 * assignment of coins to their "primary wallet"
 
@@ -59,7 +59,7 @@ Entities that **could** be synchronized (to be decided):
 
 * private keys of other sync accounts
 * coin planchets
-* tips before the corresponding coins have been withdrawn
+* rewards before the corresponding coins have been withdrawn
 * refresh sessions (not only the "meta data" about the operation,
   but everything)
 
diff --git a/design-documents/014-merchant-backoffice-ui.rst b/design-documents/014-merchant-backoffice-ui.rst
index 35ad711f..eaf435a4 100644
--- a/design-documents/014-merchant-backoffice-ui.rst
+++ b/design-documents/014-merchant-backoffice-ui.rst
@@ -141,9 +141,9 @@ Story #4: Manage inventory
 - delete products from inventory
 
 
-Story #5: Manage tipping
+Story #5: Manage rewards
 ------------------------
 
-- set up tipping reserve
+- set up reward reserve
 
-- check tipping reserve status
+- check reward reserve status
diff --git a/design-documents/020-backoffice-tips-management.rst b/design-documents/020-backoffice-rewards-management.rst
index 63365063..a9711ab0 100644
--- a/design-documents/020-backoffice-tips-management.rst
+++ b/design-documents/020-backoffice-rewards-management.rst
@@ -1,10 +1,10 @@
-DD 20: Backoffice Tips Management
-#################################
+DD 20: Backoffice Rewards Management
+####################################
 
 Summary
 =======
 
-This document describe the complete list features for tips and reserve
+This document describe the complete list features for rewards and reserve
 management and how will be shown.
 
 Motivation
@@ -19,9 +19,9 @@ User should use the backoffice to:
 
 * creating new reserves
 * listing active reserves
-* authorize tips for a reserve
-* list all tips for an active reserve
-* check tips status
+* authorize rewards for a reserve
+* list all rewards for an active reserve
+* check rewards status
 
 Proposed Solution
 =================
@@ -47,7 +47,7 @@ columns:
 * initial: if the exchange and merchant-backend disagree in the initial balance
   (failure) the cell will be red and have a tooltip with more information
 
-* actions: delete button will be disabled on failure or committed > 0, new_tip
+* actions: delete button will be disabled on failure or committed > 0, new_reward
   button will be disabled on picked_up == initial or failure
 
 
@@ -67,27 +67,27 @@ fields:
 
 If there is an error in the creation a Notification message will be shown
 
-Authorize Tip
--------------
+Authorize Reward
+----------------
 
-The merchant can authorize tips clicking in the plus (+) button that will bring
+The merchant can authorize rewards clicking in the plus (+) button that will bring
 the next popup
 
-.. image:: ../backoffice-tip-create.svg
+.. image:: ../backoffice-reward-create.svg
   :width: 400
 
 after confirm it will continue with a success page:
 
-.. image:: ../backoffice-tip-create.confirmation.svg
+.. image:: ../backoffice-reward-create.confirmation.svg
   :width: 400
 
 Details of reserve
-----------------------------
+------------------
 
 .. image:: ../backoffice-reserve-details.svg
   :width: 400
 
-Tips sorted from newer to older
+Rewards sorted from newer to older
 
 When the reserve has not yet funded
 
diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst
index 6b67d100..4d8f2cbc 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 tipping.
+* Reserve is "opened" for invoicing or rewards.
 
   * 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 92cdba63..cfe776ed 100644
--- a/design-documents/031-invoicing.rst
+++ b/design-documents/031-invoicing.rst
@@ -5,7 +5,7 @@ Summary
 =======
 
 This document proposes new endpoints to support invoicing,
-that incidentally also address the long-standing tipping
+that incidentally also address the long-standing rewards
 reserve expiration problem.
 
 
@@ -37,7 +37,7 @@ Requirements
 
   * Wallets may want to pay for the reserve with coins
     (reserve fresh, not created via bank transfer), while
-    tipping merchants likely want to pay from the reserve
+    rewarding merchants likely want to pay from the reserve
     balance itself. So both styles of payment should be
     supported.
 
@@ -62,12 +62,12 @@ 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 tipping reserve closure
+delay, and also addresses the unwanted reward reserve closure
 problem. 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 tipping
-reserve after tips are no longer issued.
+receive the funds) and also allowing the user to recover funds from a reward
+reserve after rewards are no longer issued.
 
 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 07d9164d..edfdc094 100644
--- a/design-documents/037-wallet-transactions-lifecycle.rst
+++ b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -526,20 +526,20 @@ the same as if the double-spending transaction had been deleted by the user.
 
 
 
-Transaction Type: Tip
----------------------
+Transaction Type: Reward
+------------------------
 
 * ``pending(user)``
 
-  We have downloaded the metadata for the tip.  This is the initial state for a
-  tip transaction. The user needs to accept/refuse the tip.
+  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.
 
-  * ``[tip-expired] => expired``
+  * ``[reward-expired] => expired``
   * ``[action:accept] => pending(pickup)``
 
 * ``pending(pickup)``
 
-  We are picking up the tip.
+  We are picking up the reward.
 
   * ``[failure] => failed``: any type of failure, including expiration.
   * ``[processed-kyc-required] => pending(kyc-required)``
@@ -548,9 +548,9 @@ Transaction Type: Tip
 
 * ``suspended(pickup)``
 
-  The user suspended the operation while the tip was being picked up.
+  The user suspended the operation while the reward was being picked up.
 
-  * ``[tip-expired] => failed``
+  * ``[reward-expired] => failed``
   * ``[action:resume] => pending(pickup)``
 
 * ``pending(kyc)``
@@ -564,23 +564,23 @@ Transaction Type: Tip
 * ``suspended(kyc)``
 
   The user suspended the KYC operation.  Note that we do not time out here if
-  the tip expires, as the wallet balance threshold KYC likely applies even
-  without the tip.
+  the reward expires, as the wallet balance threshold KYC likely applies even
+  without the reward.
 
   * ``[action:resume] => pending(kyc)``
 
 * ``done``
 
-  The tip operation completed.
+  The reward operation completed.
 
   * ``[action:delete] => deleted``
 
 * ``deleted``
 
-  All memory of the tip operation is lost, but of course the resulting fresh
+  All memory of the reward operation is lost, but of course the resulting fresh
   coins are preserved.
 
-.. image:: ../transaction-tip-states.png
+.. image:: ../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 4d90eaad..1c89d634 100644
--- a/design-documents/041-wallet-balance-amount-definitions.rst
+++ b/design-documents/041-wallet-balance-amount-definitions.rst
@@ -245,18 +245,18 @@ 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?
 
-TIP
-  raw amount is the amount that the merchant send as tip
+REWARD
+  raw amount is the amount that the merchant send as reward
 
-  ``instructed_amount`` = tip.amount
+  ``instructed_amount`` = reward.amount
 
   ``raw_amount`` = instructed_amount + withdrawal_fee
 
   ``effective_amount`` = instructed_amount
 
   .. note::
-    We should not show fee for tips in the wallet since the merchant is the one choosing
-    the exchange and we can assume that those tips are paid by the merchant.
+    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/index.rst b/design-documents/index.rst
index 43e52559..1d8a55d0 100644
--- a/design-documents/index.rst
+++ b/design-documents/index.rst
@@ -29,7 +29,7 @@ and protocol.
   017-backoffice-inventory-management
   018-contract-json
   019-wallet-backup-merge
-  020-backoffice-tips-management
+  020-backoffice-rewards-management
   021-exchange-key-continuity
   022-wallet-auditor-reports
   023-taler-kyc