diff options
author | MS <ms@taler.net> | 2023-02-14 13:48:07 +0100 |
---|---|---|
committer | MS <ms@taler.net> | 2023-02-14 13:49:24 +0100 |
commit | 122fad14a9d62e901e898fd832b641b46b119ec6 (patch) | |
tree | 5f02bc50822262c4e6ad1de99f1ab124fd9d6557 /design-documents | |
parent | b09701142d5d60446480655afbe88cc36e238ef3 (diff) | |
download | docs-122fad14a9d62e901e898fd832b641b46b119ec6.tar.gz docs-122fad14a9d62e901e898fd832b641b46b119ec6.tar.bz2 docs-122fad14a9d62e901e898fd832b641b46b119ec6.zip |
DD 36, addressing Christian's review.
Diffstat (limited to 'design-documents')
-rw-r--r-- | design-documents/036-currency-conversion-service.rst | 32 |
1 files changed, 14 insertions, 18 deletions
diff --git a/design-documents/036-currency-conversion-service.rst b/design-documents/036-currency-conversion-service.rst index 7c9bbc72..be33c591 100644 --- a/design-documents/036-currency-conversion-service.rst +++ b/design-documents/036-currency-conversion-service.rst @@ -40,7 +40,7 @@ Requirements regional currency ('buy-in' operation). * CCS must offer cash-out operations. * CCS should react as soon as possible to buy-in and cash-out operations. -* CCS must show its state to administrators. +* CCS must show its state to administrators and offer management tools. * CCS must link every fiat-side of a cash-out to its regional currency counterpart. In particular, because every cash-out starts with a payment *P* from regio-user to regio-issuer and ends with another @@ -61,34 +61,30 @@ Sandbox performs a first wire transfer from regio-user to regio-issuer by specifying the amount without any rates/fees applied. Along the same database transaction, Sandbox stores the *instructions* of another payment *P* from fiat-issuer to fiat-target, but this time -**with** the cash-out rates/fees. +**with** the cash-out rates/fees. Notably, P includes the **current** +fiat-target and the rates/fees, since these are configurable. -Asynchronously, a background picks P and sends it to the fiat bank. +Asynchronously, a background task picks P and sends it to the fiat bank. Finally, fiat bank conducts P and fiat-target receives the wanted amount. The same background task should also retry previous payments like P that failed to be submitted to fiat bank. +CCS offers management endpoints for prepared fiat-transactions. +Through them, adminisrators can see, retry, or cancel every fiat-transaction +that was prepared to pay fiat-target. + Buy-in operation ---------------- A buy-in operation starts as soon as the customer sends a fiat payment from fiat-customer to fiat-issuer. Sandbox is responsible to -detect such an incoming payment in a timely fashion. -Because traditional banking protocols (like EBICS) don't allow to long -poll on bank accounts, Sandbox uses background tasks to check fiat-issuer -every X minutes. Those background tasks rely on Nexus ability to speak -EBICS. +detect such an incoming payment in a timely fashion. The detection +happens by long polling on the Nexus JSON API. Nexus is ultimately +responsible to query the fiat bank via EBICS every X seconds. X +should match the tightest interval allowed by the bank. When Sandbox detects one incoming payment on fiat-issuer, it applies the -buy-in rates/fees and wires the resuling amount from regio-issuer to -regio-exchange. At this point, Nexus detects the incoming payment on +**current** buy-in rates/fees and wires the resuling amount from regio-issuer +to regio-exchange. At this point, Nexus detects the incoming payment on regio-exchange and makes the exchange aware via the Taler Wire Gateway API. From now on, the system proceeds like it always did in Taler. - -Background tasks -================ - -The background tasks are responsible for the communication between Sandbox -and fiat bank, in order to drive fiat-issuer. Their implementation requires -to extract the current Nexus background tasks and EBICS logic into own -libraries. |