note on #7365

3 files changed, 29 insertions, 14 deletions

diff --git a/core/api-exchange.rst b/core/api-exchange.rst
index 6680cd88..720d5a82 100644
--- a/core/api-exchange.rst
+++ b/core/api-exchange.rst
@@ -4243,11 +4243,11 @@ KYC status updates
   Check or update KYC status of a particular payment target.
   Returns the current KYC status of the account and, if
   negative, returns the URL where the KYC process can be
-  initiated.  The REQUIREMENT_ROW must have been
+  initiated.  The ``$REQUIREMENT_ROW`` must have been
   returned previously from an exchange API endpoint that
-  determined that KYC was needed.  The H_PATYO must be
+  determined that KYC was needed.  The ``$H_PATYO`` must be
   the hash of the payto:// URI of the payment target.
-  The USERTYPE states whether the entity to perform
+  The ``$USERTYPE`` states whether the entity to perform
   the KYC is an "individual" or "business".
 
   **Request:**
@@ -4273,6 +4273,9 @@ KYC status updates
   :http:statuscode:`204 No content`:
     The exchange is not configured to perform KYC and thus
     generally all accounts are simply considered legitimate.
+  :http:statuscode:`402 Payment Required`:
+    The client must pay the KYC fee for the KYC process.
+    **This is currently not implemented, see #7365.**
   :http:statuscode:`403 Forbidden`:
     The provided hash does not match the payment target.
   :http:statuscode:`404 Not found`:
@@ -4428,6 +4431,10 @@ naturally expire and possibly (5) wire the funds to a designated account.
       // operation.
       payments: OpenPaymentDetail[];
 
+      // Amount to be paid from the reserve for this
+      // operation.
+      reserve_payment: Amount;
+
       // Time when the client made the request.
       // Timestamp must be reasonably close to the time of
       // the exchange, otherwise the exchange may reject
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