commit 74cb1db22cb6b87f17ed16127f44415875d11509
parent af3256d381a0e8fa505b7e0fa683a7540beb2357
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Sat, 1 Jun 2024 15:23:47 +0200
docs: enhance
Diffstat:
5 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/docs/content/implementation/a-fees.tex b/docs/content/implementation/a-fees.tex
@@ -4,7 +4,7 @@ During the implementation it became obvious that there are several possible fee
\subsubsection{Model 1 - Exchange Operator Fees}
-The payment system provider will charge its business users in the background and expects the Exchange operator to calculate the fees to cover its costs. This means that the Exchange operator will specify its fees by approximating its costs to operate and maintain C2EC.
+The payment system provider will charge its business users in the background and expects the Exchange operator to calculate the fees to cover its costs. This means that the Exchange operator will specify its fees by approximating its costs to operate and maintain C2EC. Additionally a certain amount can be added on top of the calculated fees to make a profit.
\subsubsection{Model 2 - Payment Service Provider Fees}
@@ -17,3 +17,7 @@ The combination of the first two models. The Exchange operator decides to add fe
\subsubsection{Model 4 - Payment Service Provider "Late Fees"}
A payment service provider might add fees but for some reason cannot tell them to C2EC before authorizing the transaction. In this case the confirmation process of the payment service provider needs to make sure that the fees are substracted from the withdrawal amount. Otherwise the Exchange operator must cover the costs, which will lead to loss of money. This must be prevented. This fee model must be prevented when possible, because it leads to a bad user-experience. The amount which can be withdrawn will be lower than the amount authorized.
+
+\subsubsection{Mixing models}
+
+It could be a problem when mixing the different models in one instance, because this could lead to conflicts. For example if a provider using the model 1 and a provider using the model 2 is operated within the same instance this could lead to more fees for the provider using model 2, since the fees of the Exchange operator should not be considered. In the future it might be possible to handle various fee models in one instance. This would require the implementation of all models. For the thesis model 1 was implemented because Wallee uses this model. These models also resolve the discussion of the midterm meeting with Dr. Alain Hiltgen.
diff --git a/docs/content/implementation/b-terminal.tex b/docs/content/implementation/b-terminal.tex
@@ -93,6 +93,9 @@ The Taler Exchange configures a duration for which a reserve is kept open (and c
\textbf{Manual request to refund money}
Depending on the operator of the Taler Exchange it might be possible to somehow manually trigger a refund and get back the money spent for the withdrawal.
-% TODO new section for Authorize -> Complete -> Execute Final Balance flow
+\subsection{Fulfilling Transactions}
+
+To achieve finality and real-time behaviour of the withdrawal flow, the transaction must be forcefully transitioned to the \textit{fulfill} state in the Wallee backend. For this reason, the payments are not only authorized but also automatically completed in the background. After the successful completion, the payment can be directly settled and with this guarantee the finality by executing the final balance.
+% TODO Wallee Feedback einbauen
\newpage
\ No newline at end of file
diff --git a/docs/content/implementation/d-security.tex b/docs/content/implementation/d-security.tex
@@ -16,7 +16,7 @@ This case is possible, when an attacker can trick the C2EC to have confirmed wit
\subsubsection{Developer issues}
-Another problem could be developers introducing confirmation bugs. The confirmation process of a transaction must be considered as the holy grail from the perspective of the developers. If they do not take biggest care implementing the confirmation process, this could lead to loss of money on the side of the Exchange operator. The program should strictly disallow withdrawals, if the transaction is not guaranteed to be final by the payment system provider. Otherwise the finality is harmed and the system no longer secure. When adding new integrations, this section of the code needs great care and review before going to production.
+Another problem could be developers introducing confirmation bugs. The confirmation process of a transaction must be considered as the holy grail from the perspective of the developers. If they do not take biggest care implementing the confirmation process, this could lead to loss of money on the side of the Exchange operator. The program should strictly disallow withdrawals, if the transaction is not guaranteed to be final by the payment system provider. Otherwise the property of the guarantees concerning the finality is harmed and the system no longer secure (in terms of money). When adding new integrations, this section of the code needs great care and review before going to production.
\subsection{Withdrawal Operation Identifier (WOPID)}
\label{sec-security-wopid}
diff --git a/docs/content/results/reflexion.tex b/docs/content/results/reflexion.tex
@@ -22,14 +22,14 @@ I first had problems to understand how exactly the versioning in Android works.
Since the app needs to do requests in the background I had to understand how this could be achieved. Therefore I needed to understand how I can access other threads. I think in this area is the biggest shortcoming of my implementation. I implemented a asynchronous state-handling. Threads running detached from the UI-Thread will update the model, which will lead to the regeneration of the composables. I think it would be a better way to implement a proper pub / sub model using a library like rxjs or similar. Due to the lack of time I decided to not do this anymore.
-It was interesting to learn about the difference of Go's goroutines and Kotlin coroutines. While running background tasks using goroutines works perfectly fine, in Kotlin on Android I learnt it is required to start a new thread and launch coroutines on the new thread. Otherwise Android will not allow network requests, because it disallows I/O operations on its UI thread. From my point of view this shows a limitation of coroutines on top of JVM threads. They are not real parallel but just suspend work on the thread and check periodically if the can process further. Go resolves this problem in an elegant way by simply putting all network related I/O into a special queue.
+It was interesting to learn about the difference of Go's goroutines and Kotlin coroutines. While running background tasks using goroutines works perfectly fine, in Kotlin on Android I learnt it is required to start a new thread and launch coroutines on the new thread. Otherwise Android will not allow network requests, because it disallows I/O operations on its UI thread. From my point of view this shows a limitation of coroutines on top of JVM threads. They are not real parallel but just suspend work on the thread and check periodically if they can process further. If there are thread level restrictions (like the Android restrictions), they will affect the execution of the coroutines on top and like this undermine the concept of coroutines.
\subsection{Methodically}
-To organize the work I did a rough planning of the work and the artefacts. On top of this plan I did a weekly iterative planning of the work I wanted to do. This plan was presented through the weekly meeting with Prof. Dr. Christian Grothoff and Prof. Dr. Benjamin Fehrensen. Sometimes the plan needed to be sligthly adjusted due to their feedback. This led to the organization of doing my planning at thursday night so I could plan my work and adjust the plan after our weekly meeting at wednesday morning. I think I could have made the process a bit more transparent but in the end I was able to deliver the artefacts and deliverables on time. Sometimes I lost focus because there were so much loose ends to keep up with. I then did something different and ordered my thoughts. This helped sometimes but not always. When the stress level was rising this was more difficult.
+To organize the work I did a rough planning of the work and the artefacts. On top of this plan I did a weekly iterative planning of the work I wanted to do. This plan was presented through the weekly meeting with Prof. Dr. Christian Grothoff and Prof. Dr. Benjamin Fehrensen. Sometimes the plan needed to be sligthly adjusted due to their feedback. This led to the organization of doing my planning at thursday night so I could plan my work and adjust the plan after our weekly meeting at wednesday morning. I think I could have made the process a bit more transparent but in the end I was able to deliver the artefacts and deliverables on time. Sometimes I lost focus because there were so much loose ends to keep up with. I then did something different and ordered my thoughts. This helped sometimes but not always. When the stress level was rising this was even more difficult. In such situations taking a step back and prioritzing the work helped me.
\subsection{Personally}
-The thesis was constrained with a lot of insecurities for me. How does the process look? How can I implement the process? How does GNU Taler even work? How does Wallee work? In the end I am proud of what I accomplished during the thesis. I was able to understand the API and write a program which fulfills the properties needed for the withdrawal. Additionally I could learn a lot about designing an API. I am thankful that the Bern University of Applied Sciences supports free software projects like GNU Taler. It was a great opportunity for me as student to gain direct insights and work on a GNU project during my thesis. I remember that Prof. Dr. Christian Grothoff during an onsite session told me: "Nicht so kurzfristig denken!". This also shows the horizon of the project. It tries to sustainably change the payment landscape. That is what I like the most about free software. It is built to last.
+The thesis was constrained with a lot of insecurities for me. How does the process look? How can I implement the process? How does GNU Taler even work? How does Wallee work? In the end I am proud of what I accomplished during the thesis. I was able to understand the API and write a program which fulfills the properties needed for the withdrawal. Additionally I could learn a lot about designing an API. I am thankful that the Bern University of Applied Sciences supports free software projects like GNU Taler. It was a great opportunity for me as student to gain direct insights and work on a GNU project during my thesis. I remember Prof. Dr. Christian Grothoff telling me during an onsite session: "Nicht so kurzfristig denken!" (don't think shortterm). This also shows the horizon of the project. It tries to sustainably change the payment landscape (for good I think). That is what I like the most about free software. It is built to last.
The world of payment systems seems a bit chaotic to me. I think this is the result of a lot of different approaches developed at the same time for the same problem. There are standards but they mainly suggest things and do not enforce them. The technical documentation is obfuscated in big documents with a lot of boiler plate text. This makes it very hard to handle appropriately without finding out how a process works exactly by hand. For example to bring a Wallee transaction into the fulfill state (which allows the shipping of goods) you must settle the transaction and execeute the final balance. The documentation does not care about this. I had to write e-mails with Wallee to finally understand this. Even the people of Wallee messed up their own transaction states.
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
