taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit 4e29dbba2a41cbb266891c3abacb77eebddd7c08
parent a875828acb66b96fdaa80f24a88ccc69abb29654
Author: Christian Grothoff <christian@grothoff.org>
Date:   Sat, 31 Oct 2020 16:33:58 +0100

expand rationale on claiming and claim tokens (fixes #6583)

Diffstat:
Mtaler-merchant-manual.rst | 22++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)

diff --git 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