[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-docs] branch master updated: expand rationale on claiming and cla

From: gnunet
Subject: [taler-docs] branch master updated: expand rationale on claiming and claim tokens (fixes #6583)
Date: 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

commit 4e29dbba2a41cbb266891c3abacb77eebddd7c08
Author: Christian Grothoff <>
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
--- a/taler-merchant-manual.rst
+++ b/taler-merchant-manual.rst
@@ -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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]