[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated: expand rationale on claiming and cla
[taler-docs] branch master updated: expand rationale on claiming and claim tokens (fixes #6583)
Sat, 31 Oct 2020 16:34:01 +0100
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 4e29dbb expand rationale on claiming and claim tokens (fixes #6583)
4e29dbb is described below
Author: Christian Grothoff <firstname.lastname@example.org>
AuthorDate: Sat Oct 31 16:33:58 2020 +0100
expand rationale on claiming and claim tokens (fixes #6583)
taler-merchant-manual.rst | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index d93c12d..3b0aba0 100644
@@ -180,6 +180,17 @@ merchant, where the merchant specifies the specific terms
of the order.
After an order is created, it is *claimed* by a wallet. Once an order is
claimed by a specific wallet, only that wallet will be able to pay for this
order, to the exclusion of other wallets even if they see the same order URL.
+Sharing order URLs is explicitly allowed: if a user shares and order URL
+with another user, that other user should be given the opportunity to
+purchase the same product.
+To prevent unauthorized wallets from claiming an order, merchants can specify
+that claims require authorization in the form of a *claim token*. This is
+useful in case the order ID is predictable (say because an existing order ID
+scheme from the merchant frontend is used) and at the same time malicious
+actors claiming orders is problematic (say because of limited stocks). The use
+of claim tokens is optional, but if a claim token is used, it must be provided
+to the wallet as part of the order URI.
A wallet may *pay* for a claimed order, at which point the order turns into
a (paid) contract. Orders have an expiration date after which the commercial
@@ -189,12 +200,11 @@ allowing the stock to be sold in other orders.
Once a contract has been paid, the merchant should fulfill the contract. It
is possible for the merchant to *refund* a contract order, for example if the
contract cannot be fulfilled after all. Refunds are only possible after the
-customer paid and before the
-exchange has *wired* the payment to the merchant. Once the funds have been
-wired, refunds are no longer allowed by the Taler exchange. The *wire
-deadline* specifies the latest time by which an exchange must wire the funds,
-while the (earlier) *refund deadline* specifies the earliest time when an
-exchange may wire the funds.
+customer paid and before the exchange has *wired* the payment to the
+merchant. Once the funds have been wired, refunds are no longer allowed by the
+Taler exchange. The *wire deadline* specifies the latest time by which an
+exchange must wire the funds, while the (earlier) *refund deadline* specifies
+the earliest time when an exchange may wire the funds.
Contract information is kept for legal reasons, typically to provide tax
records in case of a tax audit. After the *legal expiration* (by default a
To stop receiving notification emails like this one, please contact
|[Prev in Thread]
||[Next in Thread]|
- [taler-docs] branch master updated: expand rationale on claiming and claim tokens (fixes #6583),