commit c150307a7a7cf018a277e8aad4b8a36db727f170
parent 332a567163a921035d1d469baee497ce3e494bb2
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Wed, 22 May 2024 15:24:28 +0200
poster: enhance text
Diffstat:
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/poster/cashless2ecash_poster.pdf b/poster/cashless2ecash_poster.pdf
Binary files differ.
diff --git a/poster/cashless2ecash_poster.tex b/poster/cashless2ecash_poster.tex
@@ -36,11 +36,11 @@
The C2EC components implements the structures required to fulfill the following properties:
\begin{enumerate}
- \item Liability for the money lies on the provider
- \item Convenience of the withdrawal for the customer
+ \item Finality: Liability for the money lies on the provider
+ \item Convenience: The UX for the customer is convenient
\end{enumerate}
- The liability on the provider is achieved by only allowing withdrawals of strictly finale transactions. Due to the convenient process, a broader group of people is motivated to use the Taler payment system for their payments. Eventually this helps the payment system Taler to be taken up faster by the society.
+ The liability on the provider is achieved by only allowing withdrawals of strictly finale transactions. This keeps the Exchange out of legal issues. Due to the convenient process, a broader group of people is motivated to use the Taler payment system for their payments. Eventually this helps the payment system Taler to be taken up faster by the society.
\end{posterboxenv}
@@ -74,7 +74,7 @@
\end{posterboxenv}
\begin{posterboxenv}[title=PayDroid POS Terminal App (Wallee A50)]{name=wallee, column=2, row=4, span=3, span=3}
- To show that the specification is able to capture the needs for third party withdrawals and allow the integration for theoretically any means of payment, an integration was done for the payment provider Wallee. The Android app was implemented on the Wallee platform. The newly created withdrawal application sets up the withdrawal and awaits the registration at the Terminals API by the Taler wallet. Once the wallet registered itself, the terminal authorizes the payment by letting the customer present their credit card. This triggers the confirmation of the payment at the provider backend through the C2EC backend. Upon the confirmation, the Exchange allows the withdrawal of the digtial cash.
+ To show that the specification is able to capture the needs for third party withdrawals and allow the integration for theoretically any means of payment, an integration was done for the payment provider Wallee. The Android app was implemented on the Wallee platform. The newly created withdrawal application sets up the withdrawal and awaits the registration at the Terminals API by the Taler wallet. Once the wallet registered itself, the terminal authorizes the payment by letting the customer present their credit card. This triggers the confirmation of the payment at the provider backend through the C2EC backend. Upon the confirmation, the Exchange allows the withdrawal of the digtial cash through the Taler Wallet.
\end{posterboxenv}
\begin{posterboxenv}[title=Enter Amount]{name=flow-diagram,column=1,row=5,span=1, rowspan=1}
@@ -104,7 +104,14 @@
\end{posterboxenv}
\begin{posterboxenv}[title=Integrate your platform!]{name=Integrate your platform, column=1,row=7,span=4,rowspan=1}
- C2EC is extensible. The C2EC backend component defines two interfaces which can be implemented by any provider. This also includes cash to e-cash cases like vending machines or any POS installation. One interface defines the operations for the communication with the provider backend, while the second interface defines the operations to interact with the provider specific transaction format. The operations must implement the correct confirmation process for the specific provider. This means that the implementation must guarantee the finality of the transaction and like this provides the Exchange with the securities it needs to allow the withdrawal of the digital cash. The operations also allow to trigger a refund when the Exchange closes reserves due to inactivities or in case the customer wants back their money.
+ C2EC is extensible. The C2EC backend component defines two interfaces which can be implemented by any provider. This also includes cash to e-cash cases like vending machines or any POS installation.
+
+ \begin{enumerate}
+ \item ProviderClient: defines the operations needed to communicate with the provider's backend
+ \item ProviderTransaction: defines the operations to check the finality of the transaction
+ \end{enumerate}
+
+ The implementation must guarantee the finality of the transaction and like this provides the Exchange with the securities it needs to allow the withdrawal of the digital cash. The operations also define a refund operation. The refund operation is used, when the Exchange closes reserves due to inactivities or in case the Exchange manually triggers a refund (perhaps because the customer asked to do so).
\end{posterboxenv}
\end{tcbposter}
