diff options
Diffstat (limited to 'doc/system/taler/implementation.tex')
| -rw-r--r-- | doc/system/taler/implementation.tex | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/system/taler/implementation.tex b/doc/system/taler/implementation.tex index 4b095b779..b49763c65 100644 --- a/doc/system/taler/implementation.tex +++ b/doc/system/taler/implementation.tex @@ -577,7 +577,7 @@ We now define a fallback, which is transparently implemented in the reference me In addition to indicating that a payment is required for a resource in the HTTP status code and header, the merchant includes a fallback URL in the body of the ``402 Payment Required'' response. This URL must have the custom URL scheme \texttt{taler}, and contains the contract terms URL (and other Taler-specific settings normally specified in headers) -as parameters. The above payment would include a link (labled, e.g., ``Pay with GNU Taler'') to the following URL, encoding +as parameters. The above payment would include a link (labeled, e.g., ``Pay with GNU Taler'') to the following URL, encoding the same information as the headers: \begin{lstlisting}[style=myhttp] taler:pay?*\break\contl*contract_url=*\break\contl*https%3A%2F%2Falice-shop.example.com%2Fcontract%3Fproduct%3Dessay-24.pdf*\break\contl*&resource_url=*\break\contl*https%3A%2F%2Falice-shop.example.com%2Fessay-24.pdf @@ -908,7 +908,7 @@ The following APIs are offered by the exchange: the merchant additionally can use the exchange's \texttt{/transfers/\$WTID} API that returns the list of deposits for a wire transfer identifier (WTID) included in the wire transfer to the merchant, as well as the \texttt{/deposits/\$H\_WIRE/\$MERCHANT\_PUB/\$H\_CONTRACT\_TERMS/\$COIN\_PUB} API to look up which wire transfer included the payment for a given deposit. - \item[Refresh] Refreshing consists of two stages. First, using \texttt{/coins/\$COIN\_PUB/melt} an old, possibly dirty coin is melted and thus devaluted. The committment made by the wallet during the melt and the resulting $\gamma$-challenge from the exchange are associated with a {\em refresh session}. Then, using \texttt{/refreshes/\$RCH/reveal} the wallet can answer the challenge and obtain fresh coins as change. Finally, \texttt{/coins/\$COIN\_PUB/link} provides the link deterrent against refresh abuse. + \item[Refresh] Refreshing consists of two stages. First, using \texttt{/coins/\$COIN\_PUB/melt} an old, possibly dirty coin is melted and thus devaluted. The commitment made by the wallet during the melt and the resulting $\gamma$-challenge from the exchange are associated with a {\em refresh session}. Then, using \texttt{/refreshes/\$RCH/reveal} the wallet can answer the challenge and obtain fresh coins as change. Finally, \texttt{/coins/\$COIN\_PUB/link} provides the link deterrent against refresh abuse. \item[Refunds] The refund API (\texttt{/coins/\$COIN\_PUB/refund}) can ``undo'' a deposit if the merchant gave their signature, and the aggregation deadline for the payment has not occurred yet. \item[Recoup] The recoup API (\texttt{/coins/\$COIN\_PUB/recoup}) allows customers to be compensated |