commit 787bbe5b9a37db24d34994bad346e314016d5f19
parent 368d64189b6354b645f3d289374a02fb497a57da
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Thu, 23 Oct 2025 10:03:22 +0200
spec updates for #10525
Diffstat:
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
@@ -125,7 +125,7 @@ of that instance.
Currently, the ``/private/auth/`` API supports two main authentication methods in the ``InstanceAuthConfigurationMessage``:
-* ``external``: (*@deprecated since v20*) With this method, no checks are done by the merchant backend.
+* ``external``: (@deprecated since **v20**) With this method, no checks are done by the merchant backend.
Instead, a reverse proxy / API gateway must do all authentication/authorization checks.
* ``token`` (**@since v19**): With this method, the client must provide an authorization header
that contains a bearer token when accessing a protected endpoint in the form
@@ -135,14 +135,14 @@ Currently, the ``/private/auth/`` API supports two main authentication methods i
A login token is commonly only valid for a limited period of time and scoped to specific permissions.
If the ``$INSTANCE_PASSWORD`` is lost, the administrator can set a password
using the ``taler-merchant-passwd`` command-line tool.
-* ``token`` (*@deprecated since v19*): With this method, the client must provide an authentication token in
+* ``token`` (@deprecated since **v19**): With this method, the client must provide an authentication token in
the format ``secret-token: $INSTANCE_PASSWORD``.
The behaviour is then equivalent to the ``token`` method above.
Any API may be accessed using the bearer authentication ``secret-token: $INSTANCE_PASSWORD``.
Notice that this behaviour is deprecated and will be phased out in favor of login tokens.
For testing, the service may be started with the configuration option ``DISABLED_AUTHENTICATION = YES``
-in section ``[merchant]`` (@since v20).
+in section ``[merchant]`` (@since **v20**).
Scopes
^^^^^^
@@ -172,7 +172,7 @@ such as the implemented version of the protocol and the currency used.
.. http:get:: /config
Return the protocol version and currency supported by this merchant backend.
- This specification corresponds to ``current`` protocol being version **v21**.
+ This specification corresponds to ``current`` protocol being version **v22**.
**Response:**
@@ -238,6 +238,23 @@ such as the implemented version of the protocol and the currency used.
// Since protocol **v21**
mandatory_tan_channels?: TanChannel[];
+ // Space-separated list of enabled payment target types.
+ // Useful if the SPA should not show allow adding other
+ // types of bank accounts. "*" is used to represent no
+ // restriction.
+ // Since protocol **v22**
+ payment_target_types: string;
+
+ // Regular expression representing further restrictions
+ // on allowed payment targets. Any "payto://"-URI supplied
+ // for a bank account must match the given regular expression.
+ // For example, "payto://iban/CH.*" would restrict the system
+ // to only Swiss bank accounts.
+ // Optional, no restrictions are imposed if the field is
+ // absent.
+ // Since protocol **v22**
+ payment_target_regex? string;
+
}
enum TanChannel {
diff --git a/manpages/taler-merchant.conf.5.rst b/manpages/taler-merchant.conf.5.rst
@@ -196,6 +196,15 @@ HELPER_EMAIL
STRICT_PROTOCOL_V19
Set to YES to strictly enforce protocol version 19 or later. Transient option for development.
+PAYMENT_TARGET_TYPES
+ Space-separated list of allowed payment target types (like bitcoin, iban or x-taler-bank).
+ Defaults to "*" which means no restrictions if not specified.
+
+PAYMENT_TARGET_REGEX
+ POSIX regular expression imposing additional restrictions on the "payto://"-URIs allowed
+ for bank accounts of instances of this system. For example, "payto://iban/CH.*" would
+ restrict the system to only Swiss IBAN accounts. Optional, no restrictions if not set.
+
MERCHANT KYCCHECK OPTIONS
-------------------------
