note on #7365

2 files changed, 19 insertions, 11 deletions

diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst
index 410c4d85..bfc6e514 100644
--- a/design-documents/023-taler-kyc.rst
+++ b/design-documents/023-taler-kyc.rst
@@ -17,6 +17,8 @@ banks to identify parties involved in transactions at certain points.
 Requirements
 ============
 
+The solution should support fees to be paid by the user for the KYC process (#7365).
+
 Taler needs to run KYC checks in the following circumstances:
 
 * Customer withdraws money over a monthly threshold
@@ -38,6 +40,10 @@ Taler needs to run KYC checks in the following circumstances:
 
   * key: IBAN (encoded as payto:// URI)
 
+* Reserve is "opened" for invoicing or tipping.
+
+  * key: reserve (=KYC account) long term public key per wallet (encoded as payto:// URI)
+
 
 
 Proposed Solution
@@ -97,8 +103,8 @@ Access is ``authenticated`` by also passing the hash of the payto://-URI.
 initiate a KYC process are not very sensitive.)  Given this triplet, the
 ``/kyc-check/`` endpoint returns either the (positive) KYC status or redirects
 the client (202) to the next required stage of the KYC process.  The
-redirection must be for an HTTP(S) endpoint to be triggered via a simple HTTP
-GET.
+redirection must be for an HTTP(S) endpoint to be triggered via a simple HTTP GET.  As this endpoint is involved in every KYC check at the beginning, this is also the place where we can
+integrate the payment process for the KYC fee.
 
 The specific KYC provider to be executed depends on the configuration (see
 below) which specifies a ``$PROVIDER_SECTION`` for each authentication procedure.
@@ -310,6 +316,10 @@ long-poller return with positive news.
     128-bit salt values (to keep ``deposits`` table small) and checks for salt
     to be well-formed should be added "everywhere".
 
+An additional complication will arise once the exchange can trigger a KYC
+fee (402) on ``/kyc-check/``.  In this case, the merchant SPA must show the QR
+code to the merchant to allow the merchant to pay the KYC fee with a wallet.
+
 
 
 Bank requirements
diff --git a/design-documents/031-invoicing.rst b/design-documents/031-invoicing.rst
index 24c64d79..419c299d 100644
--- a/design-documents/031-invoicing.rst
+++ b/design-documents/031-invoicing.rst
@@ -29,21 +29,19 @@ Requirements
     (or require purse fees if limit is exceeded).
 
   * Ensure user has done KYC before doing a merge.
-
-  * Support fees to be paid by the user for KYC process.
+    (Assuming the exchange does KYC at all.)
 
   * Use information from KYC process to help payer identify payee.
 
   * Reasonable UX and overall design impact.
 
-Unclear in the current proposal are:
+  * Wallets may want to pay for the reserve with coins
+    (reserve fresh, not created via bank transfer), while
+    tipping merchants likely want to pay from the reserve
+    balance itself. So both styles of payment should be
+    supported.
 
-  * How to pay for the opening. Do we support the use of
-    coins, or should we require the user to have a
-    sufficient balance in the reserve, or do we allow
-    both? Probably best to only support one. As
-    reserves are typically instant-drained by the
-    wallet, might be best to require coins?
+Unclear in the current proposal are:
 
   * Here (and in other places!), the payment of the KYC
     fee remains, eh, obscure. This should probably be