commit 3641e5dcccd75e119831c7604eef49afbed98a96
parent ed3854bbcd07d9279fd257385b729c19c1dcec4b
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Wed, 5 Jun 2024 16:03:03 +0200
docs: enhance
Diffstat:
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/docs/content/implementation/a-c2ec.tex b/docs/content/implementation/a-c2ec.tex
@@ -27,25 +27,25 @@ To decouple different steps in the withdrawal process an event based architectur
Following a short list of events and from whom they are triggered and who listens to them:
\begin{itemize}
- \item Pending -> Selected
+ \item From pending to selected
\begin{itemize}
\item Description: Registration of the withdrawal operation parameters.
\item Registered by: Wallet
\item Listened by: Terminal
\end{itemize}
- \item Selected -> Confirming
+ \item From selected to confirming
\begin{itemize}
\item Description: Payment confirmation request sent to the Bank-Integration API of C2EC.
\item Registered by: Terminal
\item Listened by: Confirmation
\end{itemize}
- \item Selected -> Confirmed
+ \item From selected to confirmed
\begin{itemize}
\item Description: Payment confirmation success will send a withdrawal operation status update event.
\item Registered by: Confirmation
\item Listened by: Consumers (via Bank-Integration-API)
\end{itemize}
- \item Selected -> Aborted
+ \item From selected to aborted
\begin{itemize}
\item Description: Payment confirmation failure will trigger a retry event.
\item Registered by: Confirmation
@@ -54,7 +54,7 @@ Following a short list of events and from whom they are triggered and who listen
\item Refund
\begin{itemize}
\item Description: Transfers which represent refunds in C2EC.
- \item Registered by: Exchange (through the wire gateway API)
+ \item Registered by: Exchange (through the Wire Gateway API)
\item Listened by: Transfer
\end{itemize}
\end{itemize}
@@ -63,7 +63,7 @@ Following a short list of events and from whom they are triggered and who listen
A withdrawal might be aborted through the terminal or the wallet. These cases are implemented through the respective \textit{abort} endpoint in the bank-integration API \autoref{sec-implementation-bank-integration-api-abort} and terminals API \autoref{sec-implementation-terminal-api-abort}. If in doubt whether to abort the withdrawal or not, it should be aborted. In case of abortion and failure cases, the security of the money is weighted higher than the user-experience. If the user must restart the withdrawal in case of a failure in the process, it is less severe than opening possible security holes by somehow processing the withdrawal anyway. On the other hand the system must be as stable as possible to make this error cases very rare. If they occur too often, the customer might not use the technology and therefore would make it worthless.
-The withdrawal can only be aborted, when it is not yet confirmed by the confirmation process (described in \autoref{sec-implementation-processes-confirmation}). When the customer wants his money back they can wait for the reserve to be closed by the Exchange or get in touch with the operator who might trigger a manual refund.
+The withdrawal can only be aborted, when it is not yet confirmed by the confirmation process (described in \autoref{sec-implementation-processes-confirmation}). When the customer wants his money back they can wait for the reserve to be closed by the Exchange or get in touch with the operator who might trigger a manual refund. The manual refund will revert the payment and give the money back to the customer.
\newpage
\include{content/implementation/a-terminal-api}
diff --git a/docs/content/implementation/a-wire-gateway-api.tex b/docs/content/implementation/a-wire-gateway-api.tex
@@ -29,7 +29,7 @@ The C2EC component needs to return incoming transactions by providers through th
\textbf{Transfers (/transfer)}
-The specification \cite{taler-wire-gateway-api} requires the implementor of the API to keep track of incoming transfer requests. In order to guarantee the idempotence of the API, the implementation keeps track of all transfers in the database table \textit{transfers}. It stores the transfer data in the database. If a request with the same UID is sent to the transfer-API, first it is checked that the incoming request is exactly the same as the previous one by comparing the request to the values stored in the database. Only if the values are the same, the transfer request is processed further. Otherwise the API responds with a conflict response.
+The specification \cite{taler-wire-gateway-api} requires the implementor of the API to keep track of incoming transfer requests. In order to guarantee the idempotence of the API, the implementation keeps track of all transfers in the database table \textit{transfers}. It stores the transfer data in the database. If a request with the same UID is sent to the transfer-API, first it is checked that the incoming request is exactly the same as the previous one by comparing the request to the values stored in the database. Only if the values are the same, the transfer request is processed further. Otherwise the API responds with a conflict response. The refund will always make a full refund. Partial refunds are not supported in the current implementation.
\textbf{Outgoing transactions (/history/outgoing)}
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
