commit 7cfdc3195e681bb89cc91608dad6786a40c170c0 parent 86bf99d11cdc6669d86ea8b0661ce8b1ce5f8a70 Author: Joel-Haeberli <haebu@rubigen.ch> Date: Wed, 5 Jun 2024 09:42:34 +0200 docs: enhance Diffstat:
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/content/architecture/overview.tex b/docs/content/architecture/overview.tex @@ -49,7 +49,7 @@ The component diagram shows the components involved by the withdrawal using the The diagram in \autoref{fig-diagram-all-sequence} shows the high level flow to withdraw digital cash using the credit card terminal and Taler. It shows when the components of \autoref{fig-diagram-all-components} interact with each other. It shows the implementation of the flow. terminal, wallet and Exchange are linked leveraging a \textit{WOPID} initially generated by the terminal and presented to the Exchange by the withdrawing wallet accompanied by a reserve public key. -The process requires the terminal, the wallet, the C2EC component and the Exchange which interact with each other. In this section the highlevel process as showed in \autoref{fig-diagram-all-sequence} is explained. +The process requires the terminal, the wallet, the C2EC component and the Exchange who interact with each other. In this section the highlevel process is explained as showed in \autoref{fig-diagram-all-sequence}. \subsection{The Terminal} diff --git a/docs/content/implementation/a-fees.tex b/docs/content/implementation/a-fees.tex @@ -1,10 +1,10 @@ \subsection{Fees} -During the implementation it became obvious that there are several possible fee models, when thinking about the general case. Using a payment service provider to withdraw money, is special because if you want to withdraw 10 CHF then you want 10 CHF in your wallet and not 10 CHF minus the fees. Think of buying a bar of chocolate. You don't care if you pay 10 CHF or 10.10 CHF because in the end you get what you want - a bar of chocolate. When withdrawing money using the credit card you want the amount in your wallet you are asking for - not less. The fees must be transparently communicated to the customer, that they understand why the authorized amount will be higher than the amount they are asking to withdraw. The fees must be calculated before hand. This leads to different models to add fees. Following four models were discovered during a brainstorming session: +During the implementation it became obvious that there are several possible fee models, when thinking about the general case. Using a payment service provider to withdraw money, is special because if you want to withdraw 10 CHF then you want 10 CHF in your wallet and not 10 CHF minus the fees. Think of buying a bar of chocolate. You don't care if you pay 10 CHF or 10.10 CHF because in the end you get what you want - a bar of chocolate. When withdrawing money using the credit card you want the amount in your wallet you are asking for - not less. The fees must be transparently communicated to the customer, that they understand why the authorized amount will be higher than the amount they are asking to withdraw. The fees must be calculated before hand. This leads to different models to add fees. These four models were discovered: \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. Additionally a certain amount can be added on top of the calculated fees to make a profit. +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 could be added on top of the calculated fees to make a profit. \subsubsection{Model 2 - Payment Service Provider Fees} @@ -20,4 +20,4 @@ A payment service provider might add fees but for some reason cannot tell them t \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. +It could be a problem when mixing the different models in one instance of C2EC, because it 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/e-testing.tex b/docs/content/implementation/e-testing.tex @@ -4,4 +4,4 @@ Since the program leverages concurrency and parallizes work a simulation client The Simulation can be used for regression testing and therefore can be run before introducing new features in order to check, that existing functionality will not be broken. -Besides the automated tests, using the above mentioned simulation, unit tests were implemented for parsing, formatting and encoding functions. Additionally manual test were fulfilled to ensure the system behaves correctly. To test the wire-gateway API, the \textit{taler-exchange-wire-gateway-client} \cite{} facility was used supplied by GNU Taler to verify the correct functioning of the API. +Besides the automated tests, using the above mentioned simulation, unit tests were implemented for parsing, formatting and encoding functions. Additionally manual test were fulfilled to ensure the system behaves correctly. To test the wire-gateway API, the \textit{taler-exchange-wire-gateway-client} \cite{taler-exchange-wire-gateway-client} facility was used supplied by GNU Taler to verify the correct functioning of the API. diff --git a/docs/pictures/dreaming_of_a_better_world.jpg b/docs/pictures/dreaming_of_a_better_world.jpg Binary files differ. diff --git a/docs/thesis.pdf b/docs/thesis.pdf Binary files differ.
