commit 122fad14a9d62e901e898fd832b641b46b119ec6
parent b09701142d5d60446480655afbe88cc36e238ef3
Author: MS <ms@taler.net>
Date: Tue, 14 Feb 2023 13:48:07 +0100
DD 36, addressing Christian's review.
Diffstat:
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git 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.
