[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated: fix #7923
|
From: |
gnunet |
|
Subject: |
[taler-docs] branch master updated: fix #7923 |
|
Date: |
Sun, 03 Sep 2023 15:14:22 +0200 |
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 898e0199 fix #7923
898e0199 is described below
commit 898e01993f2401bd1737d791229ecbc35433428d
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Sep 3 15:14:18 2023 +0200
fix #7923
---
Makefile | 6 +-
conf.py | 2 +-
core/api-exchange.rst | 8 +-
core/api-merchant.rst | 196 ++++++++++-----------
design-documents/005-wallet-backup-sync.rst | 4 +-
design-documents/014-merchant-backoffice-ui.rst | 6 +-
...t.rst => 020-backoffice-rewards-management.rst} | 28 +--
design-documents/023-taler-kyc.rst | 2 +-
design-documents/031-invoicing.rst | 10 +-
.../037-wallet-transactions-lifecycle.rst | 26 +--
.../041-wallet-balance-amount-definitions.rst | 10 +-
design-documents/index.rst | 2 +-
manpages/taler-merchant-httpd.1.rst | 2 +-
manpages/taler-merchant-setup-reserve.1.rst | 2 +-
manpages/taler-wallet-cli.1.rst | 2 +-
...tip-states.dot => transaction-reward-states.dot | 0
16 files changed, 152 insertions(+), 154 deletions(-)
diff --git a/Makefile b/Makefile
index 06d04640..e7abb24b 100644
--- a/Makefile
+++ b/Makefile
@@ -63,8 +63,8 @@ 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-tip-states.png: transaction-tip-states.dot
- dot -Tpng transaction-tip-states.dot > transaction-tip-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
@@ -82,7 +82,7 @@ deposit.png: deposit.dot
reserve.png: reserve.dot
dot -Tpng reserve.dot > reserve.png
-diagrams: 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-tip-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
+diagrams: 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
# The html-linked builder does not support caching, so we
diff --git a/conf.py b/conf.py
index efdf5476..e0b49c8c 100644
--- a/conf.py
+++ b/conf.py
@@ -596,7 +596,7 @@ man_pages = [
(
"manpages/taler-merchant-setup-reserve.1",
"taler-merchant-setup-reserve",
- "setup reserve for tipping at a Taler merchant backend",
+ "setup reserve for rewards at a Taler merchant backend",
"GNU Taler contributors",
1,
),
diff --git a/core/api-exchange.rst b/core/api-exchange.rst
index 35fdcc49..6191cac4 100644
--- a/core/api-exchange.rst
+++ b/core/api-exchange.rst
@@ -159,8 +159,8 @@ possibly by using HTTPS.
wads: ExchangePartner[];
// Set to true if this exchange allows the use
- // of reserves for tipping.
- tipping_allowed: boolean;
+ // of reserves for rewards.
+ rewards_allowed: boolean;
// EdDSA master public key of the exchange, used to sign entries
// in ``denoms`` and ``signkeys``.
@@ -5301,7 +5301,7 @@ 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
-tipping), to (2) pay an annual fee to allow a number of purses to be created
+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
@@ -5313,7 +5313,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 tipping or invoicing.
+ Request keeping a reserve open for rewards or invoicing.
**Request:**
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
index 56c6e3c5..ea059ac7 100644
--- a/core/api-merchant.rst
+++ b/core/api-merchant.rst
@@ -2578,36 +2578,34 @@ once we got a reply from the exchange.
The transfer cannot be deleted anymore.
---------------------
-Backend: Giving tips
---------------------
+-----------------------
+Backend: Giving rewards
+-----------------------
-Tips are a way for websites to give small amounts of e-cash to visitors (for
+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 watching
-advertizements). Tips are non-contractual: neither merchant nor consumer
+advertizements). Rewards are non-contractual: neither merchant nor consumer
have any contractual information about the other party as a result of the
-tip.
+reward.
Create reserve
--------------
-Reserves are basically funds a merchant has provided
-to an exchange for a tipping campaign. Each reserve
-has a limited lifetime (say 2--4 weeks). Any funds
-not used to tip customers will automatically be wired
-back from the exchange to the originating account.
+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.
-To begin tipping, 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 tipping campaign
-funds to the exchange.
+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.
-.. _tips:
+.. _rewards:
.. http:post:: [/instances/$INSTANCE]/private/reserves
- Create a reserve for tipping.
+ Create a reserve for rewards.
This request is **not** idempotent. However, while repeating
it will create another reserve, that is generally pretty harmless
@@ -2627,7 +2625,7 @@ funds to the exchange.
: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
tipping.
+ 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`:
@@ -2640,7 +2638,7 @@ funds to the exchange.
// Amount that the merchant promises to put into the reserve.
initial_balance: Amount;
- // Exchange the merchant intends to use for tipping.
+ // Exchange the merchant intends to use for rewards.
exchange_url: string;
// Desired wire method, for example "iban" or "x-taler-bank".
@@ -2659,7 +2657,7 @@ funds to the exchange.
.. http:get:: [/instances/$INSTANCE]/private/reserves
- Obtain list of reserves that have been created for tipping.
+ Obtain list of reserves that have been created for rewards.
**Request:**
@@ -2670,12 +2668,12 @@ funds to the exchange.
**Response:**
:http:statuscode:`200 OK`:
- Returns a list of known tipping reserves.
- The body is a `TippingReserveStatus`.
+ Returns a list of known reward reserves.
+ The body is a `RewardReserveStatus`.
- .. ts:def:: TippingReserveStatus
+ .. ts:def:: RewardReserveStatus
- interface TippingReserveStatus {
+ interface RewardReserveStatus {
// Array of all known reserves (possibly empty!).
reserves: ReserveStatusEntry[];
}
@@ -2702,7 +2700,7 @@ funds to the exchange.
// Amount picked up so far.
pickup_amount: Amount;
- // Amount approved for tips that exceeds the pickup_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)?
@@ -2715,18 +2713,18 @@ Query funds remaining
.. http:get:: [/instances/$INSTANCE]/private/reserves/$RESERVE_PUB
- Obtain information about a specific reserve that have been created for
tipping.
+ Obtain information about a specific reserve that have been created for
rewards.
**Request:**
- :query tips: *Optional*. If set to "yes", returns also information about all
of the tips created.
+ :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 tipping reserve is not known.
+ 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
@@ -2758,12 +2756,12 @@ Query funds remaining
// Amount picked up so far.
pickup_amount: Amount;
- // Amount approved for tips that exceeds the pickup_amount.
+ // Amount approved for rewards that exceeds the pickup_amount.
committed_amount: Amount;
- // Array of all tips created by this reserves (possibly empty!).
+ // Array of all rewards created by this reserves (possibly empty!).
// Only present if asked for explicitly.
- tips?: TipStatusEntry[];
+ rewards?: RewardStatusEntry[];
// Is this reserve active (false if it was deleted but not purged)?
active: boolean;
@@ -2778,92 +2776,92 @@ Query funds remaining
exchange_url: string;
}
- .. ts:def:: TipStatusEntry
+ .. ts:def:: RewardStatusEntry
- interface TipStatusEntry {
+ interface RewardStatusEntry {
- // Unique identifier for the tip.
- tip_id: HashCode;
+ // Unique identifier for the reward.
+ reward_id: HashCode;
- // Total amount of the tip that can be withdrawn.
+ // Total amount of the reward that can be withdrawn.
total_amount: Amount;
- // Human-readable reason for why the tip was granted.
+ // Human-readable reason for why the reward was granted.
reason: string;
}
-Authorizing tips
-----------------
+Authorizing rewards
+-------------------
-.. http:post::
[/instances/$INSTANCE]/private/reserves/$RESERVE_PUB/authorize-tip
+.. http:post::
[/instances/$INSTANCE]/private/reserves/$RESERVE_PUB/authorize-reward
- Authorize creation of a tip from the given reserve.
+ Authorize creation of a reward from the given reserve.
**Request:**
- The request body is a `TipCreateRequest` object.
+ The request body is a `RewardCreateRequest` object.
**Response:**
:http:statuscode:`200 OK`:
- A tip has been created. The backend responds with a
`TipCreateConfirmation`.
+ 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 tip amount requested exceeds the available reserve balance for tipping.
+ The reward amount requested exceeds the available reserve balance for
rewards.
- .. ts:def:: TipCreateRequest
+ .. ts:def:: RewardCreateRequest
- interface TipCreateRequest {
- // Amount that the customer should be tipped.
+ interface RewardCreateRequest {
+ // Amount that the customer should be rewarded.
amount: Amount;
- // Justification for giving the tip.
+ // Justification for giving the reward.
justification: string;
- // URL that the user should be directed to after tipping,
- // will be included in the tip_token.
+ // URL that the user should be directed to after receiving the reward,
+ // will be included in the reward_token.
next_url: string;
}
- .. ts:def:: TipCreateConfirmation
+ .. ts:def:: RewardCreateConfirmation
- interface TipCreateConfirmation {
- // Unique tip identifier for the tip that was created.
- tip_id: HashCode;
+ interface RewardCreateConfirmation {
+ // Unique reward identifier for the reward that was created.
+ reward_id: HashCode;
- // taler://tip URI for the tip.
- taler_tip_uri: string;
+ // taler://reward URI for the reward.
+ taler_reward_uri: string;
// URL that will directly trigger processing
- // the tip when the browser is redirected to it.
- tip_status_url: string;
+ // the reward when the browser is redirected to it.
+ reward_status_url: string;
- // When does the tip expire?
- tip_expiration: Timestamp;
+ // When does the reward expire?
+ reward_expiration: Timestamp;
}
-.. http:post:: [/instances/$INSTANCE]/private/tips
+.. http:post:: [/instances/$INSTANCE]/private/rewards
- Authorize creation of a tip, with
+ Authorize creation of a reward, with
automatic selection of a working reserve of the instance by the
- backend. Intentionally otherwise identical to the ``/authorize-tip``
+ backend. Intentionally otherwise identical to the ``/authorize-reward``
endpoint given above.
**Request:**
- The request body is a `TipCreateRequest` object.
+ The request body is a `RewardCreateRequest` object.
**Response:**
:http:statuscode:`200 OK`:
- A tip has been created. The backend responds with a
`TipCreateConfirmation`.
+ 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 tip amount requested exceeds the available reserve balance for tipping
+ The reward amount requested exceeds the available reserve balance for
rewards
in all of the reserves of the instance.
@@ -2873,13 +2871,13 @@ Deleting reserves
.. http:delete:: [/instances/$INSTANCE]/private/reserves/$RESERVE_PUB
Delete information about a reserve. Fails if the reserve still has
- committed to tips that were not yet picked up and that have not yet
+ 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 tips it issued will be fully deleted.
+ about rewards it issued will be fully deleted.
Otherwise only the private key would be deleted.
**Response:**
@@ -2889,48 +2887,48 @@ Deleting reserves
: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 tips awaiting pickup).
+ The backend refuses to delete the reserve (committed rewards awaiting
pickup).
-Checking tip status
--------------------
+Checking reward status
+----------------------
-.. http:get:: [/instances/$INSTANCE]/private/tips/$TIP_ID
+.. http:get:: [/instances/$INSTANCE]/private/rewards/$REWARD_ID
- Obtain information about a particular tip.
+ 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 tips of at least min_pick_up to
be
+ 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 tip is known. The backend responds with a `TipDetails` message.
+ The reward is known. The backend responds with a `RewardDetails` message.
:http:statuscode:`404 Not found`:
- The tip is unknown to the backend.
+ The reward is unknown to the backend.
- .. ts:def:: TipDetails
+ .. ts:def:: RewardDetails
- interface TipDetails {
- // Amount that we authorized for this tip.
+ 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 tip.
+ // Human-readable reason given when authorizing the reward.
reason: string;
- // Timestamp indicating when the tip is set to expire (may be in the
past).
+ // Timestamp indicating when the reward is set to expire (may be in the
past).
expiration: Timestamp;
- // Reserve public key from which the tip is funded.
+ // Reserve public key from which the reward is funded.
reserve_pub: EddsaPublicKey;
// Array showing the pickup operations of the wallet (possibly empty!).
@@ -2952,13 +2950,13 @@ Checking tip status
}
-.. http:get:: [/instances/$INSTANCE]/private/tips
+.. http:get:: [/instances/$INSTANCE]/private/rewards
- Return the list of all tips.
+ Return the list of all rewards.
**Request:**
- :query include_expired: *Optional*. If set to "yes", the result includes
expired tips also. Otherwise, only active tips are returned.
+ :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.
@@ -2967,29 +2965,29 @@ Checking tip status
**Response:**
:http:statuscode:`200 OK`:
- The backend has successfully found the list of tips. The backend responds
- with a `TipsResponse`.
+ The backend has successfully found the list of rewards. The backend
responds
+ with a `RewardsResponse`.
- .. ts:def:: TipsResponse
+ .. ts:def:: RewardsResponse
- interface TipsResponse {
+ interface RewardsResponse {
- // List of tips that are present in the backend.
- tips: Tip[];
+ // List of rewards that are present in the backend.
+ rewards: Reward[];
}
- .. ts:def:: Tip
+ .. ts:def:: Reward
- interface Tip {
+ interface Reward {
- // ID of the tip in the backend database.
+ // ID of the reward in the backend database.
row_id: number;
- // Unique identifier for the tip.
- tip_id: HashCode;
+ // Unique identifier for the reward.
+ reward_id: HashCode;
- // (Remaining) amount of the tip (including fees).
- tip_amount: Amount;
+ // (Remaining) amount of the reward (including fees).
+ reward_amount: Amount;
}
-----------
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
similarity index 75%
rename from design-documents/020-backoffice-tips-management.rst
rename to 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
diff --git a/manpages/taler-merchant-httpd.1.rst
b/manpages/taler-merchant-httpd.1.rst
index cf9192f9..3df4f4ac 100644
--- a/manpages/taler-merchant-httpd.1.rst
+++ b/manpages/taler-merchant-httpd.1.rst
@@ -93,7 +93,7 @@ TALER_MERCHANT_TOKEN
See Also
========
-taler-merchant-dbinit(1), taler-merchant-tip-enable(1), taler.conf(5)
+taler-merchant-dbinit(1), taler-merchant-setup-reserve(1), taler.conf(5)
Bugs
diff --git a/manpages/taler-merchant-setup-reserve.1.rst
b/manpages/taler-merchant-setup-reserve.1.rst
index 25d5b102..73fa2a0c 100644
--- a/manpages/taler-merchant-setup-reserve.1.rst
+++ b/manpages/taler-merchant-setup-reserve.1.rst
@@ -7,7 +7,7 @@ taler-merchant-setup-reserve(1)
Name
====
- **taler-merchant-setup-reserve** - setup reserve for tipping
+ **taler-merchant-setup-reserve** - setup reserve for rewards
Synopsis
diff --git a/manpages/taler-wallet-cli.1.rst b/manpages/taler-wallet-cli.1.rst
index bac9ea9f..2d35bb87 100644
--- a/manpages/taler-wallet-cli.1.rst
+++ b/manpages/taler-wallet-cli.1.rst
@@ -46,7 +46,7 @@ for testing.
**withdraw-uri** URI
-**tip-uri** URI
+**reward-uri** URI
**refund-uri** URI
diff --git a/transaction-tip-states.dot b/transaction-reward-states.dot
similarity index 100%
rename from transaction-tip-states.dot
rename to transaction-reward-states.dot
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-docs] branch master updated: fix #7923,
gnunet <=