discussion.tex (7422B)
1 \section{Discussion} 2 3 This thesis shows that withdrawals in GNU Taler are possible using the payment service provider Wallee. The implementation displays how the objectives of finality, user-experience and security can be achieved. The C2EC implementation also achieves the integration into the rest of the Taler ecosystem and gives a reference on how this can be achieved. 4 5 The design of the Terminals API was a major field of work during the process. Only after several iterations, the specification was ready. The iterations were necessary to sharpen the understanding of how the terminal and C2EC must interact and integrate with the existing Taler components in order to make the withdrawals functional. At first the existing Bank-Integration API was copied and extended before merging the copy with the existing Bank-Integration API. After this step I extracted terminal specific endpoints to the new Terminals API. Like this the separation of terminal and wallet specific functionality could have been achieved. The current implementation keeps changes to the existing Bank-Integration API low and therefore allow the integration of the wallet without further changes. 6 7 The implementation of the existing Bank-Integration and Wire-Gateway API were a challenge because they must be implemented with great care to not violate the specification. Another challenging task was the design of C2EC. Making C2EC a useful, robust and extensible, required the understaning of details of Taler such as byte encodings or amount handling. This task was a little more time consuming than initially planned. At first, I assumed that C2EC would just be implemented and work. This was a bit optimistic. In reality the process was iterative. Only after a lot of iterations a suitable way for the implementation was found. 8 9 A challenge which was encountered during the implementation of the terminal application and the C2EC component, was the concurrency of processes. To make the withdrawal flow as easy and useful as possible, a lot of tasks need to be covered in the background and run besides each other. This added the technical requirement to decouple steps and leverage retries to increase the robustness of the process. It helped a lot to understand that the state of a withdrawal was the anchor these retry mechanisms must be built around. 10 11 Fees are a central aspect of the process and decide wether the implementation can be used or not. The different fee models of \autoref{sec-implementation-fees} describe how fees can add up during a withdrawal. The current implementation does not cover all fee models, because fee models two to four also depend on the payment system provider used for a specific withdrawal. The checks that C2EC can make to secure its own fees are implemented. Fee model one seems to be the most secure and easy to implement fee model. It can be covered by the core implementation of C2EC and does not rely on the payment system provider specific implementation. Using other fee models requires great care during the integration and adds complexity. For the thesis, model one was implemented because Wallee uses this model. These models also resolve the discussion of the midterm meeting with Dr. Alain Hiltgen. 12 13 Towards the end of the implementation it became obvious that a simple authorization of the payment was not enough to imitate the real time feeling of the withdrawal. Other requests were necessary to do so. To findout which requests needed to be filed against the Wallee backend some investigation had to be made. The documentation does explain which states exists in Wallee's transaction scheme but does not explain, which operation must be triggered to transition states. This made the investigation somewhat cumbersome. Also the integration of the backend needed more investigation than assumed. This also led to the 14 15 The new cashless approach to withdraw digital cash makes a faster uptake of GNU Taler possible. Potential customers will only need a supported payment mean to withdraw digital cash. They can now use C2EC and the terminal app for Wallee to withdraw digital cash using GNU Taler. 16 17 \section{Limitations And Future Work} 18 19 Due to the short time available during the thesis, features and integrations are missing which can make C2EC even more valuable. Because of this I provide a list of future work. Maybe there are other students or collaborators who want to join in and add their features to the existing code. The list might not be complete and any new ideas are appreciated. I splitted the list into the list of extensions and improvements. The improvements list also shows some limitations of the implementation done during the thesis. 20 21 \subsection{Extensions} 22 \begin{enumerate} 23 \item Integration of other providers: To make use of the implemented structures, it would be nice to add more payment service providers. 24 \item Management interface for terminals: To allow easier use of the system it might be nice to have a more sophisticated interface to manage terminals. The implemented cli helps to get an understanding, how such a management interface can add terminals to the system. 25 \item Automated registration: With increasing use of C2EC, it might be nice for the operator to allow an automatic registration of new terminals. 26 \item Support quotas: To fully support the Terminals API, the quotas endpoints can be implemented. 27 \item Proper packing: To fully integrate into the Taler landscape, C2EC should be packed and installed like other Taler components such as the Exchange. 28 \end{enumerate} 29 30 \subsection{Improvements} 31 \label{sec-results-improvements} 32 \begin{enumerate} 33 \item Paydroid app: Run a Wallee terminal on behalf of the BFH. 34 \item Paydroid app: The app must be released including the credentials. This is a security risk since these credentials are shipped through (secure?) channels. A way to register to an exchange in the app is a nice extension. 35 \item C2EC: Remove doubled provider structures. Currently providers are saved to the database and must be configured in the configuration. To make the setup and management easier, the providers can only be configured inside the configuration. 36 \item C2EC: Proper separation of confirmed and unconfirmed withdrawals and transferred and untransferred refunds to reduce complexity of the implementation. 37 \item C2EC: Only one provider per instance is allowed to use the same payto target-type. Currently an additional instance must be configured, if two or more payment service providers are using the same payto target type. 38 \item Implement more fee models: To allow easier integration of other providers, the described fee models can be centralized in one location. This would help to improve the quality and robustness of the system. 39 \item Database locking: Currently no database locking is used. This can lead to race conditions. To completely prevent this locks can be applied. 40 \item IPv6 support: The process must also listen on IPv6 addresses. 41 \item Support cli without interaction. The cli currently is purely interactive. It would be a nice improvement if the cli would be usable without interactio. This would allow to use the cli for automated tasks. 42 \item Partial refunds: The current implementation only allows refunds of the entire withdrawal amount. In the future the implementation can support partial refunds. 43 \end{enumerate}