update prebuilt docs

70 files changed, 7182 insertions, 3635 deletions

diff --git a/man/challenger-admin.1 b/man/challenger-admin.1
index 09fbc2aa..7347ff9c 100644
--- a/man/challenger-admin.1
+++ b/man/challenger-admin.1
@@ -27,19 +27,19 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "CHALLENGER-ADMIN" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "CHALLENGER-ADMIN" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 challenger-admin \- manipulate list of authorized Challenger clients
 .SH SYNOPSIS
 .sp
 \fBchallenger\-admin\fP
-[\fB\-a\fP \fICLIENT_SECRET\fP\ |\ \fB\-\-add=\fP\fICLIENT_SECRET\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-d\fP\ |\ \fB\-\-delete\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-log=\fP\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP\fIFILENAME\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP] CLIENT_URL
+[\fB\-a\fP \fICLIENT_SECRET\fP\ |\ \fB–add=\fP\fICLIENT_SECRET\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-d\fP\ |\ \fB–delete\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–log=\fP\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP\fIFILENAME\fP]
+[\fB\-v\fP\ |\ \fB–version\fP] CLIENT_URL
 .SH DESCRIPTION
 .sp
 \fBchallenger\-admin\fP is a command\-line tool to add or delete clients from the Challenger database.
@@ -47,23 +47,23 @@ challenger-admin \- manipulate list of authorized Challenger clients
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-a\fP \fISECRET\fP | \fB\-\-add=\fP‌\fISECRET\fP
+\fB\-a\fP \fISECRET\fP | \fB–add=\fP‌\fISECRET\fP
 Add the client with the given \fICLIENT_URL setting the client secret to *SECRET\fP\&.  Prints the CLIENT_ID of the added client.
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the Challenger commands
 to operate from \fIFILENAME\fP\&.
 .TP
-\fB\-d\fP | \fB\-\-delete\fP
+\fB\-d\fP | \fB–delete\fP
 Delete the client with the given \fICLIENT_URL\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-log=\fP\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–log=\fP\fILOGLEVEL\fP
 Configure logging to use \fILOGLEVEL\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP\fIFILENAME\fP
 Configure logging to write logs to \fIFILENAME\fP\&.
 .TP
 \fB\-v\fP | \fB–version\fP
diff --git a/man/challenger-config.1 b/man/challenger-config.1
index 33d60ef3..48d7c215 100644
--- a/man/challenger-config.1
+++ b/man/challenger-config.1
@@ -27,75 +27,75 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "CHALLENGER-CONFIG" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "CHALLENGER-CONFIG" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 challenger-config \- manipulate Challenger configuration files
 .SH SYNOPSIS
 .sp
 \fBchallenger\-config\fP
-[\fB\-b\fP\ \fIbackend\fP\ |\ \fB\-\-supported\-backend=\fP\fIbackend\fP]
-[\fB\-c\fP\ \fIfilename\fP\ |\ \fB\-\-config=\fP\fIfilename\fP]
-[\fB\-f\fP\ |\ \fB\-\-filename\fP]
-[\fB\-F\fP\ |\ \fB\-\-full\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fIloglevel\fP\ |\ \fB\-\-loglevel=\fP\fIloglevel\fP]
-[\fB\-l\fP\ \fIfilename\fP\ |\ \fB\-\-logfile=\fP‌\fIfilename\fP]
-[\fB\-o\fP\ \fIoption\fP\ |\ \fB\-\-option=\fP\fIoption\fP]
-[\fB\-r\fP\ |\ \fB\-\-rewrite\fP]
-[\fB\-S\fP\ |\ \fB\-\-list\-sections\fP]
-[\fB\-s\fP\ \fIsection\fP\ |\ \fB\-\-section=\fP\fIsection\fP]
-[\fB\-V\fP\ \fIvalue\fP\ |\ \fB\-\-value=\fP\fIvalue\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-b\fP\ \fIbackend\fP\ |\ \fB–supported\-backend=\fP\fIbackend\fP]
+[\fB\-c\fP\ \fIfilename\fP\ |\ \fB–config=\fP\fIfilename\fP]
+[\fB\-f\fP\ |\ \fB–filename\fP]
+[\fB\-F\fP\ |\ \fB–full\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fIloglevel\fP\ |\ \fB–loglevel=\fP\fIloglevel\fP]
+[\fB\-l\fP\ \fIfilename\fP\ |\ \fB–logfile=\fP‌\fIfilename\fP]
+[\fB\-o\fP\ \fIoption\fP\ |\ \fB–option=\fP\fIoption\fP]
+[\fB\-r\fP\ |\ \fB–rewrite\fP]
+[\fB\-S\fP\ |\ \fB–list\-sections\fP]
+[\fB\-s\fP\ \fIsection\fP\ |\ \fB–section=\fP\fIsection\fP]
+[\fB\-V\fP\ \fIvalue\fP\ |\ \fB–value=\fP\fIvalue\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBchallenger\-config\fP can be used to read or modify Challenger configuration files.
 .INDENT 0.0
 .TP
-\fB\-b\fP \fIBACKEND\fP | \fB\-\-supported\-backend=\fP\fIBACKEND\fP
+\fB\-b\fP \fIBACKEND\fP | \fB–supported\-backend=\fP\fIBACKEND\fP
 Tests whether the specified \fIBACKEND\fP is supported by the current installation.
-The backend must match the name of a plugin, i.e. \(dqnamestore_postgres\(dq for
-the PostgreSQL database backend of the \(dqNAMESTORE\(dq service.  If \fIBACKEND\fP is
+The backend must match the name of a plugin, i.e. “namestore_postgres” for
+the PostgreSQL database backend of the “NAMESTORE” service.  If \fIBACKEND\fP is
 supported, challenger\-config will return a status code of 0 (success), otherwise
 77 (unsupported).  When this option is specified, no other options may be
 specified. Specifying this option together with other options will cause
 challenger\-config to return a status code of 1 (error).
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP\fIFILENAME\fP
 Use the configuration file \fIFILENAME\fP\&.
 .TP
-\fB\-f\fP | \fB\-\-filename\fP
+\fB\-f\fP | \fB–filename\fP
 Try to perform expansions as if the option values represent filenames (will
 also be applied even if the option is not really a filename).
 .TP
-\fB\-F\fP | \fB\-\-full\fP
+\fB\-F\fP | \fB–full\fP
 Write the full configuration file, not just the differences to the defaults.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP\fILOGLEVEL\fP
 Use \fILOGLEVEL\fP for logging.
 Valid values are \fBDEBUG\fP, \fBINFO\fP, \fBWARNING\fP, and \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-o\fP \fIOPTION\fP | \fB\-\-option=\fP\fIOPTION\fP
+\fB\-o\fP \fIOPTION\fP | \fB–option=\fP\fIOPTION\fP
 Which configuration option should be accessed or edited.  Required to set a
 value.  If not given, all values of a given section will be printed in the
-format \(dqOPTION = VALUE\(dq.
+format “OPTION = VALUE”.
 .TP
-\fB\-r\fP | \fB\-\-rewrite\fP
+\fB\-r\fP | \fB–rewrite\fP
 Write the configuration file even if nothing changed. Will remove all comments!
 .TP
-\fB\-S\fP | \fB\-\-list\-sections\fP
+\fB\-S\fP | \fB–list\-sections\fP
 List available configuration sections for use with \fB\-\-section\fP\&.
 .TP
-\fB\-s\fP \fISECTION\fP | \fB\-\-section=\fP\fISECTION\fP
+\fB\-s\fP \fISECTION\fP | \fB–section=\fP\fISECTION\fP
 Which configuration section should be accessed or edited.
 Required option.
 .TP
-\fB\-V\fP \fIVALUE\fP | \fB\-\-value=\fP\fIVALUE\fP
+\fB\-V\fP \fIVALUE\fP | \fB–value=\fP\fIVALUE\fP
 Configuration value to store in the given section under the given option.
 Must only be given together with \fB\-s\fP and \fB\-o\fP options.
 .INDENT 7.0
@@ -105,7 +105,7 @@ Changing the configuration file with \fB\-V\fP will remove comments
 and may reorder sections and remove \fB@INLINE@\fP directives.
 .UNINDENT
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print GNU Taler version number.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/challenger-dbconfig.1 b/man/challenger-dbconfig.1
index d83e116a..4d6c1cbd 100644
--- a/man/challenger-dbconfig.1
+++ b/man/challenger-dbconfig.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "CHALLENGER-DBCONFIG" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "CHALLENGER-DBCONFIG" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 challenger-dbconfig \- configure challenger database
 .SH SYNOPSIS
diff --git a/man/challenger-dbinit.1 b/man/challenger-dbinit.1
index 06575f06..aee5632d 100644
--- a/man/challenger-dbinit.1
+++ b/man/challenger-dbinit.1
@@ -27,19 +27,19 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "CHALLENGER-DBINIT" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "CHALLENGER-DBINIT" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 challenger-dbinit \- initialize the Challenger database
 .SH SYNOPSIS
 .sp
 \fBchallenger\-dbinit\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-g\fP\ |\ \fB\-\-garbagecollect\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-log=\fP\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP\fIFILENAME\fP]
-[\fB\-r\fP\ |\ \fB\-\-reset\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-g\fP\ |\ \fB–garbagecollect\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–log=\fP\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP\fIFILENAME\fP]
+[\fB\-r\fP\ |\ \fB–reset\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBchallenger\-dbinit\fP is a command\-line tool to initialize the Challenger database.
@@ -47,23 +47,23 @@ challenger-dbinit \- initialize the Challenger database
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the Challenger commands
 to operate from \fIFILENAME\fP\&.
 .TP
-\fB\-g\fP | \fB\-\-garbagecollect\fP
+\fB\-g\fP | \fB–garbagecollect\fP
 Remove state data from database.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-log=\fP\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–log=\fP\fILOGLEVEL\fP
 Configure logging to use \fILOGLEVEL\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP\fIFILENAME\fP
 Configure logging to write logs to \fIFILENAME\fP\&.
 .TP
-\fB\-r\fP | \fB\-\-reset\fP
+\fB\-r\fP | \fB–reset\fP
 Reset database.  (\fBDANGEROUS\fP: All existing data is lost!)
 .TP
 \fB\-v\fP | \fB–version\fP
diff --git a/man/challenger-httpd.1 b/man/challenger-httpd.1
index f0241d89..265447ed 100644
--- a/man/challenger-httpd.1
+++ b/man/challenger-httpd.1
@@ -27,18 +27,18 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "CHALLENGER-HTTPD" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "CHALLENGER-HTTPD" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 challenger-httpd \- provide the Challenger HTTP interface
 .SH SYNOPSIS
 .sp
 \fBchallenger\-httpd\fP
-[\fB\-C\fP\ |\ \fB\-\-connection\-close\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-log=\fP\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP\fIFILENAME\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-C\fP\ |\ \fB–connection\-close\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–log=\fP\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP\fIFILENAME\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBchallenger\-httpd\fP is a command\-line tool to provide the Challenger HTTP interface.
@@ -46,20 +46,20 @@ challenger-httpd \- provide the Challenger HTTP interface
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-C\fP | \fB\-\-connection\-close\fP
+\fB\-C\fP | \fB–connection\-close\fP
 Force HTTP connections to be closed after each request.
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the Challenger commands
 to operate from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-log=\fP\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–log=\fP\fILOGLEVEL\fP
 Configure logging to use \fILOGLEVEL\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP\fIFILENAME\fP
 Configure logging to write logs to \fIFILENAME\fP\&.
 .TP
 \fB\-v\fP | \fB–version\fP
diff --git a/man/challenger.conf.5 b/man/challenger.conf.5
index 79260442..5afe3706 100644
--- a/man/challenger.conf.5
+++ b/man/challenger.conf.5
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "CHALLENGER.CONF" "5" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "CHALLENGER.CONF" "5" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 challenger.conf \- Challenger configuration file
 .SH DESCRIPTION
diff --git a/man/libeufin-nexus.1 b/man/libeufin-nexus.1
index cb882455..dd8b58cc 100644
--- a/man/libeufin-nexus.1
+++ b/man/libeufin-nexus.1
@@ -27,15 +27,15 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "LIBEUFIN-NEXUS" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "LIBEUFIN-NEXUS" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 libeufin-nexus \- service to interface to various bank access APIs
 .SH SYNOPSIS
 .sp
 \fBlibeufin\-nexus\fP
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-\-version\fP]
-COMMAND [ARGS...]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB–version\fP]
+COMMAND [ARGS…]
 .sp
 Commands: serve, superuser, parse\-camt, reset\-tables
 .SH DESCRIPTION
@@ -53,7 +53,7 @@ useful for doing administrative tasks.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
 \fB–version\fP
diff --git a/man/libeufin-sandbox.1 b/man/libeufin-sandbox.1
index 63771a20..ffb76fd8 100644
--- a/man/libeufin-sandbox.1
+++ b/man/libeufin-sandbox.1
@@ -27,15 +27,15 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "LIBEUFIN-SANDBOX" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "LIBEUFIN-SANDBOX" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 libeufin-sandbox \- simulate core banking system with EBICS access to bank accounts
 .SH SYNOPSIS
 .sp
 \fBlibeufin\-sandbox\fP
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-\-version\fP]
-COMMAND [ARGS...]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB–version\fP]
+COMMAND [ARGS…]
 .sp
 Commands: serve, reset\-tables, config, make\-transaction, camt053tick
 default\-exchange
@@ -49,12 +49,12 @@ requests either over the network or via a Unix domain socket.
 Related program \fBlibeufin\-cli\fP is the preferred front end
 for that mode of operation.
 There is also a mode where \fBlibeufin\-sandbox\fP accepts commands directly,
-useful for configuring one or more \(dqdemobank\(dq (simulated bank) instances.
+useful for configuring one or more “demobank” (simulated bank) instances.
 .sp
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
 \fB–version\fP
@@ -88,10 +88,10 @@ Option \fB\-\-captcha\-url $URL\fP specifies where the wallet user is going
 to be redirected to confirm the withdrawal operation. This $URL should
 point to the bank frontend. More precisely to the UI that let the user
 finish a withdrawal operation that needs to be confirmed. Example of
-this value may be \(dq\fI\%https://bank.domain/#/operation\fP/{wopid}\(dq where
-\(dq\fI\%https://bank.domain\fP\(dq returns the demobank SPA and the demobank view under
-the route \(dq/operation/{wopid}\(dq will show the status of the operation id {wopid}.
-Note that \(dq{wopid}\(dq is literally in the \-\-captcha\-url config and replaced at
+this value may be “\fI\%https://bank.domain/#/operation\fP/{wopid}” where
+“\fI\%https://bank.domain\fP” returns the demobank SPA and the demobank view under
+the route “/operation/{wopid}” will show the status of the operation id {wopid}.
+Note that “{wopid}” is literally in the –captcha\-url config and replaced at
 runtime by the sandbox server.
 Option \fB\-\-bank\-debt\-limit N\fP (default: 1000000) specifies that
 the bank debt limit should be N (units of currency).
@@ -141,7 +141,7 @@ This sets the default exchange for demobank \fBbank01\fP\&.
 It is an error if the demobank does not exist.
 .SS make\-transaction
 .sp
-This is a \(dqlegacy\(dq command, useful in a previous iteration of LibEuFin
+This is a “legacy” command, useful in a previous iteration of LibEuFin
 and for internal testing.
 It creates and records a wire transfer transaction in the database.
 .sp
diff --git a/man/sync-config.1 b/man/sync-config.1
index d5c728a5..420b0934 100644
--- a/man/sync-config.1
+++ b/man/sync-config.1
@@ -27,75 +27,75 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "SYNC-CONFIG" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "SYNC-CONFIG" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 sync-config \- manipulate Sync configuration files
 .SH SYNOPSIS
 .sp
 \fBsync\-config\fP
-[\fB\-b\fP\ \fIbackend\fP\ |\ \fB\-\-supported\-backend=\fP\fIbackend\fP]
-[\fB\-c\fP\ \fIfilename\fP\ |\ \fB\-\-config=\fP\fIfilename\fP]
-[\fB\-f\fP\ |\ \fB\-\-filename\fP]
-[\fB\-F\fP\ |\ \fB\-\-full\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fIloglevel\fP\ |\ \fB\-\-loglevel=\fP\fIloglevel\fP]
-[\fB\-l\fP\ \fIfilename\fP\ |\ \fB\-\-logfile=\fP‌\fIfilename\fP]
-[\fB\-o\fP\ \fIoption\fP\ |\ \fB\-\-option=\fP\fIoption\fP]
-[\fB\-r\fP\ |\ \fB\-\-rewrite\fP]
-[\fB\-S\fP\ |\ \fB\-\-list\-sections\fP]
-[\fB\-s\fP\ \fIsection\fP\ |\ \fB\-\-section=\fP\fIsection\fP]
-[\fB\-V\fP\ \fIvalue\fP\ |\ \fB\-\-value=\fP\fIvalue\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-b\fP\ \fIbackend\fP\ |\ \fB–supported\-backend=\fP\fIbackend\fP]
+[\fB\-c\fP\ \fIfilename\fP\ |\ \fB–config=\fP\fIfilename\fP]
+[\fB\-f\fP\ |\ \fB–filename\fP]
+[\fB\-F\fP\ |\ \fB–full\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fIloglevel\fP\ |\ \fB–loglevel=\fP\fIloglevel\fP]
+[\fB\-l\fP\ \fIfilename\fP\ |\ \fB–logfile=\fP‌\fIfilename\fP]
+[\fB\-o\fP\ \fIoption\fP\ |\ \fB–option=\fP\fIoption\fP]
+[\fB\-r\fP\ |\ \fB–rewrite\fP]
+[\fB\-S\fP\ |\ \fB–list\-sections\fP]
+[\fB\-s\fP\ \fIsection\fP\ |\ \fB–section=\fP\fIsection\fP]
+[\fB\-V\fP\ \fIvalue\fP\ |\ \fB–value=\fP\fIvalue\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBsync\-config\fP can be used to read or modify Sync configuration files.
 .INDENT 0.0
 .TP
-\fB\-b\fP \fIBACKEND\fP | \fB\-\-supported\-backend=\fP\fIBACKEND\fP
+\fB\-b\fP \fIBACKEND\fP | \fB–supported\-backend=\fP\fIBACKEND\fP
 Tests whether the specified \fIBACKEND\fP is supported by the current installation.
-The backend must match the name of a plugin, i.e. \(dqnamestore_postgres\(dq for
-the PostgreSQL database backend of the \(dqNAMESTORE\(dq service.  If \fIBACKEND\fP is
+The backend must match the name of a plugin, i.e. “namestore_postgres” for
+the PostgreSQL database backend of the “NAMESTORE” service.  If \fIBACKEND\fP is
 supported, sync\-config will return a status code of 0 (success), otherwise
 77 (unsupported).  When this option is specified, no other options may be
 specified. Specifying this option together with other options will cause
 sync\-config to return a status code of 1 (error).
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP\fIFILENAME\fP
 Use the configuration file \fIFILENAME\fP\&.
 .TP
-\fB\-f\fP | \fB\-\-filename\fP
+\fB\-f\fP | \fB–filename\fP
 Try to perform expansions as if the option values represent filenames (will
 also be applied even if the option is not really a filename).
 .TP
-\fB\-F\fP | \fB\-\-full\fP
+\fB\-F\fP | \fB–full\fP
 Write the full configuration file, not just the differences to the defaults.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP\fILOGLEVEL\fP
 Use \fILOGLEVEL\fP for logging.
 Valid values are \fBDEBUG\fP, \fBINFO\fP, \fBWARNING\fP, and \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-o\fP \fIOPTION\fP | \fB\-\-option=\fP\fIOPTION\fP
+\fB\-o\fP \fIOPTION\fP | \fB–option=\fP\fIOPTION\fP
 Which configuration option should be accessed or edited.  Required to set a
 value.  If not given, all values of a given section will be printed in the
-format \(dqOPTION = VALUE\(dq.
+format “OPTION = VALUE”.
 .TP
-\fB\-r\fP | \fB\-\-rewrite\fP
+\fB\-r\fP | \fB–rewrite\fP
 Write the configuration file even if nothing changed. Will remove all comments!
 .TP
-\fB\-S\fP | \fB\-\-list\-sections\fP
+\fB\-S\fP | \fB–list\-sections\fP
 List available configuration sections for use with \fB\-\-section\fP\&.
 .TP
-\fB\-s\fP \fISECTION\fP | \fB\-\-section=\fP\fISECTION\fP
+\fB\-s\fP \fISECTION\fP | \fB–section=\fP\fISECTION\fP
 Which configuration section should be accessed or edited.
 Required option.
 .TP
-\fB\-V\fP \fIVALUE\fP | \fB\-\-value=\fP\fIVALUE\fP
+\fB\-V\fP \fIVALUE\fP | \fB–value=\fP\fIVALUE\fP
 Configuration value to store in the given section under the given option.
 Must only be given together with \fB\-s\fP and \fB\-o\fP options.
 .INDENT 7.0
@@ -105,7 +105,7 @@ Changing the configuration file with \fB\-V\fP will remove comments
 and may reorder sections and remove \fB@INLINE@\fP directives.
 .UNINDENT
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print GNU Taler version number.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/sync-dbconfig.1 b/man/sync-dbconfig.1
index 126efca6..cff3641f 100644
--- a/man/sync-dbconfig.1
+++ b/man/sync-dbconfig.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "SYNC-DBCONFIG" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "SYNC-DBCONFIG" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 sync-dbconfig \- configure sync database
 .SH SYNOPSIS
diff --git a/man/sync-dbinit.1 b/man/sync-dbinit.1
index 98bb5d8f..72a84dcf 100644
--- a/man/sync-dbinit.1
+++ b/man/sync-dbinit.1
@@ -27,19 +27,19 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "SYNC-DBINIT" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "SYNC-DBINIT" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 sync-dbinit \- initialize the Sync database
 .SH SYNOPSIS
 .sp
 \fBsync\-dbinit\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-g\fP\ |\ \fB\-\-garbagecollect\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-log=\fP\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP\fIFILENAME\fP]
-[\fB\-r\fP\ |\ \fB\-\-reset\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-g\fP\ |\ \fB–garbagecollect\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–log=\fP\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP\fIFILENAME\fP]
+[\fB\-r\fP\ |\ \fB–reset\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBsync\-dbinit\fP is a command\-line tool to initialize the Sync database.
@@ -47,23 +47,23 @@ sync-dbinit \- initialize the Sync database
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the Sync commands
 to operate from \fIFILENAME\fP\&.
 .TP
-\fB\-g\fP | \fB\-\-garbagecollect\fP
+\fB\-g\fP | \fB–garbagecollect\fP
 Remove state data from database.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-log=\fP\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–log=\fP\fILOGLEVEL\fP
 Configure logging to use \fILOGLEVEL\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP\fIFILENAME\fP
 Configure logging to write logs to \fIFILENAME\fP\&.
 .TP
-\fB\-r\fP | \fB\-\-reset\fP
+\fB\-r\fP | \fB–reset\fP
 Reset database.  (\fBDANGEROUS\fP: All existing data is lost!)
 .TP
 \fB\-v\fP | \fB–version\fP
diff --git a/man/sync-httpd.1 b/man/sync-httpd.1
index b9c6c3ae..75742634 100644
--- a/man/sync-httpd.1
+++ b/man/sync-httpd.1
@@ -27,22 +27,22 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "SYNC-HTTPD" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "SYNC-HTTPD" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 sync-httpd \- provide the Sync HTTP interface
 .SH SYNOPSIS
 .sp
 \fBsync\-httpd\fP
-[\fB\-A\fP\ \fIUSERNAME:PASSWORD\fP\ |\ \fB\-\-auth=\fP\fIUSERNAME:PASSWORD\fP]
-[\fB\-C\fP\ |\ \fB\-\-connection\-close\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-k\fP\ \fIKEYFILE\fP\ |\ \fB\-\-key=\fP\fIKEYFILE\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-log=\fP\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP\fIFILENAME\fP]
-[\fB\-p\fP\ \fIKEYFILEPASSPHRASE\fP\ |\ \fB\-\-pass=\fP\fIKEYFILEPASSPHRASE\fP]
-[\fB\-t\fP\ \fICERTTYPE\fP\ |\ \fB\-\-type=\fP\fICERTTYPE\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-A\fP\ \fIUSERNAME:PASSWORD\fP\ |\ \fB–auth=\fP\fIUSERNAME:PASSWORD\fP]
+[\fB\-C\fP\ |\ \fB–connection\-close\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-k\fP\ \fIKEYFILE\fP\ |\ \fB–key=\fP\fIKEYFILE\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–log=\fP\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP\fIFILENAME\fP]
+[\fB\-p\fP\ \fIKEYFILEPASSPHRASE\fP\ |\ \fB–pass=\fP\fIKEYFILEPASSPHRASE\fP]
+[\fB\-t\fP\ \fICERTTYPE\fP\ |\ \fB–type=\fP\fICERTTYPE\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBsync\-httpd\fP is a command\-line tool to provide the Sync HTTP interface.
@@ -50,32 +50,32 @@ sync-httpd \- provide the Sync HTTP interface
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-A\fP \fIUSERNAME:PASSWORD\fP | \fB\-\-auth=\fP\fIUSERNAME:PASSWORD\fP
+\fB\-A\fP \fIUSERNAME:PASSWORD\fP | \fB–auth=\fP\fIUSERNAME:PASSWORD\fP
 Use the given \fIUSERNAME\fP and \fIPASSWORD\fP for client authentication.
 .TP
-\fB\-C\fP | \fB\-\-connection\-close\fP
+\fB\-C\fP | \fB–connection\-close\fP
 Force HTTP connections to be closed after each request.
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the Sync commands
 to operate from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-k\fP \fIKEYFILE\fP | \fB\-\-key=\fP\fIKEYFILE\fP
+\fB\-k\fP \fIKEYFILE\fP | \fB–key=\fP\fIKEYFILE\fP
 Consult \fIKEYFILE\fP for the private TLS key for TLS client authentication.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-log=\fP\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–log=\fP\fILOGLEVEL\fP
 Configure logging to use \fILOGLEVEL\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP\fIFILENAME\fP
 Configure logging to write logs to \fIFILENAME\fP\&.
 .TP
-\fB\-p\fP \fIKEYFILEPASSPHRASE\fP | \fB\-\-pass=\fP\fIKEYFILEPASSPHRASE\fP
+\fB\-p\fP \fIKEYFILEPASSPHRASE\fP | \fB–pass=\fP\fIKEYFILEPASSPHRASE\fP
 Use \fIKEYFILEPASSPHRASE\fP to decrypt the TLS client private key file.
 .TP
-\fB\-t\fP \fICERTTYPE\fP | \fB\-\-type=\fP\fICERTTYPE\fP
+\fB\-t\fP \fICERTTYPE\fP | \fB–type=\fP\fICERTTYPE\fP
 Use \fICERTTYPE\fP as the type of the TLS client certificate.
 If unspecified, defaults to PEM.
 .TP
diff --git a/man/sync.conf.5 b/man/sync.conf.5
index 00ba0f70..03e231e0 100644
--- a/man/sync.conf.5
+++ b/man/sync.conf.5
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "SYNC.CONF" "5" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "SYNC.CONF" "5" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 sync.conf \- Sync configuration file
 .SH DESCRIPTION
diff --git a/man/taler-aggregator-benchmark.1 b/man/taler-aggregator-benchmark.1
index 1e164bce..afca6062 100644
--- a/man/taler-aggregator-benchmark.1
+++ b/man/taler-aggregator-benchmark.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-AGGREGATOR-BENCHMARK" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-AGGREGATOR-BENCHMARK" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-aggregator-benchmark \- generate database to measure aggregator performance
 .SH SYNOPSIS
 .sp
 \fBtaler\-aggregator\-benchmark\fP
-[\fB\-c\fP\ \fICONFIG_FILENAME\fP\ |\ \fB\-\-config=\fP‌\fICONFIG_FILENAME\fP]
-[\fB\-d\fP\ \fIDN\fP\ |\ \fB\-\-deposits=\fP\fIDN\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-log\-level=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIDM\fP\ |\ \fB\-\-merchants=\fP‌\fIDM\fP]
-[\fB\-r\fP\ \fIRATE\fP\ |\ \fB\-\-refunds=\fP\fIRATE\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fICONFIG_FILENAME\fP\ |\ \fB–config=\fP‌\fICONFIG_FILENAME\fP]
+[\fB\-d\fP\ \fIDN\fP\ |\ \fB–deposits=\fP\fIDN\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–log\-level=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIDM\fP\ |\ \fB–merchants=\fP‌\fIDM\fP]
+[\fB\-r\fP\ \fIRATE\fP\ |\ \fB–refunds=\fP\fIRATE\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-aggregator\-benchmark\fP is a command\-line tool to fill an exchange
@@ -51,30 +51,30 @@ starting multiple \fBtaler\-exchange\-aggregator\fP processes) and instead only
 prepares the database with synthetic work.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fICONFIG_FILENAME\fP | \fB\-\-config=\fP‌\fICONFIG_FILENAME\fP
+\fB\-c\fP \fICONFIG_FILENAME\fP | \fB–config=\fP‌\fICONFIG_FILENAME\fP
 (Mandatory) Use CONFIG_FILENAME as the name for the configuration file.
 .TP
-\fB\-d\fP \fIDN\fP | \fB\-\-deposits=\fP‌\fIDN\fP
+\fB\-d\fP \fIDN\fP | \fB–deposits=\fP‌\fIDN\fP
 How many deposits should be instantiated \fIper merchant\fP\&.
 Defaults to 1.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Prints a compiled\-in help text.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-log\-level=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–log\-level=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIDM\fP | \fB\-\-merchants=\fP‌\fIDM\fP
+\fB\-m\fP \fIDM\fP | \fB–merchants=\fP‌\fIDM\fP
 How many different merchants should we create. Defaults to 1.
 .TP
-\fB\-r\fP \fIRATE\fP | \fB\-\-refunds=\fP\fIRATE\fP
+\fB\-r\fP \fIRATE\fP | \fB–refunds=\fP\fIRATE\fP
 Probability of a deposit having a refund (as an integer between 0\-100).
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-auditor-dbconfig.1 b/man/taler-auditor-dbconfig.1
index b8eac769..fad98b31 100644
--- a/man/taler-auditor-dbconfig.1
+++ b/man/taler-auditor-dbconfig.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-AUDITOR-DBCONFIG" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-AUDITOR-DBCONFIG" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-auditor-dbconfig \- configure Taler auditor database
 .SH SYNOPSIS
diff --git a/man/taler-auditor-dbinit.1 b/man/taler-auditor-dbinit.1
index 028baf65..28d99947 100644
--- a/man/taler-auditor-dbinit.1
+++ b/man/taler-auditor-dbinit.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-AUDITOR-DBINIT" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-AUDITOR-DBINIT" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-auditor-dbinit \- setup auditor database
 .SH SYNOPSIS
 .sp
 \fBtaler\-auditor\-dbinit\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-g\fP\ |\ \fB\-\-gc\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-R\fP\ |\ \fB\-\-reset\fP]
-[\fB\-r\fP\ |\ \fB\-\-restart\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-g\fP\ |\ \fB–gc\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-R\fP\ |\ \fB–reset\fP]
+[\fB\-r\fP\ |\ \fB–restart\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-dbinit\fP is a command\-line tool to initialize the Taler
@@ -50,32 +50,32 @@ Taler exchange to operate.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-g\fP | \fB\-\-gc\fP
+\fB\-g\fP | \fB–gc\fP
 Garbage collect database. Deletes all unnecessary data in the
 database.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-R\fP | \fB\-\-reset\fP
+\fB\-R\fP | \fB–reset\fP
 Drop tables. Dangerous, will delete all existing data in the database.
 .TP
-\fB\-r\fP | \fB\-\-restart\fP
+\fB\-r\fP | \fB–restart\fP
 Restart all auditors from the beginning. Useful for
 testing.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-auditor-exchange.1 b/man/taler-auditor-exchange.1
index 057d0005..a9851b10 100644
--- a/man/taler-auditor-exchange.1
+++ b/man/taler-auditor-exchange.1
@@ -27,18 +27,18 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-AUDITOR-EXCHANGE" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-AUDITOR-EXCHANGE" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-auditor-exchange \- add or remove exchange from auditor’s list
 .SH SYNOPSIS
 .sp
 \fBtaler\-auditor\-exchange\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-m\fP\ \fIMASTERKEY\fP\ |\ \fB\-\-exchange\-key=\fP‌\fIMASTERKEY\fP]
-[\fB\-r\fP\ |\ \fB\-\-remove\fP]
-[\fB\-u\fP\ \fIEXCHANGE_URL\fP\ |\ \fB\-\-auditor\-url=\fP‌\fIEXCHANGE_URL\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-m\fP\ \fIMASTERKEY\fP\ |\ \fB–exchange\-key=\fP‌\fIMASTERKEY\fP]
+[\fB\-r\fP\ |\ \fB–remove\fP]
+[\fB\-u\fP\ \fIEXCHANGE_URL\fP\ |\ \fB–auditor\-url=\fP‌\fIEXCHANGE_URL\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-auditor\-exchange\fP is a command\-line tool to be used by an
@@ -49,27 +49,27 @@ taler\-auditor or taler\-wire\-auditor. Afterwards the exchange will be
 visible via the /exchanges API of the taler\-auditor\-httpd.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-m\fP \fIMASTERKEY\fP | \fB\-\-exchange\-key=\fP‌\fIMASTERKEY\fP
+\fB\-m\fP \fIMASTERKEY\fP | \fB–exchange\-key=\fP‌\fIMASTERKEY\fP
 Public key of the exchange in Crockford base32 encoding, for example
 as generated by \fBtaler\-auditor\-offline setup\fP\&.
 .TP
-\fB\-r\fP | \fB\-\-remove\fP
+\fB\-r\fP | \fB–remove\fP
 Instead of adding the exchange, remove it. Note that this will drop
 ALL data associated with that exchange, including existing auditing
 information. So use with extreme care!
 .TP
-\fB\-u\fP \fIEXCHANGE_URL\fP | \fB\-\-auditor\-url=\fP‌\fIEXCHANGE_URL\fP
+\fB\-u\fP \fIEXCHANGE_URL\fP | \fB–auditor\-url=\fP‌\fIEXCHANGE_URL\fP
 URL of the exchange. The exchange’s HTTP API must be available at
 this address.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH DIAGNOSTICS
diff --git a/man/taler-auditor-httpd.1 b/man/taler-auditor-httpd.1
index 3beef382..106aa510 100644
--- a/man/taler-auditor-httpd.1
+++ b/man/taler-auditor-httpd.1
@@ -27,19 +27,19 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-AUDITOR-HTTPD" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-AUDITOR-HTTPD" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-auditor-httpd \- HTTP server providing a RESTful API to access a Taler auditor
 .SH SYNOPSIS
 .sp
 \fBtaler\-auditor\-httpd\fP
-[\fB\-C\fP\ |\ \fB\-\-connection\-close\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-t\fP\ \fISECONDS\fP\ |\ \fB\-\-timeout\fP\fISECONDS\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-C\fP\ |\ \fB–connection\-close\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-t\fP\ \fISECONDS\fP\ |\ \fB–timeout\fP\fISECONDS\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-auditor\-httpd\fP is a command\-line tool to run the Taler auditor
@@ -48,30 +48,30 @@ before running this command.
 .SH OPTIONS
 .INDENT 0.0
 .TP
-\fB\-C\fP | \fB\-\-connection\-close\fP
+\fB\-C\fP | \fB–connection\-close\fP
 Force each HTTP connection to be closed after each request
 (useful in combination with \-f to avoid having to wait for nc to
 time out).
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP\fIFILENAME\fP
 Use the configuration and other resources for the auditor to
 operate from FILENAME.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-t\fP \fISECONDS\fP | \fB\-\-timeout=\fP\fISECONDS\fP
+\fB\-t\fP \fISECONDS\fP | \fB–timeout=\fP\fISECONDS\fP
 Specifies the number of \fISECONDS\fP after which the HTTPD should close
 (idle) HTTP connections.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SIGNALS
diff --git a/man/taler-auditor-offline.1 b/man/taler-auditor-offline.1
index c7edc072..3b593fdd 100644
--- a/man/taler-auditor-offline.1
+++ b/man/taler-auditor-offline.1
@@ -27,18 +27,18 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-AUDITOR-OFFLINE" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-AUDITOR-OFFLINE" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-auditor-offline \- Taler auditor certifies that it audits a Taler exchange
 .SH SYNOPSIS
 .sp
 \fBtaler\-auditor\-offline\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
-[subcommand ...]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
+[subcommand …]
 .SH DESCRIPTION
 .sp
 \fBtaler\-auditor\-offline\fP is a command\-line tool to be used by an auditor to
@@ -47,7 +47,7 @@ signature, the auditor affirms that he will verify that the exchange is
 properly accounting for coins of those denominations.  The tool takes a list
 of subcommands as arguments which are then processed sequentially.
 .sp
-The tool includes two subcommands to interact \fIonline\fP with the exchange\(aqs
+The tool includes two subcommands to interact \fIonline\fP with the exchange’s
 REST APIs.  The \fBdownload\fP subcommand downloads current public keys from the
 running exchange.  Note that this only includes keys that the exchange
 operator has previously validated using the \fBtaler\-exchange\-offline\fP tool.
@@ -55,10 +55,10 @@ The resulting data serves as input to the \fBsign\fP and \fBshow\fP subcommands.
 .sp
 The \fBupload\fP subcommand uploads the signatures created with the private key to
 the exchange.  It handles the output of all subcommands (except \fBdownload\fP).
-The \fBdownload\fP and \fBupload\fP subcommands must naturally be run \(dqonline\(dq and do not
-require access to the auditor\(aqs private key, which should be kept offline.
+The \fBdownload\fP and \fBupload\fP subcommands must naturally be run “online” and do not
+require access to the auditor’s private key, which should be kept offline.
 .sp
-All other subcommands are intended to be run \(dqoffline\(dq. However, especially
+All other subcommands are intended to be run “offline”. However, especially
 when testing, it is of course possible to run the subcommands online as well.
 Generally, subcommands read inputs (beyond command\-line arguments)
 from \fBstdin\fP\&. However, they may also consume outputs of previous
@@ -68,28 +68,28 @@ and if not consumed the final output is printed to \fBstdout\fP\&.
 The general options for \fBtaler\-auditor\-offline\fP are:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH CONFIGURATION
 .sp
 The exchange and the \fBtaler\-auditor\-httpd\fP must both be provided with
-the auditor\(aqs public key, such that they can validate messages signed
-by the auditor. To obtain the auditor\(aqs public key, use:
+the auditor’s public key, such that they can validate messages signed
+by the auditor. To obtain the auditor’s public key, use:
 .INDENT 0.0
 .INDENT 3.5
 .sp
@@ -102,13 +102,13 @@ $ taler\-auditor\-offline setup
 .UNINDENT
 .sp
 Note that if the private key file already exists, the above will simply output
-the existing key.  Passing additional arguments after setup (including \(dq\-\(dq)
+the existing key.  Passing additional arguments after setup (including “\-“)
 will cause the output to be encapsulated in JSON.
 .sp
 Relevant configuration options for \fBtaler\-auditor\-offline\fP are:
 .INDENT 0.0
 .IP \(bu 2
-\fB[auditor/AUDITOR_PRIV_FILE]\fP \-\-\- where to store the private key
+\fB[auditor/AUDITOR_PRIV_FILE]\fP — where to store the private key
 .UNINDENT
 .SH SUBCOMMANDS
 .SS setup
diff --git a/man/taler-auditor-sync.1 b/man/taler-auditor-sync.1
index 0c4ba633..129a3e03 100644
--- a/man/taler-auditor-sync.1
+++ b/man/taler-auditor-sync.1
@@ -27,23 +27,23 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-AUDITOR-SYNC" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-AUDITOR-SYNC" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-auditor-sync \- tool to safely synchronize auditor database
 .SH SYNOPSIS
 .sp
 \fBtaler\-auditor\-sync\fP
-[\fB\-s\fP\ \fIFILENAME\fP\ |\ \fB\-\-source\-configuration=\fP‌\fIFILENAME\fP]
-[\fB\-d\fP\ \fIFILENAME\fP\ |\ \fB\-\-destination\-configuration=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-b\fP\ \fISIZE\fP\ |\ \fB\-\-batch=\fP‌\fISIZE\fP]
-[\fB\-t\fP\ |\ \fB\-\-terminate\-when\-synchronized\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-s\fP\ \fIFILENAME\fP\ |\ \fB–source\-configuration=\fP‌\fIFILENAME\fP]
+[\fB\-d\fP\ \fIFILENAME\fP\ |\ \fB–destination\-configuration=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-b\fP\ \fISIZE\fP\ |\ \fB–batch=\fP‌\fISIZE\fP]
+[\fB\-t\fP\ |\ \fB–terminate\-when\-synchronized\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-auditor\-sync\fP is a command\-line tool to synchronize the
-Taler auditor\(aqs database in a safe way from a Taler exchange
+Taler auditor’s database in a safe way from a Taler exchange
 database. If the exchange database violates the assumed database
 invariants (as expressed by database constraints) or attempts to
 DELETE or UPDATE tables (at least those that the auditor relies
@@ -53,31 +53,31 @@ and instead halt with an error.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-s\fP \fIFILENAME\fP | \fB\-\-source\-configuration=\fP‌\fIFILENAME\fP
+\fB\-s\fP \fIFILENAME\fP | \fB–source\-configuration=\fP‌\fIFILENAME\fP
 Use the configuration in \fIFILENAME\fP to access the original (source) exchange
 database to copy records from.
 .TP
-\fB\-d\fP \fIFILENAME\fP | \fB\-\-destination\-configuration=\fP‌\fIFILENAME\fP
+\fB\-d\fP \fIFILENAME\fP | \fB–destination\-configuration=\fP‌\fIFILENAME\fP
 Use the configuration in \fIFILENAME\fP to access the target (destination) exchange
 database to copy records to.
 .TP
-\fB\-t\fP | \fB\-\-terminate\-when\-synchronized\fP
+\fB\-t\fP | \fB–terminate\-when\-synchronized\fP
 The program should exit once the two databases are in sync, instead of continuously
 copying more records when the source database is updated.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-b\fP \fISIZE\fP | \fB\-\-batch=\fP‌\fISIZE\fP
+\fB\-b\fP \fISIZE\fP | \fB–batch=\fP‌\fISIZE\fP
 Target number of records to copy in one transaction. Once the databases are
 in sync, the batch size is used to determine how long the process sleeps before
 trying to again synchronize the two databases. Not useful if \fB\-t\fP is used.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-auditor.1 b/man/taler-auditor.1
index 0748a605..cb0f4f6a 100644
--- a/man/taler-auditor.1
+++ b/man/taler-auditor.1
@@ -27,21 +27,21 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-AUDITOR" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-AUDITOR" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-auditor \- audit exchange
 .SH SYNOPSIS
 .sp
 \fBtaler\-auditor\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-i**_|_\fP\-\-internal**]
-[\fB\-I**_|_\fP\-\-ignore\-not\-found**]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIMASTER_KEY\fP\ |\ \fB\-\-exchange\-key=\fP‌\fIMASTER_KEY\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel\fP\fIUSEC\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-i**_|_\fP–internal**]
+[\fB\-I**_|_\fP–ignore\-not\-found**]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIMASTER_KEY\fP\ |\ \fB–exchange\-key=\fP‌\fIMASTER_KEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-auditor\fP is a command\-line tool to be used by an auditor to
@@ -55,40 +55,40 @@ incoming and outgoing wire transfers that the bank claims to have
 matches the exchange’s database. Its options are as follows.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-i\fP | \fB\-\-internal\fP
+\fB\-i\fP | \fB–internal\fP
 Run additional checks that can only performed on the exchange\-internal
-database and not the \(dqsafe\(dq replicated database at the auditor.
+database and not the “safe” replicated database at the auditor.
 .TP
-\fB\-I\fP | \fB\-\-ignore\-not\-found\fP
+\fB\-I\fP | \fB–ignore\-not\-found\fP
 Do not fail if the bank says that the exchange bank account does not (yet) exist.
 Keep trying.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIKEY\fP | \fB\-\-exchange\-key=\fP‌\fIKEY\fP
+\fB\-m\fP \fIKEY\fP | \fB–exchange\-key=\fP‌\fIKEY\fP
 Public master key of the exchange in Crockford base32 encoding, for
 example as generated by \fBtaler\-auditor\-offline setup\fP\&. If this option is missing,
 taler\-auditor will use the MASTER_PUBLIC_KEY value from the
 “exchange” section of the configuration.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-bank-benchmark.1 b/man/taler-bank-benchmark.1
index 9ec8a1ee..ee1c9706 100644
--- a/man/taler-bank-benchmark.1
+++ b/man/taler-bank-benchmark.1
@@ -27,68 +27,68 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-BANK-BENCHMARK" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-BANK-BENCHMARK" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-bank-benchmark \- measure bank performance
 .SH SYNOPSIS
 .sp
 \fBtaler\-bank\-benchmark\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-f\fP\ |\ \fB\-\-fakebank\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-p\fP\ \fINPROCS\fP\ |\ \fB\-\-worker\-parallelism=\fP\fINPROCS\fP]
-[\fB\-r\fP\ \fINRESERVES\fP\ |\ \fB\-\-reserves=\fP\fINRESERVES\fP]
-[\fB\-u\fP\ \fISECTION\fP\ |\ \fB\-\-exchange\-account\-section=\fP\fISECTION\fP]
-[\fB\-V\fP\ |\ \fB\-\-verbose\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
-[\fB\-w**_*NPROC*\ |\ **\-\-wirewatch=\fP\fINPROC\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-f\fP\ |\ \fB–fakebank\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-p\fP\ \fINPROCS\fP\ |\ \fB–worker\-parallelism=\fP\fINPROCS\fP]
+[\fB\-r\fP\ \fINRESERVES\fP\ |\ \fB–reserves=\fP\fINRESERVES\fP]
+[\fB\-u\fP\ \fISECTION\fP\ |\ \fB–exchange\-account\-section=\fP\fISECTION\fP]
+[\fB\-V\fP\ |\ \fB–verbose\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
+[\fB\-w**_*NPROC*\ |\ **–wirewatch=\fP\fINPROC\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-bank\-benchmark\fP is a command\-line tool to benchmark only the \(dqbank\(dq
+\fBtaler\-bank\-benchmark\fP is a command\-line tool to benchmark only the “bank”
 and the \fBtaler\-exchange\-wirewatch\fP tool.
 .sp
 The options for \fBtaler\-bank\-benchmark\fP are:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-f\fP | \fB\-\-fakebank\fP
+\fB\-f\fP | \fB–fakebank\fP
 Expect to be run against a fakebank (instead of against libeufin)
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIMODE\fP | \fB\-\-mode=\fP\fIMODE\fP
+\fB\-m\fP \fIMODE\fP | \fB–mode=\fP\fIMODE\fP
 Run as \fBbank\fP, \fBclient\fP or \fBboth\fP\&.
 If unspecified, \fIMODE\fP defaults to \fBboth\fP\&.
 .TP
-\fB\-p\fP \fINPROCS\fP | \fB\-\-worker\-parallelism=\fP\fINPROCS\fP
+\fB\-p\fP \fINPROCS\fP | \fB–worker\-parallelism=\fP\fINPROCS\fP
 Run with \fINPROCS\fP client processes.
 .TP
-\fB\-r\fP \fINRESERVES\fP | \fB\-\-reserves=\fP\fINRESERVES\fP
+\fB\-r\fP \fINRESERVES\fP | \fB–reserves=\fP\fINRESERVES\fP
 Create \fINRESERVES\fP reserves per client.
 .TP
-\fB\-u\fP \fISECTION\fP | \fB\-\-exchange\-account\-section=\fP\fISECTION\fP
+\fB\-u\fP \fISECTION\fP | \fB–exchange\-account\-section=\fP\fISECTION\fP
 Use \fISECTION\fP as the name of the configuration section which specifies the exchange bank account.
 .TP
-\fB\-V\fP | \fB\-\-verbose\fP
+\fB\-V\fP | \fB–verbose\fP
 Display more output than usual.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .TP
-\fB\-w\fP \fINPROC\fP | \fB\-\-wirewatch=\fP\fINPROC\fP
+\fB\-w\fP \fINPROC\fP | \fB–wirewatch=\fP\fINPROC\fP
 Run \fINPROC\fP processes of the \fBtaler\-exchange\-wirewatch\fP tool.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-config.1 b/man/taler-config.1
index 4392c3cf..b790bdc2 100644
--- a/man/taler-config.1
+++ b/man/taler-config.1
@@ -27,75 +27,75 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-CONFIG" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-CONFIG" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-config \- Taler configuration inspection and editing
 .SH SYNOPSIS
 .sp
 \fBtaler\-config\fP
-[\fB\-b\fP\ \fIbackend\fP\ |\ \fB\-\-supported\-backend=\fP\fIbackend\fP]
-[\fB\-c\fP\ \fIfilename\fP\ |\ \fB\-\-config=\fP\fIfilename\fP]
-[\fB\-f\fP\ |\ \fB\-\-filename\fP]
-[\fB\-F\fP\ |\ \fB\-\-full\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fIloglevel\fP\ |\ \fB\-\-loglevel=\fP\fIloglevel\fP]
-[\fB\-l\fP\ \fIfilename\fP\ |\ \fB\-\-logfile=\fP‌\fIfilename\fP]
-[\fB\-o\fP\ \fIoption\fP\ |\ \fB\-\-option=\fP\fIoption\fP]
-[\fB\-r\fP\ |\ \fB\-\-rewrite\fP]
-[\fB\-S\fP\ |\ \fB\-\-list\-sections\fP]
-[\fB\-s\fP\ \fIsection\fP\ |\ \fB\-\-section=\fP\fIsection\fP]
-[\fB\-V\fP\ \fIvalue\fP\ |\ \fB\-\-value=\fP\fIvalue\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-b\fP\ \fIbackend\fP\ |\ \fB–supported\-backend=\fP\fIbackend\fP]
+[\fB\-c\fP\ \fIfilename\fP\ |\ \fB–config=\fP\fIfilename\fP]
+[\fB\-f\fP\ |\ \fB–filename\fP]
+[\fB\-F\fP\ |\ \fB–full\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fIloglevel\fP\ |\ \fB–loglevel=\fP\fIloglevel\fP]
+[\fB\-l\fP\ \fIfilename\fP\ |\ \fB–logfile=\fP‌\fIfilename\fP]
+[\fB\-o\fP\ \fIoption\fP\ |\ \fB–option=\fP\fIoption\fP]
+[\fB\-r\fP\ |\ \fB–rewrite\fP]
+[\fB\-S\fP\ |\ \fB–list\-sections\fP]
+[\fB\-s\fP\ \fIsection\fP\ |\ \fB–section=\fP\fIsection\fP]
+[\fB\-V\fP\ \fIvalue\fP\ |\ \fB–value=\fP\fIvalue\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-config\fP can be used to read or modify GNU Taler configuration files.
 .INDENT 0.0
 .TP
-\fB\-b\fP \fIBACKEND\fP | \fB\-\-supported\-backend=\fP\fIBACKEND\fP
+\fB\-b\fP \fIBACKEND\fP | \fB–supported\-backend=\fP\fIBACKEND\fP
 Tests whether the specified \fIBACKEND\fP is supported by the current installation.
-The backend must match the name of a plugin, i.e. \(dqnamestore_postgres\(dq for
-the PostgreSQL database backend of the \(dqNAMESTORE\(dq service.  If \fIBACKEND\fP is
+The backend must match the name of a plugin, i.e. “namestore_postgres” for
+the PostgreSQL database backend of the “NAMESTORE” service.  If \fIBACKEND\fP is
 supported, taler\-config will return a status code of 0 (success), otherwise
 77 (unsupported).  When this option is specified, no other options may be
 specified. Specifying this option together with other options will cause
 taler\-config to return a status code of 1 (error).
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP\fIFILENAME\fP
 Use the configuration file \fIFILENAME\fP\&.
 .TP
-\fB\-f\fP | \fB\-\-filename\fP
+\fB\-f\fP | \fB–filename\fP
 Try to perform expansions as if the option values represent filenames (will
 also be applied even if the option is not really a filename).
 .TP
-\fB\-F\fP | \fB\-\-full\fP
+\fB\-F\fP | \fB–full\fP
 Write the full configuration file, not just the differences to the defaults.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP\fILOGLEVEL\fP
 Use \fILOGLEVEL\fP for logging.
 Valid values are \fBDEBUG\fP, \fBINFO\fP, \fBWARNING\fP, and \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-o\fP \fIOPTION\fP | \fB\-\-option=\fP\fIOPTION\fP
+\fB\-o\fP \fIOPTION\fP | \fB–option=\fP\fIOPTION\fP
 Which configuration option should be accessed or edited.  Required to set a
 value.  If not given, all values of a given section will be printed in the
-format \(dqOPTION = VALUE\(dq.
+format “OPTION = VALUE”.
 .TP
-\fB\-r\fP | \fB\-\-rewrite\fP
+\fB\-r\fP | \fB–rewrite\fP
 Write the configuration file even if nothing changed. Will remove all comments!
 .TP
-\fB\-S\fP | \fB\-\-list\-sections\fP
+\fB\-S\fP | \fB–list\-sections\fP
 List available configuration sections for use with \fB\-\-section\fP\&.
 .TP
-\fB\-s\fP \fISECTION\fP | \fB\-\-section=\fP\fISECTION\fP
+\fB\-s\fP \fISECTION\fP | \fB–section=\fP\fISECTION\fP
 Which configuration section should be accessed or edited.
 Required option.
 .TP
-\fB\-V\fP \fIVALUE\fP | \fB\-\-value=\fP\fIVALUE\fP
+\fB\-V\fP \fIVALUE\fP | \fB–value=\fP\fIVALUE\fP
 Configuration value to store in the given section under the given option.
 Must only be given together with \fB\-s\fP and \fB\-o\fP options.
 .INDENT 7.0
@@ -105,7 +105,7 @@ Changing the configuration file with \fB\-V\fP will remove comments
 and may reorder sections and remove \fB@INLINE@\fP directives.
 .UNINDENT
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print GNU Taler version number.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-aggregator.1 b/man/taler-exchange-aggregator.1
index 5ac39acc..9367bd8b 100644
--- a/man/taler-exchange-aggregator.1
+++ b/man/taler-exchange-aggregator.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-AGGREGATOR" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-AGGREGATOR" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-aggregator \- aggregate deposits into wire transfers
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-aggregator\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel\fP\fIUSEC\fP]
-[\fB\-t\fP\ |\ \fB\-\-test\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
-[\fB\-y**_|_\fP\-\-kyc\-off**]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel\fP\fIUSEC\fP]
+[\fB\-t\fP\ |\ \fB–test\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
+[\fB\-y**_|_\fP–kyc\-off**]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-aggregator\fP is a command\-line tool to run aggregate deposits
@@ -49,35 +49,35 @@ done by \fBtaler\-exchange\-transfer\fP\&.
 .sp
 The AGGREGATOR_SHARD_SIZE option can be used to allow multiple aggregator processes to run in parallel and share the load. This is only recommended if a single aggregator is insufficient for the workload.
 .sp
-The aggregator uses a special table to lock shards it is working on. If an aggregator process dies (say due to a power failure), these shard locks may prevent the aggregator from resuming normally. In this case, you must run \(dqtaler\-exchange\-dbinit \-s\(dq to release the shard locks before restarting the aggregator.
+The aggregator uses a special table to lock shards it is working on. If an aggregator process dies (say due to a power failure), these shard locks may prevent the aggregator from resuming normally. In this case, you must run “taler\-exchange\-dbinit \-s” to release the shard locks before restarting the aggregator.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-t\fP | \fB–test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .TP
-\fB\-y\fP | \fB\-\-kyc\-off\fP
+\fB\-y\fP | \fB–kyc\-off\fP
 Run without KYC checks. Talk with your regulator before using this option.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-benchmark.1 b/man/taler-exchange-benchmark.1
index f8a34e0b..6b3e885c 100644
--- a/man/taler-exchange-benchmark.1
+++ b/man/taler-exchange-benchmark.1
@@ -27,24 +27,24 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-BENCHMARK" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-BENCHMARK" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-benchmark \- measure exchange performance
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-benchmark\fP
-[\fB\-c\fP\ \fICONFIG_FILENAME\fP\ |\ \fB\-\-config=\fP‌\fICONFIG_FILENAME\fP]
-[\fB\-F\fP\ |\ \fB\-\-reserves\-first\fP]
-[\fB\-f\fP\ |\ \fB\-\-fakebank\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-log\-level=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-n\fP\ \fIHOWMANY_COINS\fP\ |\ \fB\-\-coins\-number=\fP‌\fIHOWMANY_COINS\fP]
-[\fB\-p\fP\ \fINPROCS\fP\ |\ \fB\-\-parallelism=\fP\fINPROCS\fP]
-[\fB\-R\fP\ \fIRATE\fP\ |\ \fB\-\-refresh\-rate=\fP\fIRATE\fP]
-[\fB\-r\fP\ \fIN\fP\ |\ \fB\-\-reserves=\fP\fIN\fP]
-[\fB\-u\fP\ \fISECTION\fP\ |\ \fB\-\-exchange\-account\-section=\fP\fISECTION\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fICONFIG_FILENAME\fP\ |\ \fB–config=\fP‌\fICONFIG_FILENAME\fP]
+[\fB\-F\fP\ |\ \fB–reserves\-first\fP]
+[\fB\-f\fP\ |\ \fB–fakebank\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–log\-level=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-n\fP\ \fIHOWMANY_COINS\fP\ |\ \fB–coins\-number=\fP‌\fIHOWMANY_COINS\fP]
+[\fB\-p\fP\ \fINPROCS\fP\ |\ \fB–parallelism=\fP\fINPROCS\fP]
+[\fB\-R\fP\ \fIRATE\fP\ |\ \fB–refresh\-rate=\fP\fIRATE\fP]
+[\fB\-r\fP\ \fIN\fP\ |\ \fB–reserves=\fP\fIN\fP]
+[\fB\-u\fP\ \fISECTION\fP\ |\ \fB–exchange\-account\-section=\fP\fISECTION\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-benchmark\fP is a command\-line tool to measure the time
@@ -52,44 +52,44 @@ spent to serve withdrawals/deposits/refreshes.  Before running the benchmark,
 the GNU Taler services must already be running at the configured addresses.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fICONFIG_FILENAME\fP | \fB\-\-config=\fP‌\fICONFIG_FILENAME\fP
+\fB\-c\fP \fICONFIG_FILENAME\fP | \fB–config=\fP‌\fICONFIG_FILENAME\fP
 (Mandatory) Use CONFIG_FILENAME.
 .TP
-\fB\-F\fP | \fB\-\-reserves\-first\fP
+\fB\-F\fP | \fB–reserves\-first\fP
 Create all reserves first, before starting normal operations.
 .TP
-\fB\-f\fP | \fB\-\-fakebank\fP
+\fB\-f\fP | \fB–fakebank\fP
 Expect to interact with a fakebank instead of libeufin.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Prints a compiled\-in help text.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-log\-level=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–log\-level=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-n\fP \fIHOWMANY_COINS\fP | \fB\-\-coins\-number=\fP‌\fIHOWMANY_COINS\fP
+\fB\-n\fP \fIHOWMANY_COINS\fP | \fB–coins\-number=\fP‌\fIHOWMANY_COINS\fP
 Defaults to 1. Specifies how many coins this benchmark should
 withdraw and spend. After being spent, each coin will be refreshed
 with a probability RATE (see option \fB\-\-refresh\-rate\fP).
 .TP
-\fB\-p\fP \fINPROCS\fP | \fB\-\-parallelism=\fP\fINPROCS\fP
+\fB\-p\fP \fINPROCS\fP | \fB–parallelism=\fP\fINPROCS\fP
 Run with \fINPROCS\fP client processes.
 .TP
-\fB\-R\fP \fIRATE\fP | \fB\-\-refresh\-rate=\fP\fIRATE\fP
+\fB\-R\fP \fIRATE\fP | \fB–refresh\-rate=\fP\fIRATE\fP
 Defaults to 10.  Probability of refresh per coin (0\-100).
 .TP
-\fB\-r\fP \fIN\fP | \fB\-\-reserves=\fP\fIN\fP
+\fB\-r\fP \fIN\fP | \fB–reserves=\fP\fIN\fP
 Create \fIN\fP reserves per client.
 .TP
-\fB\-u\fP \fISECTION\fP | \fB\-\-exchange\-account\-section=\fP\fISECTION\fP
+\fB\-u\fP \fISECTION\fP | \fB–exchange\-account\-section=\fP\fISECTION\fP
 Which configuration section should be used for the bank account
 of the exchange.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-closer.1 b/man/taler-exchange-closer.1
index 2d032074..98a12c05 100644
--- a/man/taler-exchange-closer.1
+++ b/man/taler-exchange-closer.1
@@ -27,19 +27,19 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-CLOSER" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-CLOSER" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-closer \- close idle reserves
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-closer\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-t\fP\ |\ \fB\-\-test\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ |\ \fB–test\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-closer\fP is a command\-line tool to run close
@@ -47,29 +47,29 @@ reserves that have been idle for too long, causing transfers
 to the originating bank account to be scheduled.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-t\fP | \fB–test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-dbconfig.1 b/man/taler-exchange-dbconfig.1
index 7704c920..40460d42 100644
--- a/man/taler-exchange-dbconfig.1
+++ b/man/taler-exchange-dbconfig.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-DBCONFIG" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-DBCONFIG" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-dbconfig \- configure Taler exchange database
 .SH SYNOPSIS
diff --git a/man/taler-exchange-dbinit.1 b/man/taler-exchange-dbinit.1
index bc0a5014..73785391 100644
--- a/man/taler-exchange-dbinit.1
+++ b/man/taler-exchange-dbinit.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-DBINIT" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-DBINIT" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-dbinit \- initialize Taler exchange database
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-dbinit\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-g\fP\ |\ \fB\-\-gc\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-r\fP\ |\ \fB\-\-reset\fP]
-[\fB\-s\fP\ |\ \fB\-\-shardunlock\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-g\fP\ |\ \fB–gc\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-r\fP\ |\ \fB–reset\fP]
+[\fB\-s\fP\ |\ \fB–shardunlock\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-dbinit\fP is a command\-line tool to initialize the Taler
@@ -50,29 +50,29 @@ Taler exchange to operate.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-g\fP | \fB\-\-gc\fP
+\fB\-g\fP | \fB–gc\fP
 Garbage collect database. Deletes all unnecessary data in the
 database.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-r\fP | \fB\-\-reset\fP
+\fB\-r\fP | \fB–reset\fP
 Drop tables. Dangerous, will delete all existing data in the database
 before creating the tables.
 .TP
-\fB\-s\fP | \fB\-\-shardunlock\fP
+\fB\-s\fP | \fB–shardunlock\fP
 Clears the (revolving) shards table. Needed to clear locks that may be held after a crash (of taler\-exchange\-aggregator or the operating system, say due to power outage) or if the AGGREGATOR_SHARD_SIZE option is changed in the configuration file.
 .TP
 \fB\-v\fP | \fB–version\fP
diff --git a/man/taler-exchange-drain.1 b/man/taler-exchange-drain.1
index a1366823..6ea62735 100644
--- a/man/taler-exchange-drain.1
+++ b/man/taler-exchange-drain.1
@@ -27,40 +27,40 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-DRAIN" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-DRAIN" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-drain \- drain profits from exchange
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-drain\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-drain\fP is used to trigger a wire transfer from the exchange\(aqs escrow account to a normal (non\-escrowed) bank account of the exchange.  The entire drain process is necessary to ensure that the auditor is aware of the
+\fBtaler\-exchange\-drain\fP is used to trigger a wire transfer from the exchange’s escrow account to a normal (non\-escrowed) bank account of the exchange.  The entire drain process is necessary to ensure that the auditor is aware of the
 balance changes arising from an exchange making profits from fees.
 .sp
-To use it, you must first create an upload a \(aqdrain\(aq command using \fBtaler\-exchange\-offline\fP\&. Afterwards this command should be run to actually queue the drain. The actual drain will then be executed by \fBtaler\-exchange\-transfer\fP\&.
+To use it, you must first create an upload a ‘drain’ command using \fBtaler\-exchange\-offline\fP\&. Afterwards this command should be run to actually queue the drain. The actual drain will then be executed by \fBtaler\-exchange\-transfer\fP\&.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-expire.1 b/man/taler-exchange-expire.1
index 744635ad..03a01728 100644
--- a/man/taler-exchange-expire.1
+++ b/man/taler-exchange-expire.1
@@ -27,19 +27,19 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-EXPIRE" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-EXPIRE" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-expire \- refund expired purses
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-expire\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-t\fP\ |\ \fB\-\-test\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ |\ \fB–test\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-expire\fP is a command\-line tool to run refund
@@ -48,29 +48,29 @@ This allows the wallet to recover the funds deposited into the
 purse using a refresh operation.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-t\fP | \fB–test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-httpd.1 b/man/taler-exchange-httpd.1
index cd53441f..cd2defa7 100644
--- a/man/taler-exchange-httpd.1
+++ b/man/taler-exchange-httpd.1
@@ -27,24 +27,24 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-HTTPD" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-HTTPD" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-httpd \- run Taler exchange (with RESTful API)
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-httpd\fP
-[\fB\-a\fP\ |\ \fB\-\-allow\-timetravel\fP]
-[\fB\-C\fP\ |\ \fB\-\-connection\-close\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-f\fP\ \fIFILENAME\fP\ |\ \fB\-\-file\-input=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-n\fP\ \fIN\fP\ |\ \fB\-\-num\-threads=\fP\fIN\fP]
-[\fB\-r**|\fP\-\-allow\-reuse\-address**]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-t\fP\ \fISECONDS\fP\ |\ \fB\-\-timeout=\fP‌\fISECONDS\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-a\fP\ |\ \fB–allow\-timetravel\fP]
+[\fB\-C\fP\ |\ \fB–connection\-close\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-f\fP\ \fIFILENAME\fP\ |\ \fB–file\-input=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-n\fP\ \fIN\fP\ |\ \fB–num\-threads=\fP\fIN\fP]
+[\fB\-r**|\fP–allow\-reuse\-address**]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ \fISECONDS\fP\ |\ \fB–timeout=\fP‌\fISECONDS\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-httpd\fP is a command\-line tool to run the Taler
@@ -54,24 +54,24 @@ must exist before running this command.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-a\fP | \fB\-\-allow\-timetravel\fP
+\fB\-a\fP | \fB–allow\-timetravel\fP
 Allow clients to request /keys for arbitrary timestamps.
 This should only be enabled for testing and development,
 as clients could abuse this in denial of service attacks,
 as it makes the /keys response generation much more expensive.
 .TP
-\fB\-C\fP | \fB\-\-connection\-close\fP
+\fB\-C\fP | \fB–connection\-close\fP
 Force each HTTP connection to be closed after each request (useful in
 combination with \fB\-f\fP to avoid having to wait for
 netcat (nc) to time out).
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from FILENAME.
 .TP
-\fB\-f\fP \fIFILENAME\fP | \fB\-\-file\-input=\fP‌\fIFILENAME\fP
+\fB\-f\fP \fIFILENAME\fP | \fB–file\-input=\fP‌\fIFILENAME\fP
 This option is only available if the exchange was compiled with the
-configure option \-\-enable\-developer\-mode. It is used for generating
+configure option –enable\-developer\-mode. It is used for generating
 test cases against the exchange using AFL. When this option is
 present, the HTTP server will
 .INDENT 7.0
@@ -89,31 +89,31 @@ input from an HTTP client and then immediately exit. This is useful
 to test taler\-exchange\-httpd against many different possible inputs
 in a controlled way.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-r\fP | \fB\-\-allow\-reuse\-address\fP
+\fB\-r\fP | \fB–allow\-reuse\-address\fP
 Allow the exchange to re\-use the listen port even if another service
 is already using it. Useful if multiple processes are used to increase
 processing capacity.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP \fISECONDS\fP | \fB\-\-timeout=\fP‌\fISECONDS\fP
+\fB\-t\fP \fISECONDS\fP | \fB–timeout=\fP‌\fISECONDS\fP
 Specifies the number of SECONDS after which the HTTPD should close
 (idle) HTTP connections.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SIGNALS
diff --git a/man/taler-exchange-kyc-aml-pep-trigger.1 b/man/taler-exchange-kyc-aml-pep-trigger.1
index b7bb90ad..bf60a2f3 100644
--- a/man/taler-exchange-kyc-aml-pep-trigger.1
+++ b/man/taler-exchange-kyc-aml-pep-trigger.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-KYC-AML-PEP-TRIGGER" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-KYC-AML-PEP-TRIGGER" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-kyc-aml-pep-trigger \- Taler KYC_AML_TRIGGER example
 .SH SYNOPSIS
@@ -35,7 +35,7 @@ taler-exchange-kyc-aml-pep-trigger \- Taler KYC_AML_TRIGGER example
 \fBtaler\-exchange\-kyc\-aml\-pep\-trigger\fP
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-kyc\-aml\-pep\-trigger\fP is a trivial shell script to illustrate how to trigger an AML process when the KYC process sets the \(dqPEP\(dq flag in the attribute data.
+\fBtaler\-exchange\-kyc\-aml\-pep\-trigger\fP is a trivial shell script to illustrate how to trigger an AML process when the KYC process sets the “PEP” flag in the attribute data.
 .sp
 The script is mostly an example (or starting point) for
 writing programs for the KYC_AML_TRIGGER option of the
diff --git a/man/taler-exchange-kyc-tester.1 b/man/taler-exchange-kyc-tester.1
index e4fc551f..f22b7789 100644
--- a/man/taler-exchange-kyc-tester.1
+++ b/man/taler-exchange-kyc-tester.1
@@ -27,24 +27,24 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-KYC-TESTER" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-KYC-TESTER" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-kyc-tester \- test KYC service integration
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-kyc\-tester\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-i\fP\ \fISECTION_NAME\fP\ |\ \fB\-\-initiate=\fP‌\fISECTION_NAME\fP]
-[\fB\-u\fP\ \fIID\fP\ |\ \fB\-\-user=\fP‌\fIID\fP]
-[\fB\-U\fP\ \fIID\fP\ |\ \fB\-\-legitimization=\fP‌\fIID\fP]
-[\fB\-P\fP\ |\ \fB\-\-print\-payto\-hash\fP]
-[\fB\-p\fP\ \fIHASH\fP\ |\ \fB\-\-payto\-hash=\fP‌\fIHASH\fP]
-[\fB\-r\fP\ \fINUMBER\fP\ |\ \fB\-\-rowid=\fP‌\fINUMBER\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
-[\fB\-w\fP\ |\ \fB\-\-run\-webservice\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-i\fP\ \fISECTION_NAME\fP\ |\ \fB–initiate=\fP‌\fISECTION_NAME\fP]
+[\fB\-u\fP\ \fIID\fP\ |\ \fB–user=\fP‌\fIID\fP]
+[\fB\-U\fP\ \fIID\fP\ |\ \fB–legitimization=\fP‌\fIID\fP]
+[\fB\-P\fP\ |\ \fB–print\-payto\-hash\fP]
+[\fB\-p\fP\ \fIHASH\fP\ |\ \fB–payto\-hash=\fP‌\fIHASH\fP]
+[\fB\-r\fP\ \fINUMBER\fP\ |\ \fB–rowid=\fP‌\fINUMBER\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
+[\fB\-w\fP\ |\ \fB–run\-webservice\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-kyc\-tester\fP is used to test the interaction between a Taler exchange and a KYC service. The tool can be used to manually trigger the various steps of a KYC process and to observe the interaction with the respective KYC service. It is supposted to help test the configuration of the integration, and \fInot\fP required at all during production.
@@ -53,48 +53,48 @@ To use it, you must first provide a configuration file with at least one KYC ser
 .sp
 Begin with a first invocation of taler\-exchange\-kyc\-tester using the options \fB\-i\fP for an individual or business and use \fB\-R\fP to specify a list of checks required from the process. The output will be an URL to visit with the browser, as well as \fB\-p\fP, \fB\-u\fP, \fB\-U\fP options to use in future invocations of the tool.
 .sp
-Next, run taler\-exchange\-kyc\-tester again, but this time using \fB\-w\fP (to run the Webserver) and using the \fB\-u\fP and \fB\-U\fP options output by the previous call, as well as the \fB\-p\fP option with the payto hash.  Then visit the Web site from the link output by the previous invocation and \(dqpass\(dq (or \(dqfail\(dq) the KYC check.
+Next, run taler\-exchange\-kyc\-tester again, but this time using \fB\-w\fP (to run the Webserver) and using the \fB\-u\fP and \fB\-U\fP options output by the previous call, as well as the \fB\-p\fP option with the payto hash.  Then visit the Web site from the link output by the previous invocation and “pass” (or “fail”) the KYC check.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-i\fP \fIUSERTYPE\fP | \fB\-\-initiate=\fP‌\fIUSERTYPE\fP
-Specifies the type of user for which we are starting a fresh KYC process. USERTYPE must be either \(dqindividual\(dq or \(dqbusiness\(dq.
+\fB\-i\fP \fIUSERTYPE\fP | \fB–initiate=\fP‌\fIUSERTYPE\fP
+Specifies the type of user for which we are starting a fresh KYC process. USERTYPE must be either “individual” or “business”.
 .TP
-\fB\-u\fP \fIID\fP | \fB\-\-user=\fP‌\fIID\fP
+\fB\-u\fP \fIID\fP | \fB–user=\fP‌\fIID\fP
 Run the process with ID for the user identifier at the KYC provider. Not useful in conjunction with \fB\-i\fP and \fB\-R\fP as that option will override whatever value is provided here.
 .TP
-\fB\-U\fP \fIID\fP | \fB\-\-legitimization=\fP‌\fIID\fP
+\fB\-U\fP \fIID\fP | \fB–legitimization=\fP‌\fIID\fP
 Run the process with ID for the legitimization process identifier at the KYC provider. Not useful in conjunction with \fB\-R\fP / \fB\-i\fP as that option will override whatever value is provided here.
 .TP
-\fB\-p\fP \fIHASH\fP | \fB\-\-payto\-hash=\fP‌\fIHASH\fP
+\fB\-p\fP \fIHASH\fP | \fB–payto\-hash=\fP‌\fIHASH\fP
 Run the process with HASH as the hash of the payto://\-URI that identifies the account or wallet triggering the KYC requirement. If not given, a fresh random value is used. Rarely useful.
 .TP
-\fB\-P\fP | \fB\-\-print\-payto\-hash\fP
+\fB\-P\fP | \fB–print\-payto\-hash\fP
 Print the HASH of the payto://\-URI used for the KYC simulation this time. Useful if the hash is needed for a subsequent use in conjunction with \fB\-p\fP\&.
 .TP
-\fB\-r\fP \fINUMBER\fP | \fB\-\-rowid=\fP‌\fINUMBER\fP
+\fB\-r\fP \fINUMBER\fP | \fB–rowid=\fP‌\fINUMBER\fP
 Run the process with NUMBER as the database row for the legitimization operation. Rarely useful, except maybe for debugging. Defaults to 42.
 .TP
-\fB\-R\fP \fICHECKS\fP | \fB\-\-requirements=\fP‌\fICHECKS\fP
+\fB\-R\fP \fICHECKS\fP | \fB–requirements=\fP‌\fICHECKS\fP
 Start a fresh KYC process for the given list of CHECKS. CHECKS must be a space\-separated list of checks that must be in the configuration under \fIPROVIDED_CHECKS\fP for some of the providers. The exchange will determine which provider to use for KYC based on the CHECKS given.  The tool will output the HTTP URL where the user has to begin the KYC process to the command\-line. This is usually the first thing to do when using this tool. Outputs the KYC\-logic specific user and legitimization IDs, or NULL if not used by the KYC\-logic at the initiation stage.  You may want to use the \fB\-P\fP option to also obtain the Payto\-Hash for use with \fBp\fP later.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .TP
-\fB\-w\fP | \fB\-\-run\-webservice\fP
+\fB\-w\fP | \fB–run\-webservice\fP
 Run a simulated Taler exchange HTTP service on the configured port with the \fB/kyc\-proof/\fP and \fB/kyc\-webhook/\fP endpoints.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-offline.1 b/man/taler-exchange-offline.1
index 222a7c80..4a32db6a 100644
--- a/man/taler-exchange-offline.1
+++ b/man/taler-exchange-offline.1
@@ -27,27 +27,27 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-OFFLINE" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-OFFLINE" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-offline \- operations using the offline key of a Taler exchange
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-offline\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
-[subcommand ...]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
+[subcommand …]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-offline\fP is a command\-line tool to interact with the Taler
-exchange\(aqs master private key. Most operations of this tool require access to
+exchange’s master private key. Most operations of this tool require access to
 the exchange’s long\-term offline signing key and should be run in a secure
 (offline) environment under strict controls.  The tool takes a list of
 subcommands as arguments which are then processed sequentially.
 .sp
-The tool includes two subcommands to interact \fIonline\fP with the exchange\(aqs
+The tool includes two subcommands to interact \fIonline\fP with the exchange’s
 REST APIs.  To determine how to talk to the exchange, these two subcommands
 rely on the \fBBASE_URL\fP configuration option from the \fB[exchange]\fP section
 of the configuration file.  The \fBdownload\fP subcommand downloads the future
@@ -55,10 +55,10 @@ public keys from the running exchange.  The resulting data serves as input to
 the \fBsign\fP and \fBshow\fP subcommands.  The \fBupload\fP subcommand uploads the
 signatures created with the private master key to the exchange.  It handles
 the output of all subcommands (except \fBdownload\fP).  The \fBdownload\fP and
-\fBupload\fP subcommands must naturally be run \(dqonline\(dq and do not require
+\fBupload\fP subcommands must naturally be run “online” and do not require
 access to the offline key.
 .sp
-All other subcommands are intended to be run \(dqoffline\(dq. However, especially
+All other subcommands are intended to be run “offline”. However, especially
 when testing, it is of course possible to run the subcommands online as well.
 Generally, subcommands read inputs (beyond command\-line arguments)
 from \fBstdin\fP\&. However, they may also consume outputs of previous
@@ -68,21 +68,21 @@ and if not consumed the final output is printed to \fBstdout\fP\&.
 The general options for \fBtaler\-exchange\-offline\fP are:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH CONFIGURATION
@@ -102,17 +102,17 @@ $ taler\-exchange\-offline setup
 .UNINDENT
 .sp
 Note that if the private key file already exists, the above will simply output
-the existing key.  Passing additional arguments after setup (including \(dq\-\(dq)
+the existing key.  Passing additional arguments after setup (including “\-“)
 will cause the output to be encapsulated in JSON.
 .sp
 Relevant configuration options for \fBtaler\-exchange\-offline\fP are:
 .INDENT 0.0
 .IP \(bu 2
-\fB[exchange/BASE_URL]\fP \-\-\- how to reach the exchange (for download/upload)
+\fB[exchange/BASE_URL]\fP — how to reach the exchange (for download/upload)
 .IP \(bu 2
-\fB[exchange\-offline/MASTER_PRIV_FILE]\fP \-\-\- where to store the private keys
+\fB[exchange\-offline/MASTER_PRIV_FILE]\fP — where to store the private keys
 .IP \(bu 2
-\fB[exchange\-offline/SECM_TOFU_FILE]\fP \-\-\- where to store TOFU data
+\fB[exchange\-offline/SECM_TOFU_FILE]\fP — where to store TOFU data
 .UNINDENT
 .SH SUBCOMMANDS
 .SS setup
@@ -164,7 +164,7 @@ configuration of extensions, in a format suitable for the \fBupload\fP
 subcommand.
 .sp
 Note that an extension on the exchange will only become activated at runtime
-\fIafter\fP the extension\(aqs configurations has been signed by the offline tool with
+\fIafter\fP the extension’s configurations has been signed by the offline tool with
 the signing key and the signed configuration been uploaded to the exchange.
 .SS drain
 .sp
@@ -208,23 +208,23 @@ in a format suitable for the \fBupload\fP subcommand.
 .sp
 This subcommand
 informs an exchange that an auditor is to be activated. Afterwards, the
-exchange will accept inputs from that auditor\(aqs \fBtaler\-auditor\-offline\fP
+exchange will accept inputs from that auditor’s \fBtaler\-auditor\-offline\fP
 tool.  Note that the auditor also must add the exchange to the list of
 exchanges that it audits via \fBtaler\-auditor\-exchange\fP\&. Furthermore, the
-exchange\(aqs database will need to be provided to the auditor.  This subcommand
+exchange’s database will need to be provided to the auditor.  This subcommand
 only informs the exchange about the auditor, but does not perform those
 additional mandatory steps for a working auditor.
 .sp
-The auditor\(aqs public key must be given in the usual base32\-encoding as the
+The auditor’s public key must be given in the usual base32\-encoding as the
 first argument.
 .sp
-The auditor\(aqs REST API base URL must be given as the second argument. The tool
-performs a minimal sanity check, namely that the URL begins with \(dqhttp\(dq
-(this also allows \(dqhttps\(dq), but as it runs offline does not perform any further
+The auditor’s REST API base URL must be given as the second argument. The tool
+performs a minimal sanity check, namely that the URL begins with “http”
+(this also allows “https”), but as it runs offline does not perform any further
 validation!
 .sp
 The third argument must be a human\-readable name for the auditor. This may
-be shown to users and should identify the auditor\(aqs business entity.  If
+be shown to users and should identify the auditor’s business entity.  If
 the name includes spaces, the argument should be quoted.
 .sp
 The subcommand takes no inputs from \fBstdin\fP or other subcommands.
@@ -235,10 +235,10 @@ in a format suitable for the \fBupload\fP subcommand.
 .sp
 This subcommand
 informs an exchange that an auditor is to be deactivated. Afterwards, the
-exchange will refuse inputs from that auditor\(aqs \fBtaler\-auditor\-offline\fP
+exchange will refuse inputs from that auditor’s \fBtaler\-auditor\-offline\fP
 tool.
 .sp
-The auditor\(aqs public key must be given in the usual base32\-encoding as the
+The auditor’s public key must be given in the usual base32\-encoding as the
 first argument.
 .sp
 The subcommand takes no inputs from \fBstdin\fP or other subcommands.
@@ -256,7 +256,7 @@ account information advertised could theoretically differ from that which
 these tool actually use, for example if the public bank account is only a
 front for the actual internal business accounts.
 .sp
-The \fBpayto://\fP URI (RFC 8905) of the exchange\(aqs bank account must be given
+The \fBpayto://\fP URI (RFC 8905) of the exchange’s bank account must be given
 as the first argument to the subcommand.
 .sp
 Afterwards, optional arguments can be given:
@@ -294,7 +294,7 @@ The following types of credit\- and debit\-restrictions are supported:
 \fBdeny\fP: A $TYPE of \fBdeny\fP means that this bank account cannot be used
 for the given operation.  \fBdeny\fP takes no further arguments.
 .IP \(bu 2
-\fBregex\fP $EXPR $HINT $JSON: A $TYPE of \fBregex\fP means that the partner\(aqs
+\fBregex\fP $EXPR $HINT $JSON: A $TYPE of \fBregex\fP means that the partner’s
 bank account \fBpayto\fP\-URI representation must follow a certain regular
 expression given in $EXPR where the syntax follows posix\-egrep, but
 without support for character classes, GNU extensions, back\-references or
@@ -317,7 +317,7 @@ This subcommand
 informs an exchange that it should stop advertising a bank account as
 belonging to the exchange on its \fB/wire\fP endpoint.
 .sp
-The \fBpayto://\fP URI (RFC 8905) of the exchange\(aqs (former) bank account must be
+The \fBpayto://\fP URI (RFC 8905) of the exchange’s (former) bank account must be
 given as the first argument to the subcommand.
 .sp
 The subcommand takes no inputs from \fBstdin\fP or other subcommands.
@@ -371,11 +371,11 @@ Partner exchange base URL.
 .IP 2. 3
 Partner exchange master public key.
 .IP 3. 3
-Calendar year for which the fee applies, \(aqnow\(aq for the current year.
+Calendar year for which the fee applies, ‘now’ for the current year.
 .IP 4. 3
-Wad frequency, in minutes (for example, \(aq30\(aq).
+Wad frequency, in minutes (for example, ‘30’).
 .IP 5. 3
-Wad fee (for example, \(aqKUDOS:0.1\(aq).
+Wad fee (for example, ‘KUDOS:0.1’).
 .UNINDENT
 .UNINDENT
 .UNINDENT
@@ -388,7 +388,7 @@ The arguments provided must include:
 .INDENT 3.5
 .INDENT 0.0
 .IP 1. 3
-Calendar year for which the fee applies, \(aqnow\(aq for the current year.
+Calendar year for which the fee applies, ‘now’ for the current year.
 .IP 2. 3
 KYC timeout. How long does the exchange keep a reserve open that is waiting for the KYC.
 .IP 3. 3
@@ -410,8 +410,8 @@ History fee charged when inquiring about non\-recent account history.
 .UNINDENT
 .SS aml\-enable
 .sp
-Enable AML officer\(aqs account, granting them access to AML data and,
-if \(aqrw\(aq is given, the power to make AML decisions.
+Enable AML officer’s account, granting them access to AML data and,
+if ‘rw’ is given, the power to make AML decisions.
 .sp
 The arguments provided must include:
 .INDENT 0.0
@@ -422,13 +422,13 @@ AML staff member public key (in base32 encoding)
 .IP 2. 3
 AML staff member legal name
 .IP 3. 3
-\(aqro\(aq or \(aqrw\(aq to set access to read\-only or read\-write
+‘ro’ or ‘rw’ to set access to read\-only or read\-write
 .UNINDENT
 .UNINDENT
 .UNINDENT
 .SS aml\-disable
 .sp
-Disable AML officer\(aqs account. Also updates the legal name.
+Disable AML officer’s account. Also updates the legal name.
 .sp
 The arguments provided must include:
 .INDENT 0.0
@@ -459,7 +459,7 @@ Wad fee to charge.
 .IP 4. 3
 Wad transfer frequency.
 .IP 5. 3
-Year for which the above options are to be configured, \(aqnow\(aq for the current year.
+Year for which the above options are to be configured, ‘now’ for the current year.
 .UNINDENT
 .UNINDENT
 .UNINDENT
@@ -522,7 +522,7 @@ $ taler\-exchange\-offline upload < sigs.json
 .SS Download, sign and upload, all in one (online)
 .sp
 Note that doing this is only recommended in non\-production deployments,
-as this requires putting the \(dqoffline\(dq key onto a system that is actually
+as this requires putting the “offline” key onto a system that is actually
 online!
 .INDENT 0.0
 .INDENT 3.5
@@ -658,7 +658,7 @@ $ taler\-exchange\-offline \e
 .UNINDENT
 .UNINDENT
 .sp
-The outputs (\(dqrevoke.json\(dq, \(dqmix.json\(dq) must be uploaded using the \fBupload\fP
+The outputs (“revoke.json”, “mix.json”) must be uploaded using the \fBupload\fP
 subcommand to the exchange to actually revoke the keys.
 .SH SECURITY CONSIDERATIONS
 .sp
@@ -667,8 +667,8 @@ system with \fImonotonic time\fP\&. The time does not have to precisely match th
 of the exchange, but it must be monotonic across tool invocations. The clock
 of the offline system is used in the enable/disable signatures to communicate
 an order of the events to the exchange.  This prevents someone from replaying
-an older \(dqenable\(dq (or \(dqdisable\(dq) message after a more recent \(dqdisable\(dq (or
-\(dqenable\(dq) message has been provided to the exchange.  Thus, there is no need
+an older “enable” (or “disable”) message after a more recent “disable” (or
+“enable”) message has been provided to the exchange.  Thus, there is no need
 to keep the actual files exchanged with the offline tool secret.
 .sp
 The \fBtaler\-exchange\-offline\fP tool tries to make sure that the online signing
@@ -678,7 +678,7 @@ but \fInot\fP the security modules from providing attacker\-controlled keys to t
 offline signing process.
 .sp
 For this, the \fBtaler\-exchange\-offline\fP signing subcommand always
-automatically learns the security module\(aqs public signing key and \fItrusts it
+automatically learns the security module’s public signing key and \fItrusts it
 on first use\fP (TOFU), but stores it to disk (see the \fBSECM_TOFU_FILE\fP option
 in the \fB[exchange\-offline]\fP section of the configuration).  If the keys
 change subsequently, the tool will refuse to sign.
diff --git a/man/taler-exchange-router.1 b/man/taler-exchange-router.1
index ac2872a4..7432bf2d 100644
--- a/man/taler-exchange-router.1
+++ b/man/taler-exchange-router.1
@@ -27,19 +27,19 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-ROUTER" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-ROUTER" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-router \- route payments to partner exchanges
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-router\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-t\fP\ |\ \fB\-\-test\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ |\ \fB–test\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-router\fP is a NOT YET IMPLEMENTED command\-line
@@ -49,29 +49,29 @@ wallets where the recipient has performed the KYC at a different
 exchange than the sender.  This is currently not supported.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-t\fP | \fB–test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-secmod-cs.1 b/man/taler-exchange-secmod-cs.1
index 7a31883f..bbed30dc 100644
--- a/man/taler-exchange-secmod-cs.1
+++ b/man/taler-exchange-secmod-cs.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-SECMOD-CS" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-SECMOD-CS" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-secmod-cs \- handle private CS key operations for a Taler exchange
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-secmod\-cs\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-p\fP\ \fIN\fP\ |\ ,**\-\-parallelism=**\fIN\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB\-\-time=\fP\fITIMESTAMP\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-p\fP\ \fIN\fP\ |\ ,**–parallelism=**\fIN\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB–time=\fP\fITIMESTAMP\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-secmod\-cs\fP is a command\-line tool to
@@ -51,33 +51,33 @@ FIXME: More details.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fBp\fP \fIN\fP | \fB\-\-parallelism=\fP\fIN\fP
+\fBp\fP \fIN\fP | \fB–parallelism=\fP\fIN\fP
 Run with \fIN\fP worker threads.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP \fITIMESTAMP\fP | \fB\-\-time=\fP\fITIMESTAMP\fP
+\fB\-t\fP \fITIMESTAMP\fP | \fB–time=\fP\fITIMESTAMP\fP
 Pretend it is \fITIMESTAMP\fP for the update.
 \fITIMESTAMP\fP is a human\-readable string (e.g., \fBYYYY\-MM\-DD HH:MM:SS\fP).
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-secmod-eddsa.1 b/man/taler-exchange-secmod-eddsa.1
index 87f0ac8c..a30524b4 100644
--- a/man/taler-exchange-secmod-eddsa.1
+++ b/man/taler-exchange-secmod-eddsa.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-SECMOD-EDDSA" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-SECMOD-EDDSA" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-secmod-eddsa \- handle private EDDSA key operations for a Taler exchange
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-secmod\-eddsa\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-p\fP\ \fIN\fP\ |\ ,**\-\-parallelism=**\fIN\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB\-\-time=\fP\fITIMESTAMP\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-p\fP\ \fIN\fP\ |\ ,**–parallelism=**\fIN\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB–time=\fP\fITIMESTAMP\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-secmod\-eddsa\fP is a command\-line tool to
@@ -51,33 +51,33 @@ FIXME: More details.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fBp\fP \fIN\fP | \fB\-\-parallelism=\fP\fIN\fP
+\fBp\fP \fIN\fP | \fB–parallelism=\fP\fIN\fP
 Run with \fIN\fP worker threads.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP \fITIMESTAMP\fP | \fB\-\-time=\fP\fITIMESTAMP\fP
+\fB\-t\fP \fITIMESTAMP\fP | \fB–time=\fP\fITIMESTAMP\fP
 Pretend it is \fITIMESTAMP\fP for the update.
 \fITIMESTAMP\fP is a human\-readable string (e.g., \fBYYYY\-MM\-DD HH:MM:SS\fP).
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-secmod-rsa.1 b/man/taler-exchange-secmod-rsa.1
index 5fef67ac..99ecf430 100644
--- a/man/taler-exchange-secmod-rsa.1
+++ b/man/taler-exchange-secmod-rsa.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-SECMOD-RSA" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-SECMOD-RSA" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-secmod-rsa \- handle private RSA key operations for a Taler exchange
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-secmod\-rsa\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-p\fP\ \fIN\fP\ |\ ,**\-\-parallelism=**\fIN\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB\-\-time=\fP\fITIMESTAMP\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-p\fP\ \fIN\fP\ |\ ,**–parallelism=**\fIN\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB–time=\fP\fITIMESTAMP\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-secmod\-rsa\fP is a command\-line tool to
@@ -51,33 +51,33 @@ FIXME: More details.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fBp\fP \fIN\fP | \fB\-\-parallelism=\fP\fIN\fP
+\fBp\fP \fIN\fP | \fB–parallelism=\fP\fIN\fP
 Run with \fIN\fP worker threads.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP \fITIMESTAMP\fP | \fB\-\-time=\fP\fITIMESTAMP\fP
+\fB\-t\fP \fITIMESTAMP\fP | \fB–time=\fP\fITIMESTAMP\fP
 Pretend it is \fITIMESTAMP\fP for the update.
 \fITIMESTAMP\fP is a human\-readable string (e.g., \fBYYYY\-MM\-DD HH:MM:SS\fP).
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-transfer.1 b/man/taler-exchange-transfer.1
index 0f37ba68..c05cb4f2 100644
--- a/man/taler-exchange-transfer.1
+++ b/man/taler-exchange-transfer.1
@@ -27,48 +27,48 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-TRANSFER" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-TRANSFER" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-transfer \- execute wire transfers
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-transfer\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel\fP\fIUSEC\fP]
-[\fB\-t\fP\ |\ \fB\-\-test\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel\fP\fIUSEC\fP]
+[\fB\-t\fP\ |\ \fB–test\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-transfer\fP is a command\-line tool to actually execute scheduled wire transfers (using the bank/wire gateway).
 The transfers are prepared by the \fBtaler\-exchange\-aggregator\fP and \fBtaler\-exchange\-closer\fP tools.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-t\fP | \fB–test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-wire-gateway-client.1 b/man/taler-exchange-wire-gateway-client.1
index 56d1cb3f..e11f0cfe 100644
--- a/man/taler-exchange-wire-gateway-client.1
+++ b/man/taler-exchange-wire-gateway-client.1
@@ -27,28 +27,28 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-WIRE-GATEWAY-CLIENT" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-WIRE-GATEWAY-CLIENT" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-wire-gateway-client \- trigger a transfer at the bank
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-wire\-gateway\-client\fP
-[\fB\-a\fP\ \fIVALUE\fP\ |\ \fB\-\-amount=\fP‌\fIVALUE\fP]
-[\fB\-b\fP\ \fIURL\fP\ |\ \fB\-\-bank=\fP‌\fIURL\fP]
-[\fB\-C\fP\ \fIACCOUNT\fP\ |\ \fB\-\-credit=\fP‌\fIACCOUNT\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-D\fP\ \fIACCOUNT\fP\ |\ \fB\-\-debit=\fP‌\fIACCOUNT\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-i\fP\ |\ \fB\-\-credit\-history\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-o\fP\ |\ \fB\-\-debit\-history\fP]
-[\fB\-p\fP\ \fIPASSPHRASE\fP\ |\ \fB\-\-pass=\fP‌\fIPASSPHRASE\fP]
-[\fB\-S\fP\ \fISTRING\fP\ |\ \fB\-\-subject=\fP‌\fISTRING\fP]
-[\fB\-s\fP\ \fIACCOUNT\-SECTION\fP\ |\ \fB\-\-section=\fP‌\fIACCOUNT\-SECTION\fP]
-[\fB\-u\fP\ \fIUSERNAME\fP\ |\ \fB\-\-user=\fP‌\fIUSERNAME\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
-[\fB\-w\fP\ \fIROW\fP\ |\ \fB\-\-since\-when=\fP‌\fIROW\fP]
+[\fB\-a\fP\ \fIVALUE\fP\ |\ \fB–amount=\fP‌\fIVALUE\fP]
+[\fB\-b\fP\ \fIURL\fP\ |\ \fB–bank=\fP‌\fIURL\fP]
+[\fB\-C\fP\ \fIACCOUNT\fP\ |\ \fB–credit=\fP‌\fIACCOUNT\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-D\fP\ \fIACCOUNT\fP\ |\ \fB–debit=\fP‌\fIACCOUNT\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-i\fP\ |\ \fB–credit\-history\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-o\fP\ |\ \fB–debit\-history\fP]
+[\fB\-p\fP\ \fIPASSPHRASE\fP\ |\ \fB–pass=\fP‌\fIPASSPHRASE\fP]
+[\fB\-S\fP\ \fISTRING\fP\ |\ \fB–subject=\fP‌\fISTRING\fP]
+[\fB\-s\fP\ \fIACCOUNT\-SECTION\fP\ |\ \fB–section=\fP‌\fIACCOUNT\-SECTION\fP]
+[\fB\-u\fP\ \fIUSERNAME\fP\ |\ \fB–user=\fP‌\fIUSERNAME\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
+[\fB\-w\fP\ \fIROW\fP\ |\ \fB–since\-when=\fP‌\fIROW\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-wire\-gateway\-client\fP is a command\-line tool to trigger bank transfers or
@@ -77,58 +77,58 @@ on transaction history operations.
 .SH OPTIONS
 .INDENT 0.0
 .TP
-\fB\-a\fP \fIVALUE\fP | \fB\-\-amount=\fP‌\fIVALUE\fP
+\fB\-a\fP \fIVALUE\fP | \fB–amount=\fP‌\fIVALUE\fP
 Amount to transfer. Given in the Taler\-typical format of
 CURRENCY:VALUE.FRACTION.
 .TP
-\fB\-b\fP \fIURL\fP | \fB\-\-bank=\fP‌\fIURL\fP
+\fB\-b\fP \fIURL\fP | \fB–bank=\fP‌\fIURL\fP
 URL at which the bank is operation.  Conflicts with \fB\-s\fP\&.
 .TP
-\fB\-C\fP \fIACCOUNT\fP | \fB\-\-credit=\fP‌\fIACCOUNT\fP
+\fB\-C\fP \fIACCOUNT\fP | \fB–credit=\fP‌\fIACCOUNT\fP
 When doing a wire transfer from the exchange, the money should be credited to \fIACCOUNT\fP\&.
 Specifies the payto:// URI of the account.  Can also be used as a filter by credit
 account when looking at transaction histories.
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the given configuration file.
 .TP
-\fB\-D\fP \fIACCOUNT\fP | \fB\-\-debit=\fP‌\fIACCOUNT\fP
+\fB\-D\fP \fIACCOUNT\fP | \fB–debit=\fP‌\fIACCOUNT\fP
 When doing a wire transfer to the exchange, the \fIACCOUNT\fP is to be debited.
 Specifies the payto:// URI of the account.  Can also be used as a filter by debit
 account when looking at transaction histories.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-i\fP | \fB\-\-credit\-history\fP
+\fB\-i\fP | \fB–credit\-history\fP
 Obtain credit history of the exchange. Conflicts with \fB\-o\fP\&.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-o\fP | \fB\-\-debit\-history\fP
+\fB\-o\fP | \fB–debit\-history\fP
 Obtain debit history of the exchange. Conflicts with \fB\-i\fP\&.
 .TP
-\fB\-p\fP \fIPASSPHRASE\fP | \fB\-\-pass=\fP‌\fIPASSPHRASE\fP
+\fB\-p\fP \fIPASSPHRASE\fP | \fB–pass=\fP‌\fIPASSPHRASE\fP
 Specifies the pass phrase for authentication.  Conflicts with \fB\-s\fP\&.
 .TP
-\fB\-S\fP \fISUBJECT\fP | \fB\-\-subject=\fP‌\fISUBJECT\fP
+\fB\-S\fP \fISUBJECT\fP | \fB–subject=\fP‌\fISUBJECT\fP
 Use \fISUBJECT\fP for the wire transfer subject.  Must be a reserve public key for credit operations and a wire transfer identifier for debit operations. If not specified, a random value will be generated instead.
 .TP
-\fB\-s\fP \fIACCOUNT_SECTION\fP | \fB\-\-section=\fP‌\fIACCOUNT\-SECTION\fP
+\fB\-s\fP \fIACCOUNT_SECTION\fP | \fB–section=\fP‌\fIACCOUNT\-SECTION\fP
 Obtain exchange account information from the \fIACCOUNT\-SECTION\fP of the configuration. The argument must be a \fB[exchange\-accountcredentials\-$NAME]\fP section name and thus start with the \fBexchange\-accountcredentials\-\fP prefix. Conflicts with \fB\-u\fP, \fB\-p\fP and \fB\-b\fP\&.  Note that either \fB\-b\fP or \fB\-s\fP must be specified.
 .TP
-\fB\-u\fP \fIUSERNAME\fP | \fB\-\-user=\fP‌\fIUSERNAME\fP
+\fB\-u\fP \fIUSERNAME\fP | \fB–user=\fP‌\fIUSERNAME\fP
 Specifies the username for authentication.  Optional and conflicts with \fB\-s\fP\&. If neither \fB\-u\fP nor \fB\-s\fP are used, we will attempt to talk to the bank without authentication.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .TP
-\fB\-w\fP \fIROW\fP | \fB\-\-since\-when=\fP‌\fIROW\fP
+\fB\-w\fP \fIROW\fP | \fB–since\-when=\fP‌\fIROW\fP
 Specifies a \fIROW\fP from which the history should be obtained. If not given, the 10 youngest transactions are returned.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-exchange-wirewatch.1 b/man/taler-exchange-wirewatch.1
index fe0fcc21..743609e9 100644
--- a/man/taler-exchange-wirewatch.1
+++ b/man/taler-exchange-wirewatch.1
@@ -27,21 +27,21 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-EXCHANGE-WIREWATCH" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-EXCHANGE-WIREWATCH" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-exchange-wirewatch \- watch for incoming wire transfers
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-wirewatch\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-I**_|_\fP\-\-ignore\-not\-found**]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-r\fP\ |\ \fB\-\-reset\fP]
-[\fB\-T\fP\ |\ \fB\-\-test\fP]
-[\fB\-t\fP\ \fIPLUGINNAME\fP\ |\ \fB\-\-type=\fP‌\fIPLUGINNAME\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-I**_|_\fP–ignore\-not\-found**]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-r\fP\ |\ \fB–reset\fP]
+[\fB\-T\fP\ |\ \fB–test\fP]
+[\fB\-t\fP\ \fIPLUGINNAME\fP\ |\ \fB–type=\fP‌\fIPLUGINNAME\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-exchange\-wirewatch\fP is a command\-line tool to import wire
@@ -50,40 +50,40 @@ transactions into the Taler exchange database.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-f\fP \fIDELAY\fP| \fB\-\-longpoll\-timeout=\fP\fIDELAY\fP
+\fB\-f\fP \fIDELAY\fP| \fB–longpoll\-timeout=\fP\fIDELAY\fP
 How long do we wait for a response for bank transactions from the bank. This is both the timeout for the long polling as well as the maximum frequency at which we would query the bank. Specified with unit (e.g. 30s, 1d, 2w), if no unit is given the number is interpreted in microseconds. Default is 60s.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-I\fP | \fB\-\-ignore\-not\-found\fP
+\fB\-I\fP | \fB–ignore\-not\-found\fP
 Do not fail if the bank says that the exchange bank account does not (yet) exist.
 Keep trying.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-r\fP | \fB\-\-reset\fP
+\fB\-r\fP | \fB–reset\fP
 Ignore our own database and start with transactions from the
 beginning of time.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-t\fP | \fB–test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-helper-auditor-aggregation.1 b/man/taler-helper-auditor-aggregation.1
index c2821763..a81f6bcd 100644
--- a/man/taler-helper-auditor-aggregation.1
+++ b/man/taler-helper-auditor-aggregation.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-HELPER-AUDITOR-AGGREGATION" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-HELPER-AUDITOR-AGGREGATION" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-helper-auditor-aggregation \- audit Taler exchange aggregation activity
 .SH SYNOPSIS
 .sp
 \fBtaler\-helper\-auditor\-aggregation\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fBi\fP\ |\ \fB\-\-internal\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIKEY\fP\ |\ \fB\-\-exchange\-key=\fP\fIKEY\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fBi\fP\ |\ \fB–internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB–exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-helper\-auditor\-aggregation\fP is a command\-line tool to
@@ -51,32 +51,32 @@ FIXME: More detail.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the auditor to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-i\fP | \fB\-\-internal\fP
+\fB\-i\fP | \fB–internal\fP
 Perform checks only applicable for exchange\-internal audits.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIKEY\fP | \fB\-\-exchange\-key=\fP\fIKEY\fP
+\fB\-m\fP \fIKEY\fP | \fB–exchange\-key=\fP\fIKEY\fP
 Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-helper-auditor-coins.1 b/man/taler-helper-auditor-coins.1
index f53989f5..ae982ea9 100644
--- a/man/taler-helper-auditor-coins.1
+++ b/man/taler-helper-auditor-coins.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-HELPER-AUDITOR-COINS" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-HELPER-AUDITOR-COINS" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-helper-auditor-coins \- audit Taler coin processing
 .SH SYNOPSIS
 .sp
 \fBtaler\-helper\-auditor\-coins\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fBi\fP\ |\ \fB\-\-internal\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIKEY\fP\ |\ \fB\-\-exchange\-key=\fP\fIKEY\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fBi\fP\ |\ \fB–internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB–exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-helper\-auditor\-coins\fP is a command\-line tool to
@@ -51,32 +51,32 @@ FIXME: More detail.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the auditor to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-i\fP | \fB\-\-internal\fP
+\fB\-i\fP | \fB–internal\fP
 Perform checks only applicable for exchange\-internal audits.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIKEY\fP | \fB\-\-exchange\-key=\fP\fIKEY\fP
+\fB\-m\fP \fIKEY\fP | \fB–exchange\-key=\fP\fIKEY\fP
 Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-helper-auditor-deposits.1 b/man/taler-helper-auditor-deposits.1
index 32abc6c4..35a0e3d3 100644
--- a/man/taler-helper-auditor-deposits.1
+++ b/man/taler-helper-auditor-deposits.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-HELPER-AUDITOR-DEPOSITS" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-HELPER-AUDITOR-DEPOSITS" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-helper-auditor-deposits \- audit Taler exchange database for deposit confirmation consistency
 .SH SYNOPSIS
 .sp
 \fBtaler\-helper\-auditor\-deposits\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fBi\fP\ |\ \fB\-\-internal\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIKEY\fP\ |\ \fB\-\-exchange\-key=\fP\fIKEY\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fBi\fP\ |\ \fB–internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB–exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-helper\-auditor\-deposits\fP is a command\-line tool to
@@ -51,32 +51,32 @@ FIXME: More detail.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the auditor to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-i\fP | \fB\-\-internal\fP
+\fB\-i\fP | \fB–internal\fP
 Perform checks only applicable for exchange\-internal audits.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIKEY\fP | \fB\-\-exchange\-key=\fP\fIKEY\fP
+\fB\-m\fP \fIKEY\fP | \fB–exchange\-key=\fP\fIKEY\fP
 Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-helper-auditor-purses.1 b/man/taler-helper-auditor-purses.1
index c93c5391..6beb71b5 100644
--- a/man/taler-helper-auditor-purses.1
+++ b/man/taler-helper-auditor-purses.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-HELPER-AUDITOR-PURSES" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-HELPER-AUDITOR-PURSES" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-helper-auditor-purses \- audit Taler exchange purse handling
 .SH SYNOPSIS
 .sp
 \fBtaler\-helper\-auditor\-purses\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fBi\fP\ |\ \fB\-\-internal\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIKEY\fP\ |\ \fB\-\-exchange\-key=\fP\fIKEY\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fBi\fP\ |\ \fB–internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB–exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-helper\-auditor\-purses\fP is a command\-line tool to
@@ -51,32 +51,32 @@ FIXME: More detail.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the auditor to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-i\fP | \fB\-\-internal\fP
+\fB\-i\fP | \fB–internal\fP
 Perform checks only applicable for exchange\-internal audits.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIKEY\fP | \fB\-\-exchange\-key=\fP\fIKEY\fP
+\fB\-m\fP \fIKEY\fP | \fB–exchange\-key=\fP\fIKEY\fP
 Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-helper-auditor-reserves.1 b/man/taler-helper-auditor-reserves.1
index a0935ccb..34a9e34b 100644
--- a/man/taler-helper-auditor-reserves.1
+++ b/man/taler-helper-auditor-reserves.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-HELPER-AUDITOR-RESERVES" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-HELPER-AUDITOR-RESERVES" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-helper-auditor-reserves \- audit Taler exchange reserve handling
 .SH SYNOPSIS
 .sp
 \fBtaler\-helper\-auditor\-reserves\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fBi\fP\ |\ \fB\-\-internal\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIKEY\fP\ |\ \fB\-\-exchange\-key=\fP\fIKEY\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fBi\fP\ |\ \fB–internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB–exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-helper\-auditor\-reserves\fP is a command\-line tool to
@@ -51,32 +51,32 @@ FIXME: More detail.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the auditor to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-i\fP | \fB\-\-internal\fP
+\fB\-i\fP | \fB–internal\fP
 Perform checks only applicable for exchange\-internal audits.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIKEY\fP | \fB\-\-exchange\-key=\fP\fIKEY\fP
+\fB\-m\fP \fIKEY\fP | \fB–exchange\-key=\fP\fIKEY\fP
 Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-helper-auditor-wire.1 b/man/taler-helper-auditor-wire.1
index 9b492827..bb8275a2 100644
--- a/man/taler-helper-auditor-wire.1
+++ b/man/taler-helper-auditor-wire.1
@@ -27,56 +27,56 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-HELPER-AUDITOR-WIRE" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-HELPER-AUDITOR-WIRE" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-helper-auditor-wire \- audit exchange database for consistency with the bank's wire transfers
 .SH SYNOPSIS
 .sp
 \fBtaler\-helper\-auditor\-wire\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fBi\fP\ |\ \fB\-\-internal\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIKEY\fP\ |\ \fB\-\-exchange\-key=\fP\fIKEY\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel=\fP\fIUSEC\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fBi\fP\ |\ \fB–internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB–exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-helper\-auditor\-wire\fP is a command\-line tool to
-audit exchange database for consistency with the bank\(aqs wire transfers.
+audit exchange database for consistency with the bank’s wire transfers.
 .sp
 FIXME: More detail.
 .sp
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the auditor to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-i\fP | \fB\-\-internal\fP
+\fB\-i\fP | \fB–internal\fP
 Perform checks only applicable for exchange\-internal audits.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIKEY\fP | \fB\-\-exchange\-key=\fP\fIKEY\fP
+\fB\-m\fP \fIKEY\fP | \fB–exchange\-key=\fP\fIKEY\fP
 Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-merchant-benchmark.1 b/man/taler-merchant-benchmark.1
index 5284ecf4..5ee8b721 100644
--- a/man/taler-merchant-benchmark.1
+++ b/man/taler-merchant-benchmark.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-MERCHANT-BENCHMARK" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-MERCHANT-BENCHMARK" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-merchant-benchmark \- generate Taler-style benchmarking payments
 .SH SYNOPSIS
@@ -46,7 +46,7 @@ default instance) and aggregated by the exchange.  Takes the following
 option:
 .INDENT 7.0
 .TP
-\fB\-p\fP \fIPN\fP | \fB\-\-payments\-number=\fP\fIPN\fP
+\fB\-p\fP \fIPN\fP | \fB–payments\-number=\fP\fIPN\fP
 Perform PN many payments, defaults to 1.
 .UNINDENT
 .TP
@@ -56,11 +56,11 @@ leaving payments unaggregated, or using a non\-default merchant
 instance.  Takes the following options:
 .INDENT 7.0
 .TP
-\fB\-t\fP \fITC\fP | \fB\-\-two\-coins=\fP\fITC\fP
+\fB\-t\fP \fITC\fP | \fB–two\-coins=\fP\fITC\fP
 Perform TC many payments that use two coins (normally, all the
 payments use only one coin).  TC defaults to 1.
 .TP
-\fB\-u\fP \fIUN\fP | \fB\-\-unaggregated\-number=\fP\fIUN\fP
+\fB\-u\fP \fIUN\fP | \fB–unaggregated\-number=\fP\fIUN\fP
 Generate UN payments that will be left unaggregated.  Note that
 subsequent invocations of the generator may pick those
 unaggregated payments and actually aggregated them.
@@ -69,27 +69,27 @@ unaggregated payments and actually aggregated them.
 .SH COMMON OPTIONS
 .INDENT 0.0
 .TP
-\fB\-a\fP \fIAPIKEY\fP | \fB\-\-apikey=\fP\fIAPIKEY\fP
-HTTP \(aqAuthorization\(aq header to send to the merchant.
+\fB\-a\fP \fIAPIKEY\fP | \fB–apikey=\fP\fIAPIKEY\fP
+HTTP ‘Authorization’ header to send to the merchant.
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP\fIFILENAME\fP
 Use the configuration and other resources for the merchant to
 operate from FILENAME.
 .TP
-\fB\-u\fP \fISECTION\fP | \fB\-\-exchange\-account\-section=\fP\fISECTION\fP
+\fB\-u\fP \fISECTION\fP | \fB–exchange\-account\-section=\fP\fISECTION\fP
 Configuration \fISECTION\fP specifying the exchange account to use.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-merchant-dbconfig.1 b/man/taler-merchant-dbconfig.1
index f414696a..4e15e4db 100644
--- a/man/taler-merchant-dbconfig.1
+++ b/man/taler-merchant-dbconfig.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-MERCHANT-DBCONFIG" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-MERCHANT-DBCONFIG" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-merchant-dbconfig \- configure Taler merchant database
 .SH SYNOPSIS
diff --git a/man/taler-merchant-dbinit.1 b/man/taler-merchant-dbinit.1
index 0961f651..b29c1847 100644
--- a/man/taler-merchant-dbinit.1
+++ b/man/taler-merchant-dbinit.1
@@ -27,18 +27,18 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-MERCHANT-DBINIT" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-MERCHANT-DBINIT" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-merchant-dbinit \- initialize Taler merchant database
 .SH SYNOPSIS
 .sp
 \fBtaler\-merchant\-dbinit\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-r\fP\ |\ \fB\-\-reset\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-r\fP\ |\ \fB–reset\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-merchant\-dbinit\fP is a command\-line tool to initialize the Taler
@@ -48,21 +48,21 @@ Taler merchant to operate.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-r\fP | \fB\-\-reset\fP
+\fB\-r\fP | \fB–reset\fP
 Drop tables. Dangerous, will delete all existing data in the database
 before creating the tables.
 .TP
diff --git a/man/taler-merchant-httpd.1 b/man/taler-merchant-httpd.1
index a33f4cac..6b34de2d 100644
--- a/man/taler-merchant-httpd.1
+++ b/man/taler-merchant-httpd.1
@@ -27,20 +27,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-MERCHANT-HTTPD" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-MERCHANT-HTTPD" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-merchant-httpd \- run Taler merchant backend (with RESTful API)
 .SH SYNOPSIS
 .sp
 \fBtaler\-merchant\-httpd\fP
-[\fB\-a**_|_\fP\-\-auth**]
-[\fB\-C\fP\ |\ \fB\-\-connection\-close\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB\-\-timetravel\fP\fIUSEC\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-a**_|_\fP–auth**]
+[\fB\-C\fP\ |\ \fB–connection\-close\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB–timetravel\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-merchant\-httpd\fP is a command\-line tool to run the Taler merchant
@@ -49,44 +49,44 @@ before running this command.
 .SH OPTIONS
 .INDENT 0.0
 .TP
-\fB\-a\fP \fITOKEN\fP | \fB\-\-auth=\fP\fITOKEN\fP
-Use TOKEN for initial access control to the merchant backend. TOKEN must start with the \(dqsecret\-token:\(dq prefix, as per RFC 8959.  The value
+\fB\-a\fP \fITOKEN\fP | \fB–auth=\fP\fITOKEN\fP
+Use TOKEN for initial access control to the merchant backend. TOKEN must start with the “secret\-token:” prefix, as per RFC 8959.  The value
 given in TOKEN must appear in backoffice requests to the default instance
-of the merchant, i.e. \(dqAuthorization: Bearer TOKEN\(dq to obtain
+of the merchant, i.e. “Authorization: Bearer TOKEN” to obtain
 access to the merchant backend.  Note that setting a passphrase for the
 default instance by any means will block future access via TOKEN.  This
 is basically a way to reset the passphrase protecting access.  TOKEN
-should be a \(dqpchar\(dq as per RFC 8959, but this is NOT checked.  Note that
-TOKEN will only grant access to the \(aqdefault\(aq instance, not other instances.
+should be a “pchar” as per RFC 8959, but this is NOT checked.  Note that
+TOKEN will only grant access to the ‘default’ instance, not other instances.
 Instead of using the command\-line, which exposes TOKEN to users on the
 system, you may want to consider setting the
 TALER_MERCHANT_TOKEN environment variable instead.
 .TP
-\fB\-C\fP | \fB\-\-connection\-close\fP
+\fB\-C\fP | \fB–connection\-close\fP
 Force each HTTP connection to be closed after each request
 (useful in combination with \-f to avoid having to wait for nc to
 time out).
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP\fIFILENAME\fP
 Use the configuration and other resources for the merchant to
 operate from FILENAME.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-T\fP \fIUSEC\fP | \fB\-\-timetravel=\fP\fIUSEC\fP
+\fB\-T\fP \fIUSEC\fP | \fB–timetravel=\fP\fIUSEC\fP
 Modify the system time by \fIUSEC\fP microseconds.
 \fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
 This option is intended for debugging/testing only.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SIGNALS
@@ -100,7 +100,7 @@ cleanly.
 .INDENT 0.0
 .TP
 .B TALER_MERCHANT_TOKEN
-Like the \(dq\-a\(dq option, resets the access token for the default
+Like the “\-a” option, resets the access token for the default
 instance to the given value.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-merchant-setup-reserve.1 b/man/taler-merchant-setup-reserve.1
index d1f62e36..eeff17b3 100644
--- a/man/taler-merchant-setup-reserve.1
+++ b/man/taler-merchant-setup-reserve.1
@@ -27,26 +27,26 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-MERCHANT-SETUP-RESERVE" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-MERCHANT-SETUP-RESERVE" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-merchant-setup-reserve \- setup reserve for rewards at a Taler merchant backend
 .SH SYNOPSIS
 .sp
 \fBtaler\-merchant\-setup\-reserve\fP
-[\fB\-A\fP\ \fIUSERNAME:PASSWORD\fP\ |\ \fB\-\-auth=\fP\fIUSERNAME:PASSWORD\fP]
-[\fB\-a\fP\ \fIVALUE\fP\ |\ \fB\-\-amount=\fP\fIVALUE\fP]
-[\fB\-C\fP\ \fICERTFILE\fP\ |\ \fB\-\-cert=\fP\fICERTFILE\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP\fIFILENAME\fP]
-[\fB\-e\fP\ \fIURL\fP\ |\ \fB\-\-exchange\-url=\fP\fIURL\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-k\fP\ \fIKEYFILE\fP\ |\ \fB\-\-key=\fP\fIKEYFILE\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-m\fP\ \fIURL\fP\ |\ \fB\-\-merchant\-url=\fP\fIURL\fP]
-[\fB\-p\fP\ \fIKEYFILEPASSPHRASE\fP\ |\ \fB\-\-pass=\fP\fIKEYFILEPASSPHRASE\fP]
-[\fB\-t\fP\ \fICERTTYPE\fP\ |\ \fB\-\-type=\fP\fICERTTYPE\fP]
-[\fB\-w\fP\ \fIMETHOD\fP\ |\ \fB\-\-wire\-method=\fP\fIMETHOD\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-A\fP\ \fIUSERNAME:PASSWORD\fP\ |\ \fB–auth=\fP\fIUSERNAME:PASSWORD\fP]
+[\fB\-a\fP\ \fIVALUE\fP\ |\ \fB–amount=\fP\fIVALUE\fP]
+[\fB\-C\fP\ \fICERTFILE\fP\ |\ \fB–cert=\fP\fICERTFILE\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP\fIFILENAME\fP]
+[\fB\-e\fP\ \fIURL\fP\ |\ \fB–exchange\-url=\fP\fIURL\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-k\fP\ \fIKEYFILE\fP\ |\ \fB–key=\fP\fIKEYFILE\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIURL\fP\ |\ \fB–merchant\-url=\fP\fIURL\fP]
+[\fB\-p\fP\ \fIKEYFILEPASSPHRASE\fP\ |\ \fB–pass=\fP\fIKEYFILEPASSPHRASE\fP]
+[\fB\-t\fP\ \fICERTTYPE\fP\ |\ \fB–type=\fP\fICERTTYPE\fP]
+[\fB\-w\fP\ \fIMETHOD\fP\ |\ \fB–wire\-method=\fP\fIMETHOD\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-merchant\-setup\-reserve\fP is a command\-line tool to setup a reserve
@@ -55,68 +55,68 @@ from the exchange needed to fill the reserve.
 .SH OPTIONS
 .INDENT 0.0
 .TP
-\fB\-A\fP \fIUSERNAME:PASSWORD\fP | \fB\-\-auth=\fP\fIUSERNAME:PASSWORD\fP
+\fB\-A\fP \fIUSERNAME:PASSWORD\fP | \fB–auth=\fP\fIUSERNAME:PASSWORD\fP
 Use \fBUSERNAME\fP and \fBPASSWORD\fP for HTTP client authentication.
-The \(dq:\(dq must be present as a separator.
+The “:” must be present as a separator.
 Note that this form of authentication has nothing to do with the TLS client
 certificate authentication supported with the \fB\-C\fP, \fB\-k\fP and \fB\-p\fP options.
 The \fBPASSWORD\fP given to this option is given to the server!
 .TP
-\fB\-a\fP \fIVALUE\fP | \fB\-\-amount=\fP\fIVALUE\fP
+\fB\-a\fP \fIVALUE\fP | \fB–amount=\fP\fIVALUE\fP
 Mandatory.
 Amount to be transferred to the reserve.
 .TP
-\fB\-C\fP \fICERTFILE\fP | \fB\-\-cert=\fP\fICERTFILE\fP
+\fB\-C\fP \fICERTFILE\fP | \fB–cert=\fP\fICERTFILE\fP
 The specified \fBCERTFILE\fP contains a TLS client certificate to be used to
 authenticate the client. See also \fB\-t\fP\&.
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP\fIFILENAME\fP
 Use the configuration and other resources for the merchant to
 operate from \fBFILENAME\fP\&.
 .TP
-\fB\-e\fP \fIURL\fP | \fB\-\-exchange\-url=\fP\fIURL\fP
+\fB\-e\fP \fIURL\fP | \fB–exchange\-url=\fP\fIURL\fP
 Mandatory.
 Use \fBURL\fP for the exchange base URL.
 This is the exchange where the reserve will be created.
 The currency used in the amount specification must be offered by this exchange.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-k\fP \fIKEYFILE\fP | \fB\-\-key=\fP\fIKEYFILE\fP
+\fB\-k\fP \fIKEYFILE\fP | \fB–key=\fP\fIKEYFILE\fP
 The specified \fBKEYFILE\fP contains a TLS client private key to be used to
 authenticate the client. See also \fB\-p\fP and \fB\-C\fP\&.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-m\fP \fIURL\fP | \fB\-\-merchant\-url=\fP\fIURL\fP
+\fB\-m\fP \fIURL\fP | \fB–merchant\-url=\fP\fIURL\fP
 Mandatory.
 Use \fBURL\fP as the merchant base URL.
 Should include the path to the instance if the reserve is to be
 created for a non\-default instance.
 .TP
-\fB\-p\fP \fIKEYFILEPASSPHRASE\fP | \fB\-\-pass=\fP\fIKEYFILEPASSPHRASE\fP
+\fB\-p\fP \fIKEYFILEPASSPHRASE\fP | \fB–pass=\fP\fIKEYFILEPASSPHRASE\fP
 The specified \fBKEYFILEPASSPHRASE\fP is to be used to decrypt the KEYFILE.
 See also \fB\-k\fP\&. Not to be confused with \fB\-A\fP\&.
 The \fBKEYFILEPASSPHRASE\fP given here is only used locally to decrypt the KEYFILE.
 .TP
-\fB\-t\fP \fICERTTYPE\fP | \fB\-\-type=\fP\fICERTTYPE\fP
+\fB\-t\fP \fICERTTYPE\fP | \fB–type=\fP\fICERTTYPE\fP
 The specified CERTFILE contains a TLS client certificate of \fBCERTTYPE\fP\&.
 Default is \fBPEM\fP\&. See also \fB\-C\fP\&.
 .TP
-\fB\-w\fP \fIMETHOD\fP | \fB\-\-wire\-method=\fP\fIMETHOD\fP
+\fB\-w\fP \fIMETHOD\fP | \fB–wire\-method=\fP\fIMETHOD\fP
 Mandatory.
 Which wire method should be used.
 Needed to select the wire transfer method of the exchange.
 The method must be supported by the exchange.
 Typical values would be \fBiban\fP or \fBx\-taler\-bank\fP\&.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB–version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
diff --git a/man/taler-merchant-webhook.1 b/man/taler-merchant-webhook.1
index 10e30ee8..0e6eec71 100644
--- a/man/taler-merchant-webhook.1
+++ b/man/taler-merchant-webhook.1
@@ -27,18 +27,18 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-MERCHANT-WEBHOOK" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-MERCHANT-WEBHOOK" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-merchant-webhook \- execute webhooks of the Taler merchant backend (optional service)
 .SH SYNOPSIS
 .sp
 \fBtaler\-merchant\-webhook\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-t\fP\ |\ \fB\-\-test\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-t\fP\ |\ \fB–test\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-merchant\-webhook\fP is a command\-line tool to trigger webhooks
@@ -48,21 +48,21 @@ requests and updates the Taler merchant database accordingly.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-t\fP | \fB–test\fP
 Run in test mode. Only runs until there are no more webhooks
 to be executed.
 .TP
diff --git a/man/taler-merchant-wirewatch.1 b/man/taler-merchant-wirewatch.1
index ec436043..aa1c2dc3 100644
--- a/man/taler-merchant-wirewatch.1
+++ b/man/taler-merchant-wirewatch.1
@@ -27,18 +27,18 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-MERCHANT-WIREWATCH" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-MERCHANT-WIREWATCH" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-merchant-wirewatch \- import credit transactions from a merchant bank account into merchant backend (optional)
 .SH SYNOPSIS
 .sp
 \fBtaler\-merchant\-wirewatch\fP
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB\-\-config=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB\-\-logfile=\fP‌\fIFILENAME\fP]
-[\fB\-t\fP\ |\ \fB\-\-test\fP]
-[\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB–help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB–logfile=\fP‌\fIFILENAME\fP]
+[\fB\-t\fP\ |\ \fB–test\fP]
+[\fB\-v\fP\ |\ \fB–version\fP]
 .SH DESCRIPTION
 .sp
 \fBtaler\-merchant\-wirewatch\fP is a command\-line tool to import
@@ -49,26 +49,26 @@ the exchange paid the merchant correctly.
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB\-\-config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Print short help on options.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB\-\-loglevel=\fP‌\fILOGLEVEL\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
 Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
 \fBWARNING\fP, \fBERROR\fP\&.
 .TP
-\fB\-l\fP \fIFILENAME\fP | \fB\-\-logfile=\fP‌\fIFILENAME\fP
+\fB\-l\fP \fIFILENAME\fP | \fB–logfile=\fP‌\fIFILENAME\fP
 Send logging output to \fIFILENAME\fP\&.
 .TP
-\fB\-s\fP \fISECTION\fP | \fB\-\-section=\fP\fISECTION\fP
+\fB\-s\fP \fISECTION\fP | \fB–section=\fP\fISECTION\fP
 Configuration section to use. Default is taler\-merchant\-wirewatch. Needed
 if different processes are used to watch multiple bank accounts (for the
 same instance or different instances).
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-t\fP | \fB–test\fP
 Run in test mode. Only runs until the current list of bank
 transactions are all imported.
 .TP
diff --git a/man/taler-terms-generator.1 b/man/taler-terms-generator.1
index 4f2c038d..a1e5e63f 100644
--- a/man/taler-terms-generator.1
+++ b/man/taler-terms-generator.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-TERMS-GENERATOR" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-TERMS-GENERATOR" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-terms-generator \- create legal policy documents for services
 .SH SYNOPSIS
@@ -46,7 +46,7 @@ taler-terms-generator \- create legal policy documents for services
 .TP
 \fBtaler\-terms\-generator\fP is a command\-line tool to create terms of service
 and privacy policy files in various file formats and languages from a
-reStructuredText (\(dq.rst\(dq) input. It can be used to generate the responses
+reStructuredText (“.rst”) input. It can be used to generate the responses
 various GNU Taler services serve under the \fB/terms\fP and \fB/pp\fP endpoints.
 .TP
 \fB\-a\fP \fIAUTHOR\fP
@@ -55,20 +55,20 @@ set the author information to the given AUTHOR in the meta\-data of various gene
 \fB\-C\fP \fICOPYRIGHT\fP
 set the copyright information to the given COPYRIGHT in the meta\-data of various generated outputs.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Prints a compiled\-in help text.
 .TP
 \fB\-l\fP \fILANGUAGE\fP
-Add the given \fILANGUAGE\fP to the list of translations for the current \fIINPUT\fP\&. \fILANGUAGE\fP must be a two\-letter language code (like \(dqde\(dq or \(dqit\(dq). This will generate or update the respective \(dq.po\(dq files to translate the \fIINPUT\fP terms to this \fILANGUAGE\fP\&.
+Add the given \fILANGUAGE\fP to the list of translations for the current \fIINPUT\fP\&. \fILANGUAGE\fP must be a two\-letter language code (like “de” or “it”). This will generate or update the respective “.po” files to translate the \fIINPUT\fP terms to this \fILANGUAGE\fP\&.
 .TP
 \fB\-o\fP \fIOUTPUT\fP
 Specifies where to write the output. This should be the directory where the service expects to find the generated resources.  Unless you changed the default configuration, you probably do not have to specify this value.
 .TP
 \fB\-p\fP \fIPAPER\fP
-Specifies the paper format for generated PDF documents. Can be \(dqa4\(dq or \(dqletter\(dq.
+Specifies the paper format for generated PDF documents. Can be “a4” or “letter”.
 .TP
 \fB\-t\fP \fITITLE\fP
-Overrides the document title. By default, the title will be set to the contents of the first line of the \fIINPUT\fP \(dq.rst\(dq file.
+Overrides the document title. By default, the title will be set to the contents of the first line of the \fIINPUT\fP “.rst” file.
 .UNINDENT
 .SH SEE ALSO
 .sp
diff --git a/man/taler-unified-setup.1 b/man/taler-unified-setup.1
index 5c8ce4ae..4cdff356 100644
--- a/man/taler-unified-setup.1
+++ b/man/taler-unified-setup.1
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER-UNIFIED-SETUP" "1" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER-UNIFIED-SETUP" "1" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler-unified-setup \- conveniently start and stop various GNU Taler services
 .SH SYNOPSIS
@@ -67,7 +67,7 @@ Start backup/sync service
 (Mandatory) Use CONFIG_FILENAME.
 .TP
 \fB\-d\fP \fIMETHOD\fP
-use the given wire method. Default is \(aqx\-taler\-bank\(aq.
+use the given wire method. Default is ‘x\-taler\-bank’.
 .TP
 \fB\-e\fP
 Start exchange
@@ -78,7 +78,7 @@ Start fakebank
 \fB\-g\fP
 Start aggregator
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB–help\fP
 Prints a compiled\-in help text.
 .TP
 \fB\-L\fP \fILOGLEVEL\fP
diff --git a/man/taler.conf.5 b/man/taler.conf.5
index 32d2dce0..eb541d7f 100644
--- a/man/taler.conf.5
+++ b/man/taler.conf.5
@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "TALER.CONF" "5" "Sep 08, 2023" "0.9" "GNU Taler"
+.TH "TALER.CONF" "5" "Sep 24, 2023" "0.9" "GNU Taler"
 .SH NAME
 taler.conf \- Taler configuration file
 .SH DESCRIPTION
@@ -129,7 +129,7 @@ Name of the currency, e.g.\ “EUR” for Euro.
 .TP
 .B CURRENCY_ROUND_UNIT
 Smallest amount in this currency that can be transferred using the
-underlying RTGS. For example: \(dqEUR:0.01\(dq or \(dqJPY:1\(dq.
+underlying RTGS. For example: “EUR:0.01” or “JPY:1”.
 .UNINDENT
 .sp
 The “[PATHS]” section is special in that it contains paths that can be
@@ -167,27 +167,27 @@ exchange tools.
 Plugin to use for the database, e.g.\ “postgres”.
 .TP
 .B SERVE
-Should the HTTP server listen on a UNIX domain socket (set option to \(dqunix\(dq) or on a TCP socket (set option to \(dqtcp\(dq)?
+Should the HTTP server listen on a UNIX domain socket (set option to “unix”) or on a TCP socket (set option to “tcp”)?
 .TP
 .B UNIXPATH
-Path to listen on if we \(dqSERVE\(dq is set to \(dqunix\(dq.
+Path to listen on if we “SERVE” is set to “unix”.
 .TP
 .B UNIXPATH_MODE
-Access permission mask to use for the \(dqUNIXPATH\(dq.
+Access permission mask to use for the “UNIXPATH”.
 .TP
 .B PORT
 Port on which the HTTP server listens, e.g.\ 8080.
 .TP
 .B BIND_TO
-Hostname to which the exchange HTTP server should be bound to, e.g. \(dqlocalhost\(dq.
+Hostname to which the exchange HTTP server should be bound to, e.g. “localhost”.
 .TP
 .B MASTER_PUBLIC_KEY
 Crockford Base32\-encoded master public key, public version of the
-exchange\(aqs long\-time offline signing key.
+exchange’s long\-time offline signing key.
 .TP
 .B AML_THRESHOLD
 Largest amount in this currency that can be transferred per month without
-an AML staff member doing a (manual) AML check. For example: \(dqUSD:1000000\(dq.
+an AML staff member doing a (manual) AML check. For example: “USD:1000000”.
 .TP
 .B KYC_AML_TRIGGER
 Program to run on KYC attribute data to decide whether we should immediately flag an account for AML review. Program must return 0 if a manual AML review is not needed, and non\-zero to trigger an AML review. The KYC attribute data of the new user will be passed on standard\-input.
@@ -241,7 +241,7 @@ For how long should the taler\-exchange\-wirewatch sleep when it is idle
 before trying to look for more work? Default is 60 seconds.
 .TP
 .B AGGREGATOR_SHARD_SIZE
-Which share of the range from [0,..2147483648] should be processed by one of the shards of the aggregator. Useful only for Taler exchanges with ultra high\-performance needs. When changing this value, you must stop all aggregators and run \(dqtaler\-exchange\-dbinit \-s\(dq before resuming. Default is 2147483648 (no sharding).
+Which share of the range from [0,..2147483648] should be processed by one of the shards of the aggregator. Useful only for Taler exchanges with ultra high\-performance needs. When changing this value, you must stop all aggregators and run “taler\-exchange\-dbinit \-s” before resuming. Default is 2147483648 (no sharding).
 .TP
 .B SIGNKEY_LEGAL_DURATION
 For how long are signatures with signing keys legally valid?
@@ -255,12 +255,12 @@ How many requests should the HTTP server process at most before committing suici
 .B TERMS_DIR
 Directory where the terms of service of the exchange operator can be fund.
 The directory must contain sub\-directories for every supported language,
-using the two\-character language code in lower case, e.g. \(dqen/\(dq or \(dqfr/\(dq.
+using the two\-character language code in lower case, e.g. “en/” or “fr/”.
 Each subdirectory must then contain files with the terms of service in
 various formats.  The basename of the file of the current policy must be
 specified under \fBTERMS_ETAG\fP\&.  The extension defines the mime type.
-Supported extensions include \(dqhtml\(dq, \(dqhtm\(dq, \(dqtxt\(dq, \(dqpdf\(dq, \(dqjpg\(dq, \(dqjpeg\(dq,
-\(dqpng\(dq and \(dqgif\(dq.  For example, using a \fBTERMS_ETAG\fP of \(dq0\(dq, the structure
+Supported extensions include “html”, “htm”, “txt”, “pdf”, “jpg”, “jpeg”,
+“png” and “gif”.  For example, using a \fBTERMS_ETAG\fP of “0”, the structure
 could be the following:
 .INDENT 7.0
 .IP \(bu 2
@@ -279,7 +279,7 @@ $TERMS_DIR/de/0.txt
 .TP
 .B TERMS_ETAG
 Basename of the file(s) in the \fBTERMS_DIR\fP with the current terms of service.
-The value is also used for the \(dqEtag\(dq in the HTTP request to control
+The value is also used for the “Etag” in the HTTP request to control
 caching.  Whenever the terms of service change, the \fBTERMS_ETAG\fP MUST also
 change, and old values MUST NOT be repeated.  For example, the date or
 version number of the terms of service SHOULD be used for the Etag.  If
@@ -295,7 +295,7 @@ Works the same as \fBTERMS_ETAG\fP, just for the privacy policy.
 .UNINDENT
 .SS EXCHANGE KYC PROVIDER OPTIONS
 .sp
-The following options must be in the section \(dq[kyc\-provider\-XXX]\(dq sections.
+The following options must be in the section “[kyc\-provider\-XXX]” sections.
 .INDENT 0.0
 .TP
 .B COST
@@ -312,20 +312,20 @@ List of checks performed by this provider. Space\-separated names of checks, mus
 .UNINDENT
 .SS EXCHANGE KYC OAUTH2 OPTIONS
 .sp
-The following options must be in the section \(dq[kyc\-provider\-XXX]\(dq sections with \(dqLOGIC = oauth2\(dq.
+The following options must be in the section “[kyc\-provider\-XXX]” sections with “LOGIC = oauth2”.
 .INDENT 0.0
 .TP
 .B KYC_OAUTH2_VALIDITY
-Duration (e.g. \(dq12 months\(dq) of the validity of the performed KYC check. Can be \(dqforever\(dq.
+Duration (e.g. “12 months”) of the validity of the performed KYC check. Can be “forever”.
 .TP
 .B KYC_OAUTH2_AUTHORIZE_URL
-URL of the OAuth2 endpoint to be used for KYC checks. The authorize URL is where the exchange will redirect the client to begin the authorization process.  Example: \(dq\fI\%http://localhost:8888/oauth/v2/authorize\fP\(dq. To use the plugin in combination with the Challenger service\(aqs \fB/setup\fP step, append \(dq#setup\(dq, thus \(dq\fI\%https://challenger.example.com/authorize#setup\fP\(dq.  Here, \(dq#setup\(dq is not a fragment but merely a hint to the logic to determine the full authorization URL via the \fB/setup\fP handler.
+URL of the OAuth2 endpoint to be used for KYC checks. The authorize URL is where the exchange will redirect the client to begin the authorization process.  Example: “\fI\%http://localhost:8888/oauth/v2/authorize\fP”. To use the plugin in combination with the Challenger service’s \fB/setup\fP step, append “#setup”, thus “\fI\%https://challenger.example.com/authorize#setup\fP”.  Here, “#setup” is not a fragment but merely a hint to the logic to determine the full authorization URL via the \fB/setup\fP handler.
 .TP
 .B KYC_OAUTH2_TOKEN_URL
-URL of the OAuth2 endpoint to be used for KYC checks. This is where the server will ultimately send the authorization token from the client and obtain its access token (which currently must be a \(dqbearer\(dq token). Example: \(dq\fI\%http://localhost:8888/oauth/v2/token\fP\(dq (or just \(dq/token\(dq)
+URL of the OAuth2 endpoint to be used for KYC checks. This is where the server will ultimately send the authorization token from the client and obtain its access token (which currently must be a “bearer” token). Example: “\fI\%http://localhost:8888/oauth/v2/token\fP” (or just “/token”)
 .TP
 .B KYC_OAUTH2_INFO_URL
-URL of the OAuth2\-protected resource endpoint, where the OAuth 2.0 token can be used to download information about the user that has undergone the KYC process. The exchange will use the access token obtained from the KYC_AUTH2_AUTH_URL to show that it is authorized to obtain the details. Example: \(dq\fI\%http://localhost:8888/api/user/me\fP\(dq or \(dq\fI\%http://localhost:8888/oauth/v2/info\fP\(dq
+URL of the OAuth2\-protected resource endpoint, where the OAuth 2.0 token can be used to download information about the user that has undergone the KYC process. The exchange will use the access token obtained from the KYC_AUTH2_AUTH_URL to show that it is authorized to obtain the details. Example: “\fI\%http://localhost:8888/api/user/me\fP” or “\fI\%http://localhost:8888/oauth/v2/info\fP”
 .TP
 .B KYC_OAUTH2_CLIENT_ID
 Client ID of the exchange when it talks to the KYC OAuth2 endpoint.
@@ -334,15 +334,15 @@ Client ID of the exchange when it talks to the KYC OAuth2 endpoint.
 Client secret of the exchange to use when talking to the KYC Oauth2 endpoint.
 .TP
 .B KYC_OAUTH2_POST_URL
-URL to which the exchange will redirect the client\(aqs browser after successful authorization/login for the KYC process. Example: \(dq\fI\%http://example.com/thank\-you\fP\(dq
+URL to which the exchange will redirect the client’s browser after successful authorization/login for the KYC process. Example: “\fI\%http://example.com/thank\-you\fP”
 .UNINDENT
 .SS EXCHANGE KYC KYCAID OPTIONS
 .sp
-The following options must be in the section \(dq[kyc\-provider\-XXX]\(dq sections with \(dqLOGIC = kycaid\(dq.
+The following options must be in the section “[kyc\-provider\-XXX]” sections with “LOGIC = kycaid”.
 .INDENT 0.0
 .TP
 .B KYC_KYCAID_VALIDITY
-Duration (e.g. \(dq12 months\(dq) of the validity of the performed KYC check. Can be \(dqforever\(dq.
+Duration (e.g. “12 months”) of the validity of the performed KYC check. Can be “forever”.
 .TP
 .B KYC_KYCAID_AUTH_TOKEN
 Authentication token to access the KYC service.
@@ -351,15 +351,15 @@ Authentication token to access the KYC service.
 ID that specifies the form to use for the KYC process.
 .TP
 .B KYC_KYCAID_POST_URL
-URL to which the exchange will redirect the client\(aqs browser after successful authorization/login for the KYC process.
+URL to which the exchange will redirect the client’s browser after successful authorization/login for the KYC process.
 .UNINDENT
 .SS EXCHANGE KYC PERSONA OPTIONS
 .sp
-The following options must be in the section \(dq[kyc\-provider\-XXX]\(dq sections with \(dqLOGIC = persona\(dq.
+The following options must be in the section “[kyc\-provider\-XXX]” sections with “LOGIC = persona”.
 .INDENT 0.0
 .TP
 .B KYC_PERSONA_VALIDITY
-Duration (e.g. \(dq12 months\(dq) of the validity of the performed KYC check. Can be \(dqforever\(dq.
+Duration (e.g. “12 months”) of the validity of the performed KYC check. Can be “forever”.
 .TP
 .B KYC_PERSONA_AUTH_TOKEN
 Authentication token to access the KYC service.
@@ -371,17 +371,17 @@ Salt value to use for request idempotency. Optional, generated at random per pro
 Subdomain to use under Persona.
 .TP
 .B KYC_PERSONA_CONVERTER_HELPER
-Helper to convert JSON with KYC data returned by Persona into GNU Taler internal format. Should probably always be set to \(dqtaler\-exchange\-kyc\-persona\-converter.sh\(dq.
+Helper to convert JSON with KYC data returned by Persona into GNU Taler internal format. Should probably always be set to “taler\-exchange\-kyc\-persona\-converter.sh”.
 .TP
 .B KYC_PERSONA_POST_URL
-URL to which the exchange will redirect the client\(aqs browser after successful authorization/login for the KYC process.
+URL to which the exchange will redirect the client’s browser after successful authorization/login for the KYC process.
 .TP
 .B KYC_PERSONA_TEMPLATE_ID
 ID of the Persona template to use.
 .UNINDENT
 .SS EXCHANGE KYC PERSONA GLOBAL OPTIONS
 .sp
-The following option must be in the section \(dq[kyclogic\-persona]\(dq.
+The following option must be in the section “[kyclogic\-persona]”.
 .INDENT 0.0
 .TP
 .B WEBHOOK_AUTH_TOKEN
@@ -393,7 +393,7 @@ The functionality of the exchange can be extended by extensions.  Those are
 shared libraries which implement the extension\-API of the exchange and are
 located under \fB$LIBDIR\fP, starting with prefix \fBlibtaler_extension_\fP\&. Each
 extension can be enabled by adding a dedicated section
-\(dq[exchange\-extension\-<extensionname>]\(dq and the following option:
+“[exchange\-extension\-<extensionname>]” and the following option:
 .INDENT 0.0
 .TP
 .B ENABLED
@@ -403,7 +403,7 @@ options might be set in the same section.
 .SS EXCHANGE EXTENSION FOR AGE RESTRICTION
 .sp
 The extension for age restriction support can be enabled by adding a section
-\(dq[exchange\-extension\-age_restriction]\(dq with the following options:
+“[exchange\-extension\-age_restriction]” with the following options:
 .INDENT 0.0
 .TP
 .B ENABLE
@@ -412,8 +412,8 @@ Must be set to \fBYES\fP in order to activate the extension.
 .B AGE_GROUPS
 A colon\-seperated string of increasing non\-negative integers, defining the
 buckets of age groups supported by the exchange.  Each integer marks the
-beginning of the next age group.  The zero\(aqth age group implicitly starts
-with 0.  For example, the string \(dq10:18\(dq would define three age groups:
+beginning of the next age group.  The zero’th age group implicitly starts
+with 0.  For example, the string “10:18” would define three age groups:
 .INDENT 7.0
 .INDENT 3.5
 .INDENT 0.0
@@ -427,7 +427,7 @@ Group 2: ages 18 and above
 .UNINDENT
 .UNINDENT
 .sp
-If not provided, the default value is \(dq8:10:12:14:16:18:21\(dq.
+If not provided, the default value is “8:10:12:14:16:18:21”.
 .UNINDENT
 .sp
 \fBNote\fP: Age restriction is bound to specific denominations and must be
@@ -436,7 +436,7 @@ the option \fBAGE_RESTRICTED = YES\fP, see \fI\%EXCHANGE COIN OPTIONS\fP\&. Howe
 age groups are defined globally for all denominations.
 .SS EXCHANGE OFFLINE SIGNING OPTIONS
 .sp
-The following options must be in the section \(dq[exchange\-offline]\(dq.
+The following options must be in the section “[exchange\-offline]”.
 .INDENT 0.0
 .TP
 .B MASTER_PRIV_FILE
@@ -463,7 +463,7 @@ this option will also be ignored.
 .UNINDENT
 .SS EXCHANGE RSA CRYPTO HELPER OPTIONS
 .sp
-The following options must be in the section \(dq[taler\-exchange\-secmod\-rsa]\(dq.
+The following options must be in the section “[taler\-exchange\-secmod\-rsa]”.
 .INDENT 0.0
 .TP
 .B LOOKAHEAD_SIGN
@@ -490,7 +490,7 @@ Note that the \fBtaler\-exchange\-secmod\-rsa\fP also evaluates the \fB[coin_*]\
 configuration sections described below.
 .SS EXCHANGE CS CRYPTO HELPER OPTIONS
 .sp
-The following options must be in the section \(dq[taler\-exchange\-secmod\-cs]\(dq.
+The following options must be in the section “[taler\-exchange\-secmod\-cs]”.
 .INDENT 0.0
 .TP
 .B LOOKAHEAD_SIGN
@@ -517,7 +517,7 @@ Note that the \fBtaler\-exchange\-secmod\-cs\fP also evaluates the \fB[coin_*]\f
 configuration sections described below.
 .SS EXCHANGE EDDSA CRYPTO HELPER OPTIONS
 .sp
-The following options must be in the section \(dq[taler\-exchange\-secmod\-eddsa]\(dq.
+The following options must be in the section “[taler\-exchange\-secmod\-eddsa]”.
 .INDENT 0.0
 .TP
 .B LOOKAHEAD_SIGN
@@ -544,7 +544,7 @@ On which path should the security module listen for signing requests?
 .UNINDENT
 .SS EXCHANGE DATABASE OPTIONS
 .sp
-The following options must be in the section \(dq[exchangedb]\(dq.
+The following options must be in the section “[exchangedb]”.
 .INDENT 0.0
 .TP
 .B IDLE_RESERVE_EXPIRATION_TIME
@@ -605,7 +605,7 @@ URL of the wire gateway.  Typically of the form
 \fBhttps://$HOSTNAME[:$PORT]/taler\-wire\-gateway/$USERNAME/\fP
 where $HOSTNAME is the hostname of the system running the bank
 (such as the Taler Python bank or the Nexus) and \fB$USERNAME\fP is
-the username of the exchange\(aqs bank account (usually matching
+the username of the exchange’s bank account (usually matching
 the \fBUSERNAME\fP option used for authentication).  Example:
 \fBhttps://bank.demo.taler.net/taler\-wire\-gateway/Exchange/\fP\&.
 .TP
@@ -660,12 +660,12 @@ What fee is charged for refunds? When a coin is refunded, the deposit
 fee is returned. Instead, the refund fee is charged to the customer.
 .TP
 .B CIPHER
-What cryptosystem should be used? Must be set to either \(dqCS\(dq or \(dqRSA\(dq.
+What cryptosystem should be used? Must be set to either “CS” or “RSA”.
 The respective crypto\-helper will then generate the keys for this
 denomination.
 .TP
 .B RSA_KEYSIZE
-What is the RSA keysize modulos (in bits)?  Only used if \(dqCIPHER=RSA\(dq.
+What is the RSA keysize modulos (in bits)?  Only used if “CIPHER=RSA”.
 .TP
 .B AGE_RESTRICTED
 Setting this option to \fBYES\fP marks the denomination as age restricted
@@ -682,19 +682,19 @@ merchant backend.
 Plugin to use for the database, e.g._“postgres”.
 .TP
 .B SERVE
-Should the HTTP server listen on a UNIX domain socket (set option to \(dqunix\(dq) or on a TCP socket (set option to \(dqtcp\(dq)?
+Should the HTTP server listen on a UNIX domain socket (set option to “unix”) or on a TCP socket (set option to “tcp”)?
 .TP
 .B UNIXPATH
-Path to listen on if we \(dqSERVE\(dq is set to \(dqunix\(dq.
+Path to listen on if we “SERVE” is set to “unix”.
 .TP
 .B UNIXPATH_MODE
-Access permission mask to use for the \(dqUNIXPATH\(dq.
+Access permission mask to use for the “UNIXPATH”.
 .TP
 .B PORT
 Port on which the HTTP server listens, e.g.\ 8080.
 .TP
 .B BIND_TO
-Hostname to which the merchant HTTP server should be bound to, e.g. \(dqlocalhost\(dq.
+Hostname to which the merchant HTTP server should be bound to, e.g. “localhost”.
 .TP
 .B LEGAL_PRESERVATION
 How long do we keep data in the database for tax audits after the
@@ -729,7 +729,7 @@ Base URL of the exchange, e.g.\ “\fI\%https://exchange.demo.taler.net/\fP”
 .TP
 .B MASTER_KEY
 Crockford Base32 encoded master public key, public version of the
-exchange\(aqs long\-time offline signing key.  Can be omitted, in that
+exchange’s long\-time offline signing key.  Can be omitted, in that
 case the exchange will NOT be trusted unless it is audited by
 a known auditor.
 Omitting \fBMASTER_KEY\fP can be useful if we do not trust the exchange
@@ -762,19 +762,19 @@ processes that do not have access to the (offline) auditor private key file.
 Base URL of the auditor, e.g.\ “\fI\%https://auditor.demo.taler.net/\fP”
 .TP
 .B SERVE
-Should the HTTP server listen on a UNIX domain socket (set option to \(dqunix\(dq) or on a TCP socket (set option to \(dqtcp\(dq)?
+Should the HTTP server listen on a UNIX domain socket (set option to “unix”) or on a TCP socket (set option to “tcp”)?
 .TP
 .B UNIXPATH
-Path to listen on if we \(dqSERVE\(dq is set to \(dqunix\(dq.
+Path to listen on if we “SERVE” is set to “unix”.
 .TP
 .B UNIXPATH_MODE
-Access permission mask to use for the \(dqUNIXPATH\(dq.
+Access permission mask to use for the “UNIXPATH”.
 .TP
 .B PORT
 Port on which the HTTP server listens, e.g.\ 8080.
 .TP
 .B BIND_TO
-Hostname to which the merchant HTTP server should be bound to, e.g. \(dqlocalhost\(dq.
+Hostname to which the merchant HTTP server should be bound to, e.g. “localhost”.
 .UNINDENT
 .SS AUDITOR POSTGRES BACKEND DATABASE OPTIONS
 .sp
@@ -783,12 +783,12 @@ The following options must be in section “[auditordb\-postgres]” if the
 .INDENT 0.0
 .TP
 .B CONFIG
-How to access the database, e.g.\ \(dqpostgres:///taler\(dq to use the
-\(dqtaler\(dq database. Testcases use “talercheck”.
+How to access the database, e.g.\ “postgres:///taler” to use the
+“taler” database. Testcases use “talercheck”.
 .UNINDENT
 .SS Bank Options
 .sp
-The following options must be in section \(dq[bank]\(dq for the taler\-fakebank\-run(1) command. They are not used by the exchange or LibEuFin!
+The following options must be in section “[bank]” for the taler\-fakebank\-run(1) command. They are not used by the exchange or LibEuFin!
 .INDENT 0.0
 .TP
 .B HTTP_PORT
diff --git a/texinfo/challenger.texi b/texinfo/challenger.texi
new file mode 100644
index 00000000..47f37ba9
--- /dev/null
+++ b/texinfo/challenger.texi
@@ -0,0 +1,1239 @@
+\input texinfo   @c -*-texinfo-*-
+@c %**start of header
+@setfilename challenger.info
+@documentencoding UTF-8
+@ifinfo
+@*Generated by Sphinx 5.3.0.@*
+@end ifinfo
+@settitle Taler Challenger Manual
+@defindex ge
+@paragraphindent 0
+@exampleindent 4
+@finalout
+@dircategory CATEGORY
+@direntry
+* MENU ENTRY: (challenger.info). DESCRIPTION
+@end direntry
+
+@c %**end of header
+
+@copying
+@quotation
+GNU Taler 0.9.0, Sep 24, 2023
+
+GNU Taler team
+
+Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+@end quotation
+
+@end copying
+
+@titlepage
+@title Taler Challenger Manual
+@insertcopying
+@end titlepage
+@contents
+
+@c %** start of user preamble
+
+@c %** end of user preamble
+
+@ifnottex
+@node Top
+@top Taler Challenger Manual
+@insertcopying
+@end ifnottex
+
+@c %**start of body
+@anchor{taler-challenger-manual doc}@anchor{0}
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
+@c @author Florian Dold
+
+@menu
+* Introduction:: 
+* Installation:: 
+* Configuration Fundamentals:: 
+* Deployment:: 
+
+@detailmenu
+ --- The Detailed Node Listing ---
+
+Introduction
+
+* About Challenger:: 
+* About this manual:: 
+* Architecture overview:: 
+
+Installation
+
+* Installing from source:: 
+* Installing the Challenger binary packages on Debian:: 
+* Installing the GNU Taler binary packages on Trisquel:: 
+* Installing the GNU Taler binary packages on Ubuntu:: 
+* Services@comma{} users@comma{} groups and file system hierarchy: Services users groups and file system hierarchy. 
+
+Configuration Fundamentals
+
+* Configuration format:: 
+* Fundamental Setup; Address validation: Fundamental Setup Address validation. 
+* Legal conditions for using the service:: 
+* Terms of Service:: 
+* Privacy Policy:: 
+* Legal policies directory layout:: 
+* Generating the Legal Terms:: 
+* Adding translations:: 
+* Updating legal documents:: 
+* Database Configuration:: 
+
+Legal policies directory layout
+
+* Example:: 
+
+Deployment
+
+* Serving:: 
+* Reverse Proxy Setup:: 
+* Launching Challenger:: 
+* Authorizing clients:: 
+* OAuth 2.0 integration: OAuth 2 0 integration. 
+* Database management:: 
+
+@end detailmenu
+@end menu
+
+@node Introduction,Installation,Top,Top
+@anchor{taler-challenger-manual gnu-taler-challenger-operator-manual}@anchor{1}@anchor{taler-challenger-manual introduction}@anchor{2}
+@chapter Introduction
+
+
+@menu
+* About Challenger:: 
+* About this manual:: 
+* Architecture overview:: 
+
+@end menu
+
+@node About Challenger,About this manual,,Introduction
+@anchor{taler-challenger-manual about-challenger}@anchor{3}
+@section About Challenger
+
+
+Challenger is an OAuth 2.0-compatible address validation service.
+By redirecting a user-agent to a Challenger service a client can
+have Challenger validate that the user is able to receive messages
+at a particular address and obtain that address via the @code{/info}
+endpoint.
+
+@node About this manual,Architecture overview,About Challenger,Introduction
+@anchor{taler-challenger-manual about-this-manual}@anchor{4}
+@section About this manual
+
+
+This manual targets system administrators who want to install,
+operate or integrate a challenger service.  To report issues
+or learn about known limitations, please check our
+bug tracker@footnote{https://bugs.taler.net}.
+
+@node Architecture overview,,About this manual,Introduction
+@anchor{taler-challenger-manual architecture-overview}@anchor{5}
+@section Architecture overview
+
+
+TBC.
+
+@node Installation,Configuration Fundamentals,Introduction,Top
+@anchor{taler-challenger-manual challengerinstallation}@anchor{6}@anchor{taler-challenger-manual installation}@anchor{7}
+@chapter Installation
+
+
+In this guide’s shell-session fragments, the command prompt shows two pieces
+of information:
+
+
+@itemize *
+
+@item 
+Who is performing the command
+(@code{$user} vs @code{root}, and ending character @code{$} vs @code{#}).
+@end itemize
+
+@menu
+* Installing from source:: 
+* Installing the Challenger binary packages on Debian:: 
+* Installing the GNU Taler binary packages on Trisquel:: 
+* Installing the GNU Taler binary packages on Ubuntu:: 
+* Services@comma{} users@comma{} groups and file system hierarchy: Services users groups and file system hierarchy. 
+
+@end menu
+
+@node Installing from source,Installing the Challenger binary packages on Debian,,Installation
+@anchor{taler-challenger-manual installing-from-source}@anchor{8}
+@section Installing from source
+
+
+The following instructions will show how to install libgnunetutil and
+the core GNU Taler libraries from source.
+
+The package sources can be find in our
+download directory@footnote{http://ftpmirror.gnu.org/taler/}.
+
+GNU Taler components version numbers follow the @code{MAJOR.MINOR.MICRO} format.
+The general rule for compatibility is that @code{MAJOR} and @code{MINOR} must match.
+Exceptions to this general rule are documented in the release notes.
+For example, Challenger 1.3.0 should be compatible with Taler exchange 1.4.x
+as the MAJOR version matches.  A MAJOR version of 0 indicates experimental
+development, and you are expected to always run all of the `latest' releases
+together (no compatibility guarantees).
+
+First, the following packages need to be installed before we can compile the
+backend:
+
+
+@itemize -
+
+@item 
+“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
+on Debian-based systems (for GNUnet documentation support, can be
+omitted if GNUnet is configured with @code{--disable-documentation})
+
+@item 
+libsqlite3 >= 3.16.2
+
+@item 
+GNU libunistring >= 0.9.3
+
+@item 
+libcurl >= 7.26 (or libgnurl >= 7.26)
+
+@item 
+libqrencode >= 4.0.0 (Taler merchant only)
+
+@item 
+GNU libgcrypt >= 1.6 (1.10 or later highly recommended)
+
+@item 
+libsodium >= 1.0
+
+@item 
+libargon2 >= 20171227
+
+@item 
+libjansson >= 2.7
+
+@item 
+PostgreSQL >= 13, including libpq
+
+@item 
+GNU libmicrohttpd >= 0.9.71
+
+@item 
+GNUnet >= 0.19 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
+
+@item 
+Python3 with @code{jinja2}
+@end itemize
+
+If you are on Debian stable or later, the following command may help you
+install these dependencies:
+
+@example
+# apt-get install \
+  libqrencode-dev \
+  libsqlite3-dev \
+  libltdl-dev \
+  libunistring-dev \
+  libsodium-dev \
+  libargon2-dev \
+  libcurl4-gnutls-dev \
+  libgcrypt20-dev \
+  libjansson-dev \
+  libpq-dev \
+  libmicrohttpd-dev \
+  python3-jinja2 \
+  postgresql-13
+@end example
+
+Before you install GNUnet, you must download and install the dependencies
+mentioned in the previous section, otherwise the build may succeed, but could
+fail to export some of the tooling required by GNU Taler.
+
+To install GNUnet, unpack the tarball and change
+into the resulting directory, then proceed as follows:
+
+@example
+$ ./configure [--prefix=GNUNETPFX]
+$ # Each dependency can be fetched from non standard locations via
+$ # the '--with-<LIBNAME>' option. See './configure --help'.
+$ make
+# make install
+# ldconfig
+@end example
+
+If you did not specify a prefix, GNUnet will install to @code{/usr/local},
+which requires you to run the last step as @code{root}.
+The @code{ldconfig} command (also run as @code{root}) makes the
+shared object libraries (@code{.so} files)
+visible to the various installed programs.
+
+Please note that unlike most packages, if you want to run the @code{make check}
+command, you should run it only `after' having done @code{make install}.  The
+latter ensures that necessary binaries are copied to the right place.
+
+In any case, if @code{make check} fails, please consider filing a
+bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
+
+There is no need to actually run a GNUnet peer or a Taler exchange to use
+Challenger – all Challenger needs from GNUnet and Taler are a number of
+headers and libraries!
+
+After installing GNUnet, unpack the GNU Taler exchange tarball,
+change into the resulting directory, and proceed as follows:
+
+@example
+$ ./configure [--prefix=EXCHANGEPFX] \
+              [--with-gnunet=GNUNETPFX]
+$ # Each dependency can be fetched from non standard locations via
+$ # the '--with-<LIBNAME>' option. See './configure --help'.
+$ make
+# make install
+@end example
+
+If you did not specify a prefix, the exchange will install to @code{/usr/local},
+which requires you to run the last step as @code{root}.  You have to specify
+@code{--with-gnunet=/usr/local} if you installed GNUnet to @code{/usr/local} in the
+previous step.
+
+TBD.
+
+Please note that unlike most packages, if you want to run the @code{make check}
+command, you should run it only `after' having done @code{make install}.  The
+latter ensures that necessary binaries are copied to the right place.
+
+In any case, if @code{make check} fails, please consider filing a
+bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
+
+@node Installing the Challenger binary packages on Debian,Installing the GNU Taler binary packages on Trisquel,Installing from source,Installation
+@anchor{taler-challenger-manual installing-the-challenger-binary-packages-on-debian}@anchor{9}
+@section Installing the Challenger binary packages on Debian
+
+
+To install the GNU Taler Debian packages, first ensure that you have
+the right Debian distribution. At this time, the packages are built for
+Debian bookworm.
+
+You need to add a file to import the GNU Taler packages. Typically,
+this is done by adding a file @code{/etc/apt/sources.list.d/taler.list} that
+looks like this:
+
+@example
+deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/debian stable main
+@end example
+
+Next, you must import the Taler Systems SA public package signing key
+into your keyring and update the package lists:
+
+@example
+# wget -O /etc/apt/keyrings/taler-systems.gpg \
+    https://taler.net/taler-systems.gpg
+# apt update
+@end example
+
+@cartouche
+@quotation Note 
+You may want to verify the correctness of the Taler Systems SA key out-of-band.
+@end quotation
+@end cartouche
+
+Now your system is ready to install the official GNU Taler binary packages
+using apt.
+
+To install the Challenger, you can now simply run:
+
+@example
+# apt install challenger
+@end example
+
+Note that the package does not perform any configuration work except for
+setting up the various users and the systemd service scripts. You still must
+configure at least the database, HTTP reverse proxy (typically with TLS
+certificates) and the terms of service.
+
+@node Installing the GNU Taler binary packages on Trisquel,Installing the GNU Taler binary packages on Ubuntu,Installing the Challenger binary packages on Debian,Installation
+@anchor{taler-challenger-manual installing-the-gnu-taler-binary-packages-on-trisquel}@anchor{a}
+@section Installing the GNU Taler binary packages on Trisquel
+
+
+To install the GNU Taler Trisquel packages, first ensure that you have
+the right Trisquel distribution. Packages are currently available for
+Trisquel GNU/Linux 10.0.  Simply follow the same instructions provided
+for Ubuntu.
+
+@node Installing the GNU Taler binary packages on Ubuntu,Services users groups and file system hierarchy,Installing the GNU Taler binary packages on Trisquel,Installation
+@anchor{taler-challenger-manual installing-the-gnu-taler-binary-packages-on-ubuntu}@anchor{b}
+@section Installing the GNU Taler binary packages on Ubuntu
+
+
+To install the GNU Taler Ubuntu packages, first ensure that you have
+the right Ubuntu distribution. At this time, the packages are built for
+Ubuntu Kinetic and Ubuntu Jammy. Make sure to have @code{universe} in your
+@code{/etc/apt/sources.list} (after @code{main}) as we depend on some packages
+from Ubuntu @code{universe}.
+
+A typical @code{/etc/apt/sources.list.d/taler.list} file for this setup
+would look like this:
+
+@example
+deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ stable main
+@end example
+
+The last line is crucial, as it adds the GNU Taler packages.
+
+Next, you must import the Taler Systems SA public package signing key
+into your keyring and update the package lists:
+
+@example
+# wget -O /etc/apt/keyrings/taler-systems.gpg \
+    https://taler.net/taler-systems.gpg
+# apt update
+@end example
+
+@cartouche
+@quotation Note 
+You may want to verify the correctness of the Taler Systems key out-of-band.
+@end quotation
+@end cartouche
+
+Now your system is ready to install the official GNU Taler binary packages
+using apt.
+
+To install the Taler exchange, you can now simply run:
+
+@example
+# apt install challenger
+@end example
+
+Note that the package does not perform any configuration work except for
+setting up the various users and the systemd service scripts. You still must
+configure at least the database, HTTP reverse proxy (typically with TLS
+certificates), and the terms of service.
+
+@node Services users groups and file system hierarchy,,Installing the GNU Taler binary packages on Ubuntu,Installation
+@anchor{taler-challenger-manual services-users-groups-and-file-system-hierarchy}@anchor{c}
+@section Services, users, groups and file system hierarchy
+
+
+The `challenger' package will use several system users
+to compartmentalize different parts of the system:
+
+
+@itemize *
+
+@item 
+@code{challenger-httpd}: runs the HTTP daemon with the core business logic.
+
+@item 
+@code{postgres}: runs the PostgreSQL database (from `postgresql' package).
+
+@item 
+@code{www-data}: runs the frontend HTTPS service with the TLS keys (from `nginx' package).
+@end itemize
+
+The package will deploy a systemd service files in
+@code{/usr/lib/systemd/system/} for Challenger:
+
+
+@itemize *
+
+@item 
+@code{challenger-httpd.service}: the Challenger logic with the public REST API.
+@end itemize
+
+@node Configuration Fundamentals,Deployment,Installation,Top
+@anchor{taler-challenger-manual configuration-fundamentals}@anchor{d}
+@chapter Configuration Fundamentals
+
+
+This chapter provides fundamental details about the exchange configuration.
+
+The configuration for all Taler components uses a single configuration file
+as entry point: @code{/etc/challenger/challenger.conf}.
+
+System defaults are automatically loaded from files in
+@code{/usr/share/challenger/config.d}.  These default files should never be modified.
+
+The default configuration @code{challenger.conf} configuration file also includes all
+configuration files in @code{/etc/challenger/conf.d}.
+
+To view the entire configuration annotated with the source of each configuration option, you
+can use the @code{challenger-config} helper:
+
+@example
+[root@@exchange-online]# challenger-config --diagnostics
+< ... annotated, full configuration ... >
+@end example
+
+@cartouche
+@quotation Warning 
+While @code{challenger-config} also supports rewriting configuration files, we strongly
+recommend to edit configuration files manually, as @code{challenger-config} does not
+preserve comments and, by default, rewrites @code{/etc/challenger/challenger.conf}.
+@end quotation
+@end cartouche
+
+@menu
+* Configuration format:: 
+* Fundamental Setup; Address validation: Fundamental Setup Address validation. 
+* Legal conditions for using the service:: 
+* Terms of Service:: 
+* Privacy Policy:: 
+* Legal policies directory layout:: 
+* Generating the Legal Terms:: 
+* Adding translations:: 
+* Updating legal documents:: 
+* Database Configuration:: 
+
+@end menu
+
+@node Configuration format,Fundamental Setup Address validation,,Configuration Fundamentals
+@anchor{taler-challenger-manual configuration-format}@anchor{e}
+@section Configuration format
+
+
+All GNU Taler components are designed to possibly share the same
+configuration files.  When installing a GNU Taler component, the
+installation deploys default values in configuration files located
+at $@{prefix@}/share/taler/config.d/ where $@{prefix@} is the installation
+prefix. Different components must be installed to the same prefix.
+
+In order to override these defaults, the user can write a custom configuration
+file and either pass it to the component at execution time using the `-c'
+option, or name it taler.conf and place it under $HOME/.config/ which is where
+components will look by default. Note that the systemd service files pass @code{-c
+/etc/taler.conf}, thus making @code{/etc/taler.conf} the primary location for
+the configuration.
+
+A config file is a text file containing sections, and each section
+contains maps options to their values.  Configuration files follow
+basically the INI syntax:
+
+@example
+[section1]
+value1 = string
+value2 = 23
+
+[section2]
+value21 = string
+value22 = /path22
+@end example
+
+Comments start with a hash (@code{#}).  Throughout the configuration, it is
+possible to use @code{$}-substitution for options relating to names of files or
+directories. It is also possible to provide defaults values for those
+variables that are unset, by using the following syntax:
+@code{$@{VAR:-default@}}. There are two ways a user can set the value
+of @code{$}-prefixable variables:
+
+@quotation
+
+
+@enumerate 
+
+@item 
+by defining them under a @code{[paths]} section:
+@end enumerate
+
+@quotation
+
+@example
+[paths]
+TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
+..
+[section-x]
+path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
+@end example
+@end quotation
+
+
+@enumerate 2
+
+@item 
+or by setting them in the environment:
+@end enumerate
+
+@quotation
+
+@example
+$ export VAR=/x
+@end example
+@end quotation
+@end quotation
+
+The configuration loader will give precedence to variables set under
+@code{[path]} over environment variables.
+
+The utility @code{taler-config}, which gets installed along with the exchange,
+can be used get and set configuration values without directly editing the
+configuration file. The option @code{-f} is particularly useful to resolve
+pathnames, when they use several levels of @code{$}-expanded variables. See
+@code{taler-config --help}.
+
+The repository @code{git://git.taler.net/deployment} contains example code
+for generating configuration files under @code{deployment/netzbon/}.
+
+@node Fundamental Setup Address validation,Legal conditions for using the service,Configuration format,Configuration Fundamentals
+@anchor{taler-challenger-manual fundamental-setup-address-validation}@anchor{f}
+@section Fundamental Setup: Address validation
+
+
+Each challenger service is designed to validate one type of address. Possible
+address types include:
+
+@quotation
+
+
+@itemize *
+
+@item 
+phone numbers (via SMS)
+
+@item 
+e-mail addresses (via SMTP)
+
+@item 
+mail addresses (via postal service)
+@end itemize
+@end quotation
+
+In principle, additional types of addresses can easily be added by extending
+the respective HTML and programs to send challenges to the new address type.
+
+To make different types of address validations possible, the Challenger
+configuration contains two configuration options.
+
+@quotation
+
+
+@enumerate 
+
+@item 
+The @code{ADDRESS_TYPE} configuration option informs Challenger about the
+type of address it is expected to validate. It is returned as part of
+the OAuth 2.0 @code{/info} endpoint to the client, and is typically also
+used when deciding how to render the HTML form for address entry that is
+shown to the user.
+
+@item 
+The @code{AUTH_COMMAND} configuration option specifies which command
+Challenger should run to send a challenge to an address. The actual
+address is given to this subcommand as the first argument (@code{$1}),
+while the text with the challenge is passed to standard input.
+The subcommand should terminate with a status code of 0 on success.
+@end enumerate
+@end quotation
+
+
+@float LiteralBlock
+
+@caption{/etc/challenger/challenger.conf}
+
+@example
+ [challenger]
+ ADDRESS_TYPE = email
+ AUTH_COMMAND = challenger-send-email.sh
+ # ... rest of file ...
+@end example
+
+@end float
+
+
+Challenger comes with @code{AUTH_COMMAND} shell scripts for sending e-mail, SMS
+and postal mail. Note that for SMS and postal mail the Challenger scripts uses
+third party services to actually send the SMS or print and mail the postal
+mail. These third parties naturally charge money for their services, and thus
+the Challenger administrator will need to add the respective credentials to
+the SMS and postal mail scripts before they can function.  In any case, these
+scripts should be primarily seen as `examples' on how to write authentication
+commands.
+
+@quotation
+
+..note:
+
+@example
+We strongly welcome contributions for additional scripts with alternative
+providers or for new types of addresses.
+@end example
+@end quotation
+
+@node Legal conditions for using the service,Terms of Service,Fundamental Setup Address validation,Configuration Fundamentals
+@anchor{taler-challenger-manual legal-conditions-for-using-the-service}@anchor{10}
+@section Legal conditions for using the service
+
+
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
+
+The service has well-known API endpoints to return its legal conditions to the
+user in various languages and various formats.  This section describes how to
+setup and configure the legal conditions.
+
+@node Terms of Service,Privacy Policy,Legal conditions for using the service,Configuration Fundamentals
+@anchor{taler-challenger-manual terms-of-service}@anchor{11}
+@section Terms of Service
+
+
+The service has an endpoint “/terms” to return the terms of service (in legal
+language) of the service operator.  Client software show these terms of
+service to the user when the user is first interacting with the service.
+Terms of service are optional for experimental deployments, if none are
+configured, the service will return a simple statement saying that there are
+no terms of service available.
+
+To configure the terms of service response, there are two options
+in the configuration file for the service:
+
+
+@itemize -
+
+@item 
+@code{TERMS_ETAG}: The current “Etag” to return for the terms of service.
+This value must be changed whenever the terms of service are
+updated. A common value to use would be a version number.
+Note that if you change the @code{TERMS_ETAG}, you MUST also provide
+the respective files in @code{TERMS_DIR} (see below).
+
+@item 
+@code{TERMS_DIR}: The directory that contains the terms of service.
+The files in the directory must be readable to the service
+process.
+@end itemize
+
+@node Privacy Policy,Legal policies directory layout,Terms of Service,Configuration Fundamentals
+@anchor{taler-challenger-manual privacy-policy}@anchor{12}
+@section Privacy Policy
+
+
+The service has an endpoint “/pp” to return the terms privacy policy (in legal
+language) of the service operator.  Clients should show the privacy policy to
+the user when the user explicitly asks for it, but it should not be shown by
+default.  Privacy policies are optional for experimental deployments, if none
+are configured, the service will return a simple statement saying that there
+is no privacy policy available.
+
+To configure the privacy policy response, there are two options
+in the configuration file for the service:
+
+
+@itemize -
+
+@item 
+@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
+This value must be changed whenever the privacy policy is
+updated. A common value to use would be a version number.
+Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
+the respective files in @code{PRIVACY_DIR} (see below).
+
+@item 
+@code{PRIVACY_DIR}: The directory that contains the privacy policy.
+The files in the directory must be readable to the service
+process.
+@end itemize
+
+@node Legal policies directory layout,Generating the Legal Terms,Privacy Policy,Configuration Fundamentals
+@anchor{taler-challenger-manual legal-policies-directory-layout}@anchor{13}
+@section Legal policies directory layout
+
+
+The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
+particular layout.  You may use the same directory for both the terms of
+service and the privacy policy, as long as you use different ETAGs.  Inside of
+the directory, there should be sub-directories using two-letter language codes
+like “en”, “de”, or “jp”.  Each of these directories would then hold
+translations of the current terms of service into the respective language.
+Empty directories are permitted in case translations are not available.
+
+Then, inside each language directory, files with the name of the value set as
+the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
+of the files should be typical for the respective mime type.  The set of
+supported mime types is currently hard-coded in the service, and includes
+“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
+the service may show a warning on startup.
+
+@menu
+* Example:: 
+
+@end menu
+
+@node Example,,,Legal policies directory layout
+@anchor{taler-challenger-manual example}@anchor{14}
+@subsection Example
+
+
+A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
+
+
+@itemize -
+
+@item 
+TERMS_DIR/en/tos-v0.txt
+
+@item 
+TERMS_DIR/en/tos-v0.html
+
+@item 
+TERMS_DIR/en/tos-v0.pdf
+
+@item 
+TERMS_DIR/en/tos-v0.epub
+
+@item 
+TERMS_DIR/en/tos-v0.md
+
+@item 
+TERMS_DIR/de/tos-v0.txt
+
+@item 
+TERMS_DIR/de/tos-v0.html
+
+@item 
+TERMS_DIR/de/tos-v0.pdf
+
+@item 
+TERMS_DIR/de/tos-v0.epub
+
+@item 
+TERMS_DIR/de/tos-v0.md
+@end itemize
+
+If the user requests an HTML format with language preferences “fr” followed by
+“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+French.
+
+@node Generating the Legal Terms,Adding translations,Legal policies directory layout,Configuration Fundamentals
+@anchor{taler-challenger-manual generating-the-legal-terms}@anchor{15}
+@section Generating the Legal Terms
+
+
+The @code{taler-terms-generator} script can be used to generate directories with
+terms of service and privacy policies in multiple languages and all required
+data formats from a single source file in @code{.rst} format and GNU gettext
+translations in @code{.po} format.
+
+To use the tool, you need to first write your legal conditions in English in
+reStructuredText (rst).  You should find a templates in
+@code{$PREFIX/share/terms/*.rst} where @code{$PREFIX} is the location where you
+installed the service to. Whenever you make substantive changes to the legal
+terms, you must use a fresh filename and change the respective @code{ETAG}.  The
+resulting file must be called @code{$ETAG.rst} and the first line of the file should be the title of the document.
+
+Once you have written the @code{$ETAG.rst} file in English, you can
+generate the first set of outputs:
+
+@example
+$ taler-terms-generator -i $ETAG
+@end example
+
+Afterwards, you should find the terms in various formats for all configured
+languages (initially only English) in @code{$PREFIX/share/terms/}.  The generator
+has a few options which are documented in its man page.
+
+@node Adding translations,Updating legal documents,Generating the Legal Terms,Configuration Fundamentals
+@anchor{taler-challenger-manual adding-translations}@anchor{16}
+@section Adding translations
+
+
+Translations must be available in subdirectories
+@code{locale/$LANGUAGE/LC_MESSAGES/$ETAG.po}.
+To start translating, you first need to add a new
+language:
+
+@example
+$ taler-terms-generator -i $ETAG -l $LANGUAGE
+@end example
+
+Here, @code{$LANGUAGE} should be a two-letter language
+code like @code{de} or @code{fr}.  The command will generate
+a file @code{locale/$LANGUAGE/LC_MESSAGES/$ETAG.po}
+which contains each English sentence or paragraph
+in the original document and an initially empty
+translation.  Translators should update the @code{.po}
+file. Afterwards, simply re-run
+
+@example
+$ taler-terms-generator -i $ETAG
+@end example
+
+to make the current translation(s) available to the
+service.
+
+@cartouche
+@quotation Note 
+You must restart the service whenever adding or updating legal documents or their translations.
+@end quotation
+@end cartouche
+
+@node Updating legal documents,Database Configuration,Adding translations,Configuration Fundamentals
+@anchor{taler-challenger-manual updating-legal-documents}@anchor{17}
+@section Updating legal documents
+
+
+When making minor changes without legal implications, edit the @code{.rst} file,
+then re-run the step to add a new language for each existing translation to
+produce an updated @code{.po} file. Translate the sentences that have changed and
+finally run the generator (without @code{-l}) on the ETAG (@code{-i $ETAG}) to
+create the final files.
+
+When making major changes with legal implications, you should first rename (or
+copy) the existing @code{.rst} file and the associated translation files to a new
+unique name.  Afterwards, make the major changes, update the @code{.po} files,
+complete the translations and re-create the final files.  Finally, do not
+forget to update the @code{ETAG} configuration option to the new name and to
+restart the service.
+
+@node Database Configuration,,Updating legal documents,Configuration Fundamentals
+@anchor{taler-challenger-manual database-configuration}@anchor{18}
+@section Database Configuration
+
+
+The access credentials for the Challenger database are configured in
+@code{/etc/challenger/challenger.conf}.  Currently, only PostgreSQL is
+supported as a database backend.
+
+@cartouche
+@quotation Note 
+The `challenger-dbconfig' tool can be used to automate the database
+setup. When using the Debian/Ubuntu packages, the user should already have
+been created, so you can just run the tool without any arguments and should
+have a working database configuration.  Subsequently, you should still run
+`taler-challenger-dbinit' as the @code{challenger-httpd} user to
+initialize the database schema.
+@end quotation
+@end cartouche
+
+To create a database for Challenger on the local system, run:
+
+@example
+[root@@exchange-online]# su - postgres
+[postgres@@exchange-online]# createuser challenger-httpd
+[postgres@@exchange-online]# createdb -O challenger-httpd challenger
+[postgres@@exchange-online]# exit
+@end example
+
+This will create a @code{challenger} database owned by the @code{taler-httpd} user.
+We will use that user later to perform database maintenance operations.
+
+Assuming the above database setup, the database credentials to configure
+in the configuration file would simply be:
+
+
+@float LiteralBlock
+
+@caption{/etc/challenger/challenger.conf}
+
+@example
+[challenger]
+DB = postgres
+
+[challenger-postgres]
+CONFIG = postgres:///challenger
+@end example
+
+@end float
+
+
+If the database is run on a different host, please follow the instructions
+from the PostgreSQL manual for configuring remote access.
+
+After configuring the database credentials, the Challenger database needs
+to be initialized with the following command:
+
+@example
+[root@@exchange-online]# sudo -u challenger-httpd challenger-dbinit
+
+..note::
+
+  To run this command, the user must have `@w{`}CREATE TABLE`@w{`}, `@w{`}CREATE
+  INDEX`@w{`}, `@w{`}ALTER TABLE`@w{`} and (in the future possibly even) `@w{`}DROP TABLE`@w{`}
+  permissions.  Those permissions are only required for this step (which may
+  have to be repeated when upgrading a deployment).  Afterwards, during
+  normal operation, permissions to `@w{`}CREATE`@w{`} or `@w{`}ALTER`@w{`} tables are not
+  required by Challenger and thus should not be granted.  For more
+  information, see :doc:`manpages/challenger-dbinit.1`.
+@end example
+
+@node Deployment,,Configuration Fundamentals,Top
+@anchor{taler-challenger-manual deployment}@anchor{19}
+@chapter Deployment
+
+
+This chapter describes how to deploy Challenger once the basic installation
+and configuration are completed.
+
+@menu
+* Serving:: 
+* Reverse Proxy Setup:: 
+* Launching Challenger:: 
+* Authorizing clients:: 
+* OAuth 2.0 integration: OAuth 2 0 integration. 
+* Database management:: 
+
+@end menu
+
+@node Serving,Reverse Proxy Setup,,Deployment
+@anchor{taler-challenger-manual challengerserving}@anchor{1a}@anchor{taler-challenger-manual serving}@anchor{1b}
+@section Serving
+
+
+The Challenger can serve HTTP over both TCP and UNIX domain socket.
+
+The following options are to be configured in the section @code{[challenger]}:
+
+
+@itemize -
+
+@item 
+@code{SERVE}: Must be set to @code{tcp} to serve HTTP over TCP, or @code{unix} to serve
+HTTP over a UNIX domain socket.
+
+@item 
+@code{PORT}: Set to the TCP port to listen on if @code{SERVE} is @code{tcp}.
+
+@item 
+@code{UNIXPATH}: Set to the UNIX domain socket path to listen on if @code{SERVE} is
+@code{unix}.
+
+@item 
+
+@table @asis
+
+@item @code{UNIXPATH_MODE}: Number giving the mode with the access permission mask
+
+for the @code{UNIXPATH} (i.e. 660 = @code{rw-rw---}). Make sure to set it in such
+a way that your reverse proxy has permissions to access the UNIX domain
+socket.  The default (660) assumes that the reverse proxy is a member of
+the group under which the exchange HTTP server is running.
+@end table
+@end itemize
+
+@node Reverse Proxy Setup,Launching Challenger,Serving,Deployment
+@anchor{taler-challenger-manual challengerreverseproxy}@anchor{1c}@anchor{taler-challenger-manual reverse-proxy-setup}@anchor{1d}
+@section Reverse Proxy Setup
+
+
+By default, the @code{challenger-httpd} service listens for HTTP connections
+on a UNIX domain socket.  To make the service publicly available, a reverse
+proxy such as nginx should be used.  You must configure the reverse proxy
+to use TLS as this is required by OAuth 2.0.
+
+The @code{challenger} package ships with a sample configuration that can be
+enabled in nginx:
+
+@example
+[root@@exchange-online]# vim /etc/nginx/sites-available/challenger
+< ... customize configuration ... >
+[root@@exchange-online]# ln -s /etc/nginx/sites-available/challenger \
+                              /etc/nginx/sites-enabled/challenger
+[root@@exchange-online]# systemctl reload nginx
+@end example
+
+@node Launching Challenger,Authorizing clients,Reverse Proxy Setup,Deployment
+@anchor{taler-challenger-manual launching-challenger}@anchor{1e}
+@section Launching Challenger
+
+
+A running exchange requires starting the following processes:
+
+
+@itemize -
+
+@item 
+@code{challenger-httpd} (needs database access)
+@end itemize
+
+The processes should be started via a hypervisor like
+@code{systemd} or @code{gnunet-arm} that automatically re-starts them should they
+have terminated unexpectedly.  Furthermore, the hypervisor
+`should' periodically re-start the service (say once per hour)
+to limit Postgres database memory utilization.
+
+@cartouche
+@quotation Note 
+The @code{challenger-httpd} does not ship with HTTPS enabled by default.
+It must thus be run behind an HTTPS reverse proxy that performs
+TLS termination on the same system.  Thus, it would typically be configured
+to listen on a UNIX domain socket.
+@end quotation
+@end cartouche
+
+Given proper packaging, all of the above are realized via a simple systemd
+target. This enables Challenger to be properly started using a simple command:
+
+@example
+# systemctl start challenger-httpd.service
+@end example
+
+@node Authorizing clients,OAuth 2 0 integration,Launching Challenger,Deployment
+@anchor{taler-challenger-manual authorizing-clients}@anchor{1f}
+@section Authorizing clients
+
+
+Before clients can use Challenger, they must be explicitly configured. Each
+client is identified via its OAuth 2.0 REDIRECT URI.  Thus, a client must have
+exactly one REDIRECT URI
+
+@quotation
+
+..note:
+
+@example
+The OAuth 2.0 specification allows for a client to register
+zero or multiple REDIRECT URIs. However, zero is insecure
+as it creates an open redirector, and multiple REDIRECT URIs
+can trivially be implemented with Challenger by adding more
+clients.
+@end example
+@end quotation
+
+You can add or remove clients at any time; the Challenger service does not
+need to be running, but if it is you can still add or remove clients without
+restarting the service.  To add (or remove) a client, you must use the
+@code{challenger-admin} command:
+
+@example
+# sudo -u challenger-httpd challenger-admin --add=$SECRET $REDIRECT_URI
+@end example
+
+Here, @code{$SECRET} is the client secret of OAuth 2.0 which will be used in
+various parts of the protocol to authenticate the client.  The
+@code{$REDIRECT_URI} is the URI where the user-agent will be redirected to upon
+completion of the process.  The @code{challenger-admin} command will
+then output the `client ID', which will be a unique positive number.
+The first time you run the command, you will thus likely see:
+@code{Client added. Client ID is: 1}.  This client ID, the @code{$SECRET}
+and the @code{$REDIRECT_URI} will form the foundation for the OAuth 2.0
+configuration.
+
+@node OAuth 2 0 integration,Database management,Authorizing clients,Deployment
+@anchor{taler-challenger-manual oauth-2-0-integration}@anchor{20}
+@section OAuth 2.0 integration
+
+
+When integrating Challenger into an OAuth 2.0 process, you need to provide the
+three options from the previous section, but also the authorization, token and
+info endpoints.  For Challenger, these are @code{/authorize}, @code{/token} and
+@code{/info}.  However, the @code{/authorize} endpoint is special, as it is actually
+@code{/authorize/$NONCE} where @code{$NONCE} is a nonce that must be first requested
+by the client using the @code{/setup} endpoint!
+
+@quotation
+
+..note:
+
+@example
+This extra step prevents user-agents from (ab)using the Challenger service
+to send challenges to addresses even when there is no authorized client
+that desires address validation. This is an important feature as address
+validation could be expensive.
+@end example
+@end quotation
+
+Thus, to generate the authorization URL, a client must first POST to
+@code{/setup} using their client secret in an @code{Authorization: Bearer $SECRET}
+HTTP header to obtain a fresh @code{$NONCE}.
+
+In the GNU Taler exchange configuration, this is indicated by appending
+@code{#setup} to the @code{KYC_OAUTH2_AUTHORIZE_URL} endpoint.  Be careful to quote
+the URL, as @code{#} is otherwise interpreted as the beginning of a comment by
+the configuration file syntax:
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-oauth2.conf}
+
+@example
+[kyc-provider-example-oauth2]
+LOGIC = oauth2
+# (generic options omitted)
+KYC_OAUTH2_AUTHORIZE_URL = "https://challenger.example.com/authorize#setup"
+KYC_OAUTH2_TOKEN_URL = "https://challenger.example.com/token"
+KYC_OAUTH2_INFO_URL = "https://challenger.example.com/info"
+KYC_OAUTH2_CLIENT_ID = 1
+KYC_OAUTH2_CLIENT_SECRET = "$SECRET"
+@end example
+
+@end float
+
+
+@node Database management,,OAuth 2 0 integration,Deployment
+@anchor{taler-challenger-manual database-management}@anchor{21}
+@section Database management
+
+
+@quotation
+
+@cartouche
+@quotation Note 
+We advise to make good backups before experimenting with
+the database.
+@end quotation
+@end cartouche
+@end quotation
+
+To update the Challenger database after upgrading to a newer
+version of Challenger, you should simply re-run @code{challenger-dbinit}.
+Without further options, this command is expected to preserve
+all data and only migrate the existing database to the latest
+schema:
+
+@example
+$ challenger-dbinit
+@end example
+
+To delete stale data from the Challenger database, you can use
+garbage collection:
+
+@example
+$ challenger-dbinit --garbagecollect
+@end example
+
+The Challenger database can be re-initialized using:
+
+@example
+$ challenger-dbinit --reset
+@end example
+
+However, running this command will result in all data in the database
+being lost.
+
+@c %**end of body
+@bye
diff --git a/texinfo/taler-auditor.texi b/texinfo/taler-auditor.texi
index e90120de..4345d8f4 100644
--- a/texinfo/taler-auditor.texi
+++ b/texinfo/taler-auditor.texi
@@ -3,7 +3,7 @@
 @setfilename taler-auditor.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 3.4.3.@*
+@*Generated by Sphinx 5.3.0.@*
 @end ifinfo
 @settitle Taler Auditor Manual
 @defindex ge
@@ -15,13 +15,11 @@
 * MENU ENTRY: (taler-auditor.info). DESCRIPTION
 @end direntry
 
-@definfoenclose strong,`,'
-@definfoenclose emph,`,'
 @c %**end of header
 
 @copying
 @quotation
-GNU Taler 0.9.0, Nov 03, 2022
+GNU Taler 0.9.0, Sep 24, 2023
 
 GNU Taler team
 
@@ -102,9 +100,20 @@ Configuration
 * Using taler-config:: 
 * Initial configuration:: 
 * Keys:: 
-* Configuring the auditor's REST endpoint:: 
+* Configuring the auditor’s REST endpoint:: 
 * Bank account:: 
 * Database:: 
+* Legal conditions for using the service:: 
+* Terms of Service:: 
+* Privacy Policy:: 
+* Legal policies directory layout:: 
+* Generating the Legal Terms:: 
+* Adding translations:: 
+* Updating legal documents:: 
+
+Legal policies directory layout
+
+* Example:: 
 
 Deployment
 
@@ -129,7 +138,7 @@ Operation
 
 Auditor implementation guide
 
-* The auditor's database:: 
+* The auditor’s database:: 
 * Invariants checked by the auditor:: 
 * Testing the auditor:: 
 
@@ -165,6 +174,21 @@ to become readable.
 @section About GNU Taler
 
 
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+
 GNU Taler is an open protocol for an electronic payment system with a
 free software reference implementation. GNU Taler offers secure, fast
 and easy payment processing using well understood cryptographic
@@ -197,7 +221,7 @@ to other parties.
 
 To perform this duty, you will need at least (read-only) access to the bank
 transactions of the exchange, as well as a continuously synchronized replica
-of the exchange's database.  The general assumption for running the auditor
+of the exchange’s database.  The general assumption for running the auditor
 is that this is done on a separate system controlled by the auditor. After
 all, the goal is to detect nerfarious activity of the exchange operator,
 which cannot be effectively done on a machine controlled by the exchange
@@ -209,9 +233,9 @@ withdrawals made by consumers and income received by merchants.  As a result,
 the auditor is expected to provide high confidentiality for the database.  In
 general, the auditor does not have to offer high-availability: the exchange
 operator can continue operations without the auditor, and the auditor can
-catch up with it later when the auditor's systems are restored. However, of
+catch up with it later when the auditor’s systems are restored. However, of
 course any downtime would provide a window of opportunity for fraud and should
-thus be minimized.  Finally, the auditor's copy of the exchange's database can
+thus be minimized.  Finally, the auditor’s copy of the exchange’s database can
 be useful as a backup to the exchange in case the exchange experiences a loss
 of its own copies. Thus, business agreements between auditor and exchanges may
 include availability requirements as well.
@@ -219,7 +243,7 @@ include availability requirements as well.
 Then, with the software provided, auditors can verify the cryptographic proofs
 collected by the exchange and detect if any improper bank transactions have been
 made.  There are additional tasks which an auditor should perform.  While this
-manual only focuses on the audit of the exchange's database and wire transfers
+manual only focuses on the audit of the exchange’s database and wire transfers
 with the existing tools, a proper auditor should also perform the following
 tasks:
 
@@ -245,7 +269,7 @@ verification that the exchange properly implements the @code{/link} protocol
 @item 
 verification that the exchange properly reports coins issued during
 the refresh protocol (by irregularly refreshing coins withdrawn by
-the auditor and comparing against the exchange's database --- the
+the auditor and comparing against the exchange’s database — the
 code required to support this is not yet implemented)
 @end itemize
 
@@ -266,8 +290,8 @@ oversight function.
 Auditors should generally be independent third parties that verify that the
 exchange operates correctly.  However, an exchange is likely to also run the
 auditing logic, as it is also used to calculate the exchange’s profits, risk
-and liabilities.  Furthermore, it's usually a good idea to not only rely on
-third parties to verify one's own work.
+and liabilities.  Furthermore, it’s usually a good idea to not only rely on
+third parties to verify one’s own work.
 
 The Taler software stack for an auditor consists of the following
 components:
@@ -299,7 +323,7 @@ the auditor to detect if an exchange is underreporting deposits.
 In the future, the Web service should be extended to allow customers and
 merchants to automatically upload cryptographic proof of other violations
 of the specification by the exchange.  However, for now it is assumed that
-the respective cryptographic proofs are reported and verified manually ---
+the respective cryptographic proofs are reported and verified manually —
 as with a well-behaved exchange this should obviously be a rare event.
 
 The main binary of this component is the @code{taler-auditor-httpd}.
@@ -319,7 +343,7 @@ needs access to the wire gateway).
 The @code{taler-helper-auditor-wire} auditor verifies that the bank
 transactions performed by the exchange
 were done properly.  This component must have access to the bank account
-of the exchange, as well as to a copy of the exchange's database.
+of the exchange, as well as to a copy of the exchange’s database.
 
 The @code{taler-auditor} script invokes the various helpers, each generating
 a JSON report. It then invokes the @code{taler-helper-auditor-render.py}
@@ -365,7 +389,7 @@ Python3 module @code{jinja2}
 @itemize -
 
 @item 
-"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
+“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
 on Debian-based systems (for GNUnet documentation support, can be
 omitted if GNUnet is configured with @code{--disable-documentation})
 
@@ -379,10 +403,10 @@ GNU libunistring >= 0.9.3
 libcurl >= 7.26 (or libgnurl >= 7.26)
 
 @item 
-libqrencode >= 4.0.0
+libqrencode >= 4.0.0 (Taler merchant only)
 
 @item 
-GNU libgcrypt >= 1.6
+GNU libgcrypt >= 1.6 (1.10 or later highly recommended)
 
 @item 
 libsodium >= 1.0
@@ -400,7 +424,34 @@ PostgreSQL >= 13, including libpq
 GNU libmicrohttpd >= 0.9.71
 
 @item 
-GNUnet >= 0.16 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
+GNUnet >= 0.19 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
+
+@item 
+Python3 with @code{jinja2}
+@end itemize
+
+If you are on Debian stable or later, the following command may help you
+install these dependencies:
+
+@example
+# apt-get install \
+  libqrencode-dev \
+  libsqlite3-dev \
+  libltdl-dev \
+  libunistring-dev \
+  libsodium-dev \
+  libargon2-dev \
+  libcurl4-gnutls-dev \
+  libgcrypt20-dev \
+  libjansson-dev \
+  libpq-dev \
+  libmicrohttpd-dev \
+  python3-jinja2 \
+  postgresql-13
+@end example
+
+
+@itemize -
 
 @item 
 GNU Taler exchange (from download directory@footnote{http://ftpmirror.gnu.org/taler/},
@@ -454,13 +505,9 @@ which requires you to run the last step as @code{root}.  You have to specify
 previous step.
 
 Please note that unlike most packages, if you want to run the @code{make check}
-command, you should run it only @emph{after} having done @code{make install}.  The
+command, you should run it only `after' having done @code{make install}.  The
 latter ensures that necessary binaries are copied to the right place.
 
-Gratuitous editorial note by TTN: I think this is a quirk that we should
-fix in the long-term as such weirdness might hide other build issues.
-However, this is probably a minority viewpoint.
-
 In any case, if @code{make check} fails, please consider filing a
 bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
 
@@ -471,27 +518,28 @@ bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
 
 To install the GNU Taler Debian packages, first ensure that you have
 the right Debian distribution. At this time, the packages are built for
-Bullseye.
+Debian bookworm.
 
 You need to add a file to import the GNU Taler packages. Typically,
 this is done by adding a file @code{/etc/apt/sources.list.d/taler.list} that
 looks like this:
 
 @example
-deb https://deb.taler.net/apt/debian bullseye main
+deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/debian stable main
 @end example
 
 Next, you must import the Taler Systems SA public package signing key
 into your keyring and update the package lists:
 
 @example
-# wget -O - https://taler.net/taler-systems.gpg.key | apt-key add -
+# wget -O /etc/apt/keyrings/taler-systems.gpg \
+    https://taler.net/taler-systems.gpg
 # apt update
 @end example
 
 @cartouche
 @quotation Note 
-You may want to verify the correctness of the Taler Systems key out-of-band.
+You may want to verify the correctness of the Taler Systems SA key out-of-band.
 @end quotation
 @end cartouche
 
@@ -517,13 +565,15 @@ Sample configuration files for the HTTP reverse proxy can be found in
 
 To install the GNU Taler Ubuntu packages, first ensure that you have
 the right Ubuntu distribution. At this time, the packages are built for
-Ubuntu 22.04 LTS (Jammy Jellyfish).
+Ubuntu Kinetic and Ubuntu Jammy. Make sure to have @code{universe} in your
+@code{/etc/apt/sources.list} (after @code{main}) as we depend on some packages
+from Ubuntu @code{universe}.
 
 A typical @code{/etc/apt/sources.list.d/taler.list} file for this setup
 would look like this:
 
 @example
-deb https://deb.taler.net/apt/ubuntu/ jammy main
+deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ stable main
 @end example
 
 The last line is crucial, as it adds the GNU Taler packages.
@@ -532,8 +582,8 @@ Next, you must import the Taler Systems SA public package signing key
 into your keyring and update the package lists:
 
 @example
-# wget -O /etc/apt/trusted.gpg.d/taler-systems.asc \
-    https://taler.net/taler-systems.gpg.key
+# wget -O /etc/apt/keyrings/taler-systems.gpg \
+    https://taler.net/taler-systems.gpg
 # apt update
 @end example
 
@@ -585,22 +635,22 @@ is not recommended for security.  The recommended set of users includes:
 @itemize *
 
 @item 
-auditor --- runs the main auditing process and HTTP backend
+auditor — runs the main auditing process and HTTP backend
 
 @item 
-sync --- synchronizes the ingres database with the production database
+sync — synchronizes the ingres database with the production database
 
 @item 
-helper --- runs taler-auditor-offline download and upload commands
+helper — runs taler-auditor-offline download and upload commands
 
 @item 
-auditor-ingres --- imports database from exchange production system
+auditor-ingres — imports database from exchange production system
 
 @item 
-auditor-wire --- imports wire transfer data from bank production system
+auditor-wire — imports wire transfer data from bank production system
 
 @item 
-offline --- manages the offline key, on a separate @emph{offline} machine
+offline — manages the offline key, on a separate `offline' machine
 @end itemize
 @end quotation
 
@@ -620,10 +670,10 @@ distribution would typically create for you):
 @itemize *
 
 @item 
-www-data --- runs the HTTPS frontend (usually nginx or Apache)
+www-data — runs the HTTPS frontend (usually nginx or Apache)
 
 @item 
-postgres --- runs the PostgreSQL database
+postgres — runs the PostgreSQL database
 @end itemize
 @end quotation
 
@@ -640,20 +690,20 @@ We recommend using the following databases for the auditor:
 @itemize *
 
 @item 
-exchange-ingres --- synchronized exchange database over the network
+exchange-ingres — synchronized exchange database over the network
 
 @item 
-exchange-production --- local copy of exchange database with trusted schema
+exchange-production — local copy of exchange database with trusted schema
 
 @item 
-auditor --- auditor production database with current state of the audit
+auditor — auditor production database with current state of the audit
 
 @item 
-libeufin --- local state of the auditor-wire tool for the bank transfer data import
+libeufin — local state of the auditor-wire tool for the bank transfer data import
 @end itemize
 @end quotation
 
-As the @emph{postgres} user, you can create these databases using:
+As the `postgres' user, you can create these databases using:
 
 @example
 # As the 'postgres' user:
@@ -681,7 +731,7 @@ $ echo 'GRANT SELECT ON ALL TABLES IN SCHEMA public TO auditor;' | psql libeufin
 @chapter Configuration
 
 
-The auditor's configuration works the same way as the configuration of other
+The auditor’s configuration works the same way as the configuration of other
 Taler components.
 This section discusses configuration options related to the auditor.
 
@@ -690,9 +740,16 @@ This section discusses configuration options related to the auditor.
 * Using taler-config:: 
 * Initial configuration:: 
 * Keys:: 
-* Configuring the auditor's REST endpoint:: 
+* Configuring the auditor’s REST endpoint:: 
 * Bank account:: 
 * Database:: 
+* Legal conditions for using the service:: 
+* Terms of Service:: 
+* Privacy Policy:: 
+* Legal policies directory layout:: 
+* Generating the Legal Terms:: 
+* Adding translations:: 
+* Updating legal documents:: 
 
 @end menu
 
@@ -701,16 +758,22 @@ This section discusses configuration options related to the auditor.
 @section Configuration format
 
 
-In Taler realm, any component obeys to the same pattern to get
-configuration values. According to this pattern, once the component has
-been installed, the installation deploys default values in
-$@{prefix@}/share/taler/config.d/, in .conf files. In order to override
-these defaults, the user can write a custom .conf file and either pass
-it to the component at execution time, or name it taler.conf and place
-it under $HOME/.config/.
+All GNU Taler components are designed to possibly share the same
+configuration files.  When installing a GNU Taler component, the
+installation deploys default values in configuration files located
+at $@{prefix@}/share/taler/config.d/ where $@{prefix@} is the installation
+prefix. Different components must be installed to the same prefix.
+
+In order to override these defaults, the user can write a custom configuration
+file and either pass it to the component at execution time using the `-c'
+option, or name it taler.conf and place it under $HOME/.config/ which is where
+components will look by default. Note that the systemd service files pass @code{-c
+/etc/taler.conf}, thus making @code{/etc/taler.conf} the primary location for
+the configuration.
 
 A config file is a text file containing sections, and each section
-contains its values. The right format follows:
+contains maps options to their values.  Configuration files follow
+basically the INI syntax:
 
 @example
 [section1]
@@ -722,14 +785,23 @@ value21 = string
 value22 = /path22
 @end example
 
-Throughout any configuration file, it is possible to use @code{$}-prefixed
-variables, like @code{$VAR}, especially when they represent filesystem
-paths. It is also possible to provide defaults values for those
+Comments start with a hash (@code{#}).  Throughout the configuration, it is
+possible to use @code{$}-substitution for options relating to names of files or
+directories. It is also possible to provide defaults values for those
 variables that are unset, by using the following syntax:
-@code{$@{VAR:-default@}}. However, there are two ways a user can set
-@code{$}-prefixable variables:
+@code{$@{VAR:-default@}}. There are two ways a user can set the value
+of @code{$}-prefixable variables:
+
+@quotation
+
+
+@enumerate 
+
+@item 
+by defining them under a @code{[paths]} section:
+@end enumerate
 
-by defining them under a @code{[paths]} section, see example below,
+@quotation
 
 @example
 [paths]
@@ -738,47 +810,43 @@ TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
 [section-x]
 path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
 @end example
+@end quotation
+
 
+@enumerate 2
+
+@item 
 or by setting them in the environment:
+@end enumerate
+
+@quotation
 
 @example
 $ export VAR=/x
 @end example
+@end quotation
+@end quotation
 
 The configuration loader will give precedence to variables set under
-@code{[path]}, though.
+@code{[path]} over environment variables.
 
-The utility @code{taler-config}, which gets installed along with the
-exchange, serves to get and set configuration values without directly
-editing the .conf. The option @code{-f} is particularly useful to resolve
+The utility @code{taler-config}, which gets installed along with the exchange,
+can be used get and set configuration values without directly editing the
+configuration file. The option @code{-f} is particularly useful to resolve
 pathnames, when they use several levels of @code{$}-expanded variables. See
 @code{taler-config --help}.
 
-Note that, in this stage of development, the file
-@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
-component. For example, both an exchange and a bank can read values from
-it.
-
-The repository @code{git://taler.net/deployment} contains examples of
-configuration file used in our demos. See under @code{deployment/config}.
-
-@quotation
-
-@strong{Note}
-
-Expectably, some components will not work just by using default
-values, as their work is often interdependent. For example, a
-merchant needs to know an exchange URL, or a database name.
-@end quotation
+The repository @code{git://git.taler.net/deployment} contains example code
+for generating configuration files under @code{deployment/netzbon/}.
 
 @node Using taler-config,Initial configuration,Configuration format,Configuration
 @anchor{taler-auditor-manual using-taler-config}@anchor{10}
 @section Using taler-config
 
 
-The tool @code{taler-config} can be used to extract or manipulate
-configuration values; however, the configuration use the well-known INI
-file format and can also be edited by hand.
+The tool @code{taler-config} can be used to extract or manipulate configuration
+values; however, the configuration use the well-known INI file format and is
+generally better edited by hand to preserve comments and structure.
 
 Run
 
@@ -791,20 +859,20 @@ to list all of the configuration values in section @code{$SECTION}.
 Run
 
 @example
-$ taler-config -s $section -o $option
+$ taler-config -s $SECTION -o $OPTION
 @end example
 
-to extract the respective configuration value for option @code{$option} in
-section @code{$section}.
+to extract the respective configuration value for option @code{$OPTION} in
+section @code{$SECTION}.
 
 Finally, to change a setting, run
 
 @example
-$ taler-config -s $section -o $option -V $value
+$ taler-config -s $SECTION -o $OPTION -V $VALUE
 @end example
 
-to set the respective configuration value to @code{$value}. Note that you
-have to manually restart the Taler backend after you change the
+to set the respective configuration value to @code{$VALUE}. Note that you
+have to manually restart affected Taler components after you change the
 configuration to make the new configuration go into effect.
 
 Some default options will use $-variables, such as @code{$DATADIR} within
@@ -813,16 +881,13 @@ configuration, pass the @code{-f} option to @code{taler-config}. For example,
 compare:
 
 @example
-$ taler-config -s ACCOUNT-bank \
-               -o WIRE_RESPONSE
-$ taler-config -f -s ACCOUNT-bank \
-               -o WIRE_RESPONSE
+$ taler-config --section exchange-offline --option MASTER_PRIV_FILE
+$ taler-config -f --section exchange-offline --option MASTER_PRIV_FILE
 @end example
 
 While the configuration file is typically located at
-@code{$HOME/.config/taler.conf}, an alternative location can be specified
-to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
-option.
+@code{$HOME/.config/taler.conf}, an alternative location can be specified to any
+GNU Taler component using the @code{-c} option.
 
 @node Initial configuration,Keys,Using taler-config,Configuration
 @anchor{taler-auditor-manual initial-configuration}@anchor{11}@anchor{taler-auditor-manual setupbaseurl}@anchor{12}
@@ -839,7 +904,7 @@ $ taler-config -s auditor -o BASE_URL -V https://auditor.example.com/
 
 The @code{helper} user that is used to download information from the exchange
 needs to know details about the exchange. Similarly, the @code{offline} user
-needs to check signatures signed with the exchange's offline key. Hence, you
+needs to check signatures signed with the exchange’s offline key. Hence, you
 need to obtain the @code{MASTER_PUBLIC_KEY} from the exchange operator (they need
 to run @code{taler-exchange-offline setup}) and the REST endpoint of the exchange
 and configure these:
@@ -850,14 +915,14 @@ $ taler-config -s exchange -o BASE_URL -V https://exchange.example.com/
 $ taler-config -s exchange -o MASTER_PUBLIC_KEY -V $SOMELONGBASE32VALUEHERE
 @end example
 
-@node Keys,Configuring the auditor's REST endpoint,Initial configuration,Configuration
+@node Keys,Configuring the auditor’s REST endpoint,Initial configuration,Configuration
 @anchor{taler-auditor-manual auditorkeys}@anchor{13}@anchor{taler-auditor-manual keys}@anchor{14}
 @section Keys
 
 
 The auditor works with one signing key to certify that it is auditing
-a particular exchange's denomination keys.  This key can and should
-be kept @emph{offline} (and backed up adequately). As with the exchange's
+a particular exchange’s denomination keys.  This key can and should
+be kept `offline' (and backed up adequately). As with the exchange’s
 offline key, it is only used for a few cryptographic signatures and
 thus the respective code can be run on modest hardware, like a
 Raspberry Pi.
@@ -898,9 +963,9 @@ You can set this configuration value using:
 $ taler-config -s auditor -o PUBLIC_KEY -V $SOMELONGBASE32VALUEHERE
 @end example
 
-@node Configuring the auditor's REST endpoint,Bank account,Keys,Configuration
+@node Configuring the auditor’s REST endpoint,Bank account,Keys,Configuration
 @anchor{taler-auditor-manual auditorserving}@anchor{15}@anchor{taler-auditor-manual configuring-the-auditor-s-rest-endpoint}@anchor{16}
-@section Configuring the auditor's REST endpoint
+@section Configuring the auditor’s REST endpoint
 
 
 The auditor can serve HTTP over both TCP and UNIX domain socket.
@@ -926,7 +991,7 @@ HTTP over a UNIX domain socket
 for @code{unixpath} (i.e. 660 = @code{rw-rw----}).
 @end itemize
 
-@node Bank account,Database,Configuring the auditor's REST endpoint,Configuration
+@node Bank account,Database,Configuring the auditor’s REST endpoint,Configuration
 @anchor{taler-auditor-manual auditorbank-account}@anchor{17}@anchor{taler-auditor-manual bank-account}@anchor{18}
 @section Bank account
 
@@ -935,7 +1000,7 @@ Bank accounts for the auditor (user @code{auditor-wire}) are configured in
 exactly the same way as bank accounts for the exchange. See the exchange (and
 LibEuFin) documentation for details.
 
-@node Database,,Bank account,Configuration
+@node Database,Legal conditions for using the service,Bank account,Configuration
 @anchor{taler-auditor-manual auditordatabaseconfiguration}@anchor{19}@anchor{taler-auditor-manual database}@anchor{1a}
 @section Database
 
@@ -969,14 +1034,14 @@ CONFIG = postgres:///auditordemo
 If an exchange runs its own auditor, it may use the same database for
 the auditor and the exchange itself.
 
-The @code{taler-auditor-dbinit} tool is used to initialize the auditor's
+The @code{taler-auditor-dbinit} tool is used to initialize the auditor’s
 tables. After running this tool, the rights to CREATE or DROP tables
 are no longer required and should be removed.
 
 Both the @code{taler-auditor-httpd} and the @code{taler-auditor} (and its helpers)
 also need (read-only) access to a (recent, current, synchronized) copy of the
-exchange's database.  The configuration options are the same that are also
-used when configuring the exchange' database:
+exchange’s database.  The configuration options are the same that are also
+used when configuring the exchange’ database:
 
 @quotation
 
@@ -991,13 +1056,252 @@ CONFIG = postgres:///exchangedemo
 @end example
 @end quotation
 
+@node Legal conditions for using the service,Terms of Service,Database,Configuration
+@anchor{taler-auditor-manual legal-conditions-for-using-the-service}@anchor{1b}
+@section Legal conditions for using the service
+
+
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
+
+The service has well-known API endpoints to return its legal conditions to the
+user in various languages and various formats.  This section describes how to
+setup and configure the legal conditions.
+
+@node Terms of Service,Privacy Policy,Legal conditions for using the service,Configuration
+@anchor{taler-auditor-manual terms-of-service}@anchor{1c}
+@section Terms of Service
+
+
+The service has an endpoint “/terms” to return the terms of service (in legal
+language) of the service operator.  Client software show these terms of
+service to the user when the user is first interacting with the service.
+Terms of service are optional for experimental deployments, if none are
+configured, the service will return a simple statement saying that there are
+no terms of service available.
+
+To configure the terms of service response, there are two options
+in the configuration file for the service:
+
+
+@itemize -
+
+@item 
+@code{TERMS_ETAG}: The current “Etag” to return for the terms of service.
+This value must be changed whenever the terms of service are
+updated. A common value to use would be a version number.
+Note that if you change the @code{TERMS_ETAG}, you MUST also provide
+the respective files in @code{TERMS_DIR} (see below).
+
+@item 
+@code{TERMS_DIR}: The directory that contains the terms of service.
+The files in the directory must be readable to the service
+process.
+@end itemize
+
+@node Privacy Policy,Legal policies directory layout,Terms of Service,Configuration
+@anchor{taler-auditor-manual privacy-policy}@anchor{1d}
+@section Privacy Policy
+
+
+The service has an endpoint “/pp” to return the terms privacy policy (in legal
+language) of the service operator.  Clients should show the privacy policy to
+the user when the user explicitly asks for it, but it should not be shown by
+default.  Privacy policies are optional for experimental deployments, if none
+are configured, the service will return a simple statement saying that there
+is no privacy policy available.
+
+To configure the privacy policy response, there are two options
+in the configuration file for the service:
+
+
+@itemize -
+
+@item 
+@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
+This value must be changed whenever the privacy policy is
+updated. A common value to use would be a version number.
+Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
+the respective files in @code{PRIVACY_DIR} (see below).
+
+@item 
+@code{PRIVACY_DIR}: The directory that contains the privacy policy.
+The files in the directory must be readable to the service
+process.
+@end itemize
+
+@node Legal policies directory layout,Generating the Legal Terms,Privacy Policy,Configuration
+@anchor{taler-auditor-manual legal-policies-directory-layout}@anchor{1e}
+@section Legal policies directory layout
+
+
+The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
+particular layout.  You may use the same directory for both the terms of
+service and the privacy policy, as long as you use different ETAGs.  Inside of
+the directory, there should be sub-directories using two-letter language codes
+like “en”, “de”, or “jp”.  Each of these directories would then hold
+translations of the current terms of service into the respective language.
+Empty directories are permitted in case translations are not available.
+
+Then, inside each language directory, files with the name of the value set as
+the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
+of the files should be typical for the respective mime type.  The set of
+supported mime types is currently hard-coded in the service, and includes
+“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
+the service may show a warning on startup.
+
+@menu
+* Example:: 
+
+@end menu
+
+@node Example,,,Legal policies directory layout
+@anchor{taler-auditor-manual example}@anchor{1f}
+@subsection Example
+
+
+A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
+
+
+@itemize -
+
+@item 
+TERMS_DIR/en/tos-v0.txt
+
+@item 
+TERMS_DIR/en/tos-v0.html
+
+@item 
+TERMS_DIR/en/tos-v0.pdf
+
+@item 
+TERMS_DIR/en/tos-v0.epub
+
+@item 
+TERMS_DIR/en/tos-v0.md
+
+@item 
+TERMS_DIR/de/tos-v0.txt
+
+@item 
+TERMS_DIR/de/tos-v0.html
+
+@item 
+TERMS_DIR/de/tos-v0.pdf
+
+@item 
+TERMS_DIR/de/tos-v0.epub
+
+@item 
+TERMS_DIR/de/tos-v0.md
+@end itemize
+
+If the user requests an HTML format with language preferences “fr” followed by
+“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+French.
+
+@node Generating the Legal Terms,Adding translations,Legal policies directory layout,Configuration
+@anchor{taler-auditor-manual generating-the-legal-terms}@anchor{20}
+@section Generating the Legal Terms
+
+
+The @code{taler-terms-generator} script can be used to generate directories with
+terms of service and privacy policies in multiple languages and all required
+data formats from a single source file in @code{.rst} format and GNU gettext
+translations in @code{.po} format.
+
+To use the tool, you need to first write your legal conditions in English in
+reStructuredText (rst).  You should find a templates in
+@code{$PREFIX/share/terms/*.rst} where @code{$PREFIX} is the location where you
+installed the service to. Whenever you make substantive changes to the legal
+terms, you must use a fresh filename and change the respective @code{ETAG}.  The
+resulting file must be called @code{$ETAG.rst} and the first line of the file should be the title of the document.
+
+Once you have written the @code{$ETAG.rst} file in English, you can
+generate the first set of outputs:
+
+@example
+$ taler-terms-generator -i $ETAG
+@end example
+
+Afterwards, you should find the terms in various formats for all configured
+languages (initially only English) in @code{$PREFIX/share/terms/}.  The generator
+has a few options which are documented in its man page.
+
+@node Adding translations,Updating legal documents,Generating the Legal Terms,Configuration
+@anchor{taler-auditor-manual adding-translations}@anchor{21}
+@section Adding translations
+
+
+Translations must be available in subdirectories
+@code{locale/$LANGUAGE/LC_MESSAGES/$ETAG.po}.
+To start translating, you first need to add a new
+language:
+
+@example
+$ taler-terms-generator -i $ETAG -l $LANGUAGE
+@end example
+
+Here, @code{$LANGUAGE} should be a two-letter language
+code like @code{de} or @code{fr}.  The command will generate
+a file @code{locale/$LANGUAGE/LC_MESSAGES/$ETAG.po}
+which contains each English sentence or paragraph
+in the original document and an initially empty
+translation.  Translators should update the @code{.po}
+file. Afterwards, simply re-run
+
+@example
+$ taler-terms-generator -i $ETAG
+@end example
+
+to make the current translation(s) available to the
+service.
+
+@cartouche
+@quotation Note 
+You must restart the service whenever adding or updating legal documents or their translations.
+@end quotation
+@end cartouche
+
+@node Updating legal documents,,Adding translations,Configuration
+@anchor{taler-auditor-manual updating-legal-documents}@anchor{22}
+@section Updating legal documents
+
+
+When making minor changes without legal implications, edit the @code{.rst} file,
+then re-run the step to add a new language for each existing translation to
+produce an updated @code{.po} file. Translate the sentences that have changed and
+finally run the generator (without @code{-l}) on the ETAG (@code{-i $ETAG}) to
+create the final files.
+
+When making major changes with legal implications, you should first rename (or
+copy) the existing @code{.rst} file and the associated translation files to a new
+unique name.  Afterwards, make the major changes, update the @code{.po} files,
+complete the translations and re-create the final files.  Finally, do not
+forget to update the @code{ETAG} configuration option to the new name and to
+restart the service.
+
 @node Deployment,Operation,Configuration,Top
-@anchor{taler-auditor-manual auditordeployment}@anchor{1b}@anchor{taler-auditor-manual deployment}@anchor{1c}
+@anchor{taler-auditor-manual auditordeployment}@anchor{23}@anchor{taler-auditor-manual deployment}@anchor{24}
 @chapter Deployment
 
-@anchor{taler-auditor-manual wallets}@anchor{1d}
+@anchor{taler-auditor-manual wallets}@anchor{25}
 Before GNU Taler wallets will happily interact with an exchange, the
-respective auditor's public key (as obtained via @code{taler-auditor-offline
+respective auditor’s public key (as obtained via @code{taler-auditor-offline
 setup} from the @code{offline} user) must be added under the respective currency
 to the wallet.  This is usually expected to be hard-coded into the Taler
 wallet.
@@ -1005,7 +1309,7 @@ wallet.
 Users can also manually add auditors for a particular currency via a
 Web page offering the respective pairing.
 
-FIXME-DOLD: explain how that Web page works, once it works...
+FIXME-DOLD: explain how that Web page works, once it works…
 
 @menu
 * Exchange:: 
@@ -1015,17 +1319,17 @@ FIXME-DOLD: explain how that Web page works, once it works...
 @end menu
 
 @node Exchange,Signing Denominations,,Deployment
-@anchor{taler-auditor-manual auditorexchange}@anchor{1e}@anchor{taler-auditor-manual exchange}@anchor{1f}
+@anchor{taler-auditor-manual auditorexchange}@anchor{26}@anchor{taler-auditor-manual exchange}@anchor{27}
 @section Exchange
 
 
-The next step is to add the exchange's master public key and the base URL of
+The next step is to add the exchange’s master public key and the base URL of
 the exchange to the list of exchanges audited by the auditor.  This is done
 using the @code{taler-auditor-exchange} tool.  The tool basically creates the
-respective record in the auditor's database.
+respective record in the auditor’s database.
 
 If this step is skipped, the auditor will malfunction at all future stages
-with a foreign key violation, as it does not know the exchange's master public
+with a foreign key violation, as it does not know the exchange’s master public
 key.
 
 @example
@@ -1035,18 +1339,18 @@ $ taler-auditor-exchange -m $MASTER_PUB -u $EXCHANGE_BASE_URL
 
 An equivalent step must be performed by the exchange operator.  Here, the
 exchange operator must use the @code{taler-exchange-offline} tool to add the
-auditor's public key, base URL and (business) name to the list of approved
+auditor’s public key, base URL and (business) name to the list of approved
 auditors of the exchange. For details, see Auditor-configuration in the
 exchange operator manual.
 
 @node Signing Denominations,Database<2>,Exchange,Deployment
-@anchor{taler-auditor-manual signing-denominations}@anchor{20}@anchor{taler-auditor-manual signingdenominations}@anchor{21}
+@anchor{taler-auditor-manual signing-denominations}@anchor{28}@anchor{taler-auditor-manual signingdenominations}@anchor{29}
 @section Signing Denominations
 
 
 @geindex maintenance
 
-These steps must be performed @emph{regularly} whenever the exchange is
+These steps must be performed `regularly' whenever the exchange is
 deploying new denomination keys. After the exchange operator
 has signed new keys using the @code{taler-exchange-offline} tool,
 each auditor should run:
@@ -1073,7 +1377,7 @@ process that is outside of the scope of this document.
 Note that the @code{input.json} does not contain any confidential data.  However,
 signing the wrong keys would be fatal in that it may allow an illegitimate
 exchange to convince users that it is a trustworthy operator and subsequently
-betray the user's trust that is anchored in the existence of a trustworthy
+betray the user’s trust that is anchored in the existence of a trustworthy
 auditor.
 
 Given the verified JSON input, the auditor can then sign it (typically
@@ -1103,26 +1407,26 @@ Commands, like @code{taler-auditor-offline}, that support the @code{-l LOGFILE}
 command-line option, send logging output to standard error by default.
 
 @node Database<2>,,Signing Denominations,Deployment
-@anchor{taler-auditor-manual auditordatabaseinitialization}@anchor{22}@anchor{taler-auditor-manual id1}@anchor{23}
+@anchor{taler-auditor-manual auditordatabaseinitialization}@anchor{2a}@anchor{taler-auditor-manual id1}@anchor{2b}
 @section Database
 
 
 The next key step for the auditor is to configure replication of the
-@emph{exchange}'s database in-house. This should be performed in two steps
+`exchange'’s database in-house. This should be performed in two steps
 as illustrated in the following figure:
 
 @image{taler-auditor-figures/replication,,,,png}
 
 First, the exchange should use standard PostgreSQL replication features to
-enable the auditor to obtain a full copy of the exchange's database.
-Second, the auditor should make a "trusted" local copy, ensuring that it
+enable the auditor to obtain a full copy of the exchange’s database.
+Second, the auditor should make a “trusted” local copy, ensuring that it
 never replicates malicious changes using @code{taler-auditor-sync}. Both
 of these steps are described in more detail below.
 
 We note that as a result of these steps, the auditor will have three
 databases: its own production primary database (as configured in
-@code{auditordb-postgres}), its on production copy of the exchange's database
-(@code{exchangedb-postgress}), and a third, untrusted "ingres" copy of the
+@code{auditordb-postgres}), its on production copy of the exchange’s database
+(@code{exchangedb-postgress}), and a third, untrusted “ingres” copy of the
 exchange database.  The untrusted database should run as a separate PostgreSQL
 instance and is only accessed via @code{taler-auditor-sync} and the replication
 mechanism driven by the exchange operator.
@@ -1134,11 +1438,11 @@ mechanism driven by the exchange operator.
 @end menu
 
 @node Ingres replication of the exchange production database,Safe replication of the ingres database into the auditor production database,,Database<2>
-@anchor{taler-auditor-manual ingres-replication-of-the-exchange-production-database}@anchor{24}
+@anchor{taler-auditor-manual ingres-replication-of-the-exchange-production-database}@anchor{2c}
 @subsection Ingres replication of the exchange production database
 
 
-Ingres operation should be done using the @code{auditor-ingres} user --- or
+Ingres operation should be done using the @code{auditor-ingres} user — or
 depending on the setup parts of the operation may be done by the @code{postgres}
 user directly.
 
@@ -1151,10 +1455,10 @@ that asynchronous replication should suffice.
 
 The resulting auditor database should be treated as read-only on the auditor
 side.  The @code{taler-exchange-dbinit} tool can be used to setup the schema, or
-the schema can be replicated using PostgreSQL's standard mechanisms. The same
+the schema can be replicated using PostgreSQL’s standard mechanisms. The same
 applies for schema upgrades: if logical replication is used (which does not
 replicate schema changes), @code{taler-exchange-dbinit} can be used to migrate
-the schema(s) in both the ingres and production copies of the exchange's
+the schema(s) in both the ingres and production copies of the exchange’s
 database as well.
 
 On the exchange side, a database user must be created that has the right
@@ -1168,7 +1472,7 @@ $ echo "CREATE PUBLICATION $NAME FOR ALL TABLES;" | psql taler-exchange
 @end example
 
 The exchange must share the password of the publication with the auditor. A
-good @code{$NAME} relates to the auditor's business unit name.  A secure tunnel
+good @code{$NAME} relates to the auditor’s business unit name.  A secure tunnel
 must be setup between the exchange and the auditor, for example using SSH or
 Wireguard.
 
@@ -1191,7 +1495,7 @@ PostgreSQL configuration:
 wal_level= logical
 @end example
 
-Next, the @code{postgres} user of the auditor's system must first initialize the
+Next, the @code{postgres} user of the auditor’s system must first initialize the
 local tables:
 
 @example
@@ -1201,7 +1505,7 @@ $ taler-config -s exchangedb-postgres -o CONFIG -V "postgres:///taler-ingress"
 $ taler-exchange-dbinit
 @end example
 
-To complete the replication, the @code{postgres} user of the auditor's
+To complete the replication, the @code{postgres} user of the auditor’s
 system must subscribe:
 
 @example
@@ -1218,7 +1522,7 @@ For details, we refer to the PostgreSQL manual.
 Depending on the replication method used, the exchange may perform
 unexpected changes to the schema or perform @code{UPDATE}, @code{DELETE} or
 @code{DROP} operations on the tables.  Hence, the auditor cannot rely upon the
-exchange's primary copy to respect schema constraints, especially as we
+exchange’s primary copy to respect schema constraints, especially as we
 have to presume that the exchange could act maliciously.  Furthermore, it
 is unclear to what degree PostgreSQL database replication mechanisms are
 robust against a malicious master database.  Thus, the auditor should
@@ -1228,25 +1532,25 @@ process, from its actual operational data.
 @end cartouche
 
 @node Safe replication of the ingres database into the auditor production database,,Ingres replication of the exchange production database,Database<2>
-@anchor{taler-auditor-manual safe-replication-of-the-ingres-database-into-the-auditor-production-database}@anchor{25}
+@anchor{taler-auditor-manual safe-replication-of-the-ingres-database-into-the-auditor-production-database}@anchor{2d}
 @subsection Safe replication of the ingres database into the auditor production database
 
 
 Using @code{taler-auditor-sync} as the @code{sync} user, the auditor should
-make a second "safe" copy of the exchange's ingres database.
+make a second “safe” copy of the exchange’s ingres database.
 @code{taler-auditor-sync} basically reads from one exchange database and inserts
 all records found into a second exchange database. If the source database
 violates invariants, the tool halts with an error. This way, records violating
 invariants are never even copied, and in particular schema changes and
-deletions or updates are not propagated into the auditor's production
+deletions or updates are not propagated into the auditor’s production
 database.
 
 While @code{taler-auditor-sync} could in theory be run directly against the
-exchange's production system, this is likely a bad idea due to the high
+exchange’s production system, this is likely a bad idea due to the high
 latency from the network between auditor and exchange operator. Thus, we
-recommend first making an "untrusted" ingress copy of the exchange's
+recommend first making an “untrusted” ingress copy of the exchange’s
 production database using standard PostgreSQL tooling, and then using
-@code{taler-auditor-sync} to create a second "safe" copy.  The "safe" copy used
+@code{taler-auditor-sync} to create a second “safe” copy.  The “safe” copy used
 by the production system should also run under a different UID.
 
 Before @code{taler-auditor-sync} can be used, the target database must be
@@ -1278,15 +1582,15 @@ $ taler-auditor-sync -s src.conf -d dst.cfg -t
 
 When the exchange performs garbage collection to @code{DELETE} obsolete records,
 this change should be automatically replicated to the auditors untrusted
-ingress database.  However, as @code{taler-auditor-sync} tries to be "safe",
-it will not replicate those deletions to the auditor's production database.
+ingress database.  However, as @code{taler-auditor-sync} tries to be “safe”,
+it will not replicate those deletions to the auditor’s production database.
 Thus, it is necessary to (occasonally) run @code{taler-exchange-dbinit -g} on
-the auditor's production database to garbage collect old data in the
-auditor's production copy.  We note that this does not have to be done
+the auditor’s production database to garbage collect old data in the
+auditor’s production copy.  We note that this does not have to be done
 at the same time when the exchange runs its garbage collection.
 
 @node Operation,Auditor implementation guide,Deployment,Top
-@anchor{taler-auditor-manual id2}@anchor{26}@anchor{taler-auditor-manual operation}@anchor{27}
+@anchor{taler-auditor-manual id2}@anchor{2e}@anchor{taler-auditor-manual operation}@anchor{2f}
 @chapter Operation
 
 
@@ -1302,13 +1606,13 @@ at the same time when the exchange runs its garbage collection.
 @end menu
 
 @node Web service,Audit,,Operation
-@anchor{taler-auditor-manual id3}@anchor{28}@anchor{taler-auditor-manual web-service}@anchor{29}
+@anchor{taler-auditor-manual id3}@anchor{30}@anchor{taler-auditor-manual web-service}@anchor{31}
 @section Web service
 
 
 The @code{taler-auditor-httpd} runs the required REST API for the auditor.  The
 service must have @code{INSERT} (and @code{SELECT}) rights on the
-@code{deposit_confirmations} table in the auditor's database.  We expect that in
+@code{deposit_confirmations} table in the auditor’s database.  We expect that in
 future versions additional rights may be required.
 
 For now, we recommend simply running the @code{taler-auditor-httpd} under the
@@ -1319,7 +1623,7 @@ As the @code{taler-auditor-httpd} does not include HTTPS-support, it is
 advisable to run it behind a reverse proxy that offers TLS termination.
 
 @node Audit,Reading the report,Web service,Operation
-@anchor{taler-auditor-manual audit}@anchor{2a}@anchor{taler-auditor-manual id4}@anchor{2b}
+@anchor{taler-auditor-manual audit}@anchor{32}@anchor{taler-auditor-manual id4}@anchor{33}
 @section Audit
 
 
@@ -1354,11 +1658,11 @@ interactions with the bank (which may not even have the wire transfer records
 anymore), this is not recommended in a production setup.
 
 @node Reading the report,Database upgrades,Audit,Operation
-@anchor{taler-auditor-manual reading-the-report}@anchor{2c}
+@anchor{taler-auditor-manual reading-the-report}@anchor{34}
 @section Reading the report
 
 
-The auditor's report needs to be read carefully, as it includes
+The auditor’s report needs to be read carefully, as it includes
 several categories of failures of different severity:
 
 
@@ -1390,7 +1694,7 @@ Configuration issues (such was wire fees unavailable).
 @end itemize
 
 @node Database upgrades,Database reset,Reading the report,Operation
-@anchor{taler-auditor-manual auditordatabaseupgrades}@anchor{2d}@anchor{taler-auditor-manual database-upgrades}@anchor{2e}
+@anchor{taler-auditor-manual auditordatabaseupgrades}@anchor{35}@anchor{taler-auditor-manual database-upgrades}@anchor{36}
 @section Database upgrades
 
 
@@ -1416,7 +1720,7 @@ halting the exchange business logic,
 
 @item 
 allowing the replication and @code{taler-auditor-sync} to complete
-(see also the @strong{-t} option of @code{taler-auditor-sync})
+(see also the `-t' option of @code{taler-auditor-sync})
 
 @item 
 completing a @code{taler-audit} run against the old schema
@@ -1424,14 +1728,14 @@ completing a @code{taler-audit} run against the old schema
 @item 
 migrating the exchange schema (@code{taler-exchange-dbinit}) of
 the master database, possibly the ingres database and the
-auditor's production copy
+auditor’s production copy
 
 @item 
 migrating the auditor database (@code{taler-auditor-dbinit})
 
 @item 
-resuming database replication between the exchange's master
-database and the auditor's ingres copy
+resuming database replication between the exchange’s master
+database and the auditor’s ingres copy
 
 @item 
 resuming @code{taler-auditor-sync}
@@ -1445,7 +1749,7 @@ Regardless, the above is merely the general rule. Please review the specific
 release notes to ensure this procedure is correct for the specific upgrade.
 
 @node Database reset,Revocations,Database upgrades,Operation
-@anchor{taler-auditor-manual database-reset}@anchor{2f}
+@anchor{taler-auditor-manual database-reset}@anchor{37}
 @section Database reset
 
 
@@ -1456,14 +1760,14 @@ $ taler-auditor-dbinit -R
 @end example
 
 However, running this command will result in all data in the database being
-@emph{lost}, including steps like enabling an exchange using
+`lost', including steps like enabling an exchange using
 @code{taler-auditor-exchange}. Thus, doing so may result in significant
 commputation (and bandwidth consumption with the bank) when the auditor is
 next launched, as it will re-download and re-verify all historic transactions.
 Hence this should not be done in a production system.
 
 @node Revocations,Failures,Database reset,Operation
-@anchor{taler-auditor-manual auditorrevocations}@anchor{30}@anchor{taler-auditor-manual revocations}@anchor{31}
+@anchor{taler-auditor-manual auditorrevocations}@anchor{38}@anchor{taler-auditor-manual revocations}@anchor{39}
 @section Revocations
 
 
@@ -1476,29 +1780,29 @@ For more information, see Revocations in the exchange operator manual.
 If all denominations of an exchange are revoked, the exchange includes logic
 to wire back all returned funds to the bank accounts from which they
 originate.  If some denominations remain operational, wallets will generally
-exchange old coins of revoked denominations for new coins -- while providing
+exchange old coins of revoked denominations for new coins – while providing
 additional information to demonstrate that these coins were not forged from
 the compromised private key but obtained via a legitimate withdraw operation.
 
 @node Failures,,Revocations,Operation
-@anchor{taler-auditor-manual failures}@anchor{32}
+@anchor{taler-auditor-manual failures}@anchor{3a}
 @section Failures
 
 
-Most audit failures are handled by the auditor's regular reporting functionality,
+Most audit failures are handled by the auditor’s regular reporting functionality,
 creating a (hopefully descriptive) PDF report detailing the problems found.
 
 However, there is one category of errors where this is not possible, which
-concerns arithmetic overflows for amounts. Taler's specification limits amount
-values to at most 2^52. If, during the auditor's calculations, amounts are
+concerns arithmetic overflows for amounts. Taler’s specification limits amount
+values to at most 2^52. If, during the auditor’s calculations, amounts are
 encountered that exceed this threshold, the auditor will not generate a regular
 report, but instead write a log statement explaining where the problem happened
-and exit with a status code of @emph{42}.
+and exit with a status code of `42'.
 
 The most common expected case when this happens is a corrupted database. This
 could be because the exchange is actively malicious, or more likely due to
 some data corruption.  The audit cannot continue until the corruption has been
-addressed. If it is not possible to restore a fully @emph{correct} version of the
+addressed. If it is not possible to restore a fully `correct' version of the
 database, the suggestion is to replace the corrupted (and likely very large)
 amounts with zero (Note: this does not apply to the value of denominations or
 fees, here it is crucial that the correct amounts are restored). While an
@@ -1507,14 +1811,14 @@ calculations with zero instead.
 
 After patching the database, the audit can
 be restarted. A full reset is not required, as the audit transaction is aborted
-when the auditor exits with code @emph{42}.  After restarting, the resulting audit
+when the auditor exits with code `42'.  After restarting, the resulting audit
 report is likely to indicates errors relating to the corrupted fields (such as
 invalid signatures, arithmetic errors by the exchange, etc.), but at least the
 loss/gain calculations will be meaningful and actually indicative of the scope
 of the error created by the corrupted data.
 
 @node Auditor implementation guide,Index,Operation,Top
-@anchor{taler-auditor-manual auditor-implementation-guide}@anchor{33}
+@anchor{taler-auditor-manual auditor-implementation-guide}@anchor{3b}
 @chapter Auditor implementation guide
 
 
@@ -1522,15 +1826,15 @@ The auditor implementation is split into five main processes, called
 @code{taler-helper-auditor-XXX}.  The split was done to realize the principle of
 least privilege and to enable independent logic to be possibly run in
 parallel.  Only the taler-wire-auditor must have (read-only) access to the
-exchange's bank account, the other components only need access to the
+exchange’s bank account, the other components only need access to the
 database.
 
 All auditor subsystems basically start their audit from a certain transaction
 index (@code{BIG SERIAL}) in the auditor database which identifies where the last
 audit concluded. They then check that the transactions claimed in the
-exchange's database match up internally, including the cryptographic
+exchange’s database match up internally, including the cryptographic
 signatures and also with respect to amounts adding up. The auditor also
-calculates the exchange's profits and expected bank balances.  Once all
+calculates the exchange’s profits and expected bank balances.  Once all
 existing transactions are processed, the auditor processes store the current
 checkpoint in its database and generate a JSON report.
 
@@ -1539,23 +1843,23 @@ uses Jinja2 with a TeX template to convert the five individual
 JSON reports into LaTeX and then into PDF.
 
 @menu
-* The auditor's database:: 
+* The auditor’s database:: 
 * Invariants checked by the auditor:: 
 * Testing the auditor:: 
 
 @end menu
 
-@node The auditor's database,Invariants checked by the auditor,,Auditor implementation guide
-@anchor{taler-auditor-manual the-auditor-s-database}@anchor{34}
-@section The auditor's database
+@node The auditor’s database,Invariants checked by the auditor,,Auditor implementation guide
+@anchor{taler-auditor-manual the-auditor-s-database}@anchor{3c}
+@section The auditor’s database
 
 
 The database scheme used by the exchange looks as follows:
 
 @image{taler-auditor-figures/auditor-db,,,,png}
 
-@node Invariants checked by the auditor,Testing the auditor,The auditor's database,Auditor implementation guide
-@anchor{taler-auditor-manual invariants-checked-by-the-auditor}@anchor{35}
+@node Invariants checked by the auditor,Testing the auditor,The auditor’s database,Auditor implementation guide
+@anchor{taler-auditor-manual invariants-checked-by-the-auditor}@anchor{3d}
 @section Invariants checked by the auditor
 
 
@@ -1575,11 +1879,11 @@ pass where it might seem applicable.
 @end menu
 
 @node Invariants checked by the taler-helper-auditor-aggregation,Invariants checked by the taler-helper-auditor-coins,,Invariants checked by the auditor
-@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-aggregation}@anchor{36}
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-aggregation}@anchor{3e}
 @subsection Invariants checked by the taler-helper-auditor-aggregation
 
 
-This is from CodeBlau's analysis. A proper write-up is pending.
+This is from CodeBlau’s analysis. A proper write-up is pending.
 CodeBlau reports the following checks:
 
 
@@ -1687,11 +1991,11 @@ wire fee unavailable for given time
 @end itemize
 
 @node Invariants checked by the taler-helper-auditor-coins,Invariants checked by the taler-helper-auditor-deposits,Invariants checked by the taler-helper-auditor-aggregation,Invariants checked by the auditor
-@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-coins}@anchor{37}
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-coins}@anchor{3f}
 @subsection Invariants checked by the taler-helper-auditor-coins
 
 
-This is from CodeBlau's analysis. A proper write-up is pending.
+This is from CodeBlau’s analysis. A proper write-up is pending.
 CodeBlau reports the following checks:
 
 
@@ -1699,9 +2003,9 @@ CodeBlau reports the following checks:
 
 @item 
 check that all denominations used by the exchange have been signed using
-this auditor's key. All denominations encountered in the database that
+this auditor’s key. All denominations encountered in the database that
 this auditor did not officially sign for are reported (but still included
-in the audit as they obviously may impact the exchange's bank balance).
+in the audit as they obviously may impact the exchange’s bank balance).
 Depending on the business situation, this may be normal (say if an exchange
 is changing auditors and newer denominations are no longer supported until
 their end-of-life by the current auditor).
@@ -1783,7 +2087,7 @@ recoup, denomination not revoked
 @end itemize
 
 @node Invariants checked by the taler-helper-auditor-deposits,Invariants checked by the taler-helper-auditor-reserves,Invariants checked by the taler-helper-auditor-coins,Invariants checked by the auditor
-@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-deposits}@anchor{38}
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-deposits}@anchor{40}
 @subsection Invariants checked by the taler-helper-auditor-deposits
 
 
@@ -1793,11 +2097,11 @@ exchange at the auditor.  This is to ensure that the exchange cannot defraud
 merchants by simply not reporting deposits to the auditor.
 
 @node Invariants checked by the taler-helper-auditor-reserves,Invariants checked by the taler-helper-auditor-wire,Invariants checked by the taler-helper-auditor-deposits,Invariants checked by the auditor
-@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-reserves}@anchor{39}
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-reserves}@anchor{41}
 @subsection Invariants checked by the taler-helper-auditor-reserves
 
 
-This is from CodeBlau's analysis. A proper write-up is pending.
+This is from CodeBlau’s analysis. A proper write-up is pending.
 CodeBlau reports the following checks:
 
 
@@ -1854,16 +2158,16 @@ target account does not match origin account
 @end itemize
 
 @node Invariants checked by the taler-helper-auditor-wire,,Invariants checked by the taler-helper-auditor-reserves,Invariants checked by the auditor
-@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-wire}@anchor{3a}
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-wire}@anchor{42}
 @subsection Invariants checked by the taler-helper-auditor-wire
 
 
 This auditor is special in that it is the only pass that is required to have
-@emph{read-only} access to the exchange's bank account (privilege separation).  Its
-main role is to verify that the wire transfers in the exchange's database and
+`read-only' access to the exchange’s bank account (privilege separation).  Its
+main role is to verify that the wire transfers in the exchange’s database and
 those reported by the bank are identical.
 
-This is from CodeBlau's analysis. A proper write-up is pending.
+This is from CodeBlau’s analysis. A proper write-up is pending.
 CodeBlau reports the following checks:
 
 
@@ -1919,13 +2223,13 @@ closing fee above total amount
 @end itemize
 
 @node Testing the auditor,,Invariants checked by the auditor,Auditor implementation guide
-@anchor{taler-auditor-manual testing-the-auditor}@anchor{3b}
+@anchor{taler-auditor-manual testing-the-auditor}@anchor{43}
 @section Testing the auditor
 
 
 The main objective of the auditor is to detect inconsistencies. Thus, the
 @code{test-auditor.sh} script deliberately introduces various inconsistencies into
-a synthetic exchange database.  For this, an "normal" exchange database is
+a synthetic exchange database.  For this, an “normal” exchange database is
 first generated using the @code{taler-wallet-cli}.  Then, various fields or rows
 of that database are manipulated, and the auditor is let loose on the modified
 database.  Afterwards, the test verifies that the JSON contains values
@@ -1938,13 +2242,13 @@ cover as many code paths as possible in both the exchange and the auditor.  It
 should also ideally create all interesting possible variations of the exchange
 database fields (within the constraints of the database schema).
 
-In general, @code{test-auditor.sh} runs the tests against an "old" database where
+In general, @code{test-auditor.sh} runs the tests against an “old” database where
 some transactions are past the due-date (and hence the aggregator would trigger
 wire transfers), as well as a freshly generated exchange database where the
 auditor would not perform any transfers.  Auditor interactions can be made
 before or after the aggregator, depending on what is being tested.
 
-The current script also rudimentarily tests the auditor's resume logic,
+The current script also rudimentarily tests the auditor’s resume logic,
 by re-starting the auditor once against a database that the auditor has
 already seen.
 
diff --git a/texinfo/taler-developer-manual-figures/arch-api.png b/texinfo/taler-developer-manual-figures/arch-api.png
index 8004f790..9e593ab4 100644
--- a/texinfo/taler-developer-manual-figures/arch-api.png
+++ b/texinfo/taler-developer-manual-figures/arch-api.png
diff --git a/texinfo/taler-developer-manual-figures/exchange-db.png b/texinfo/taler-developer-manual-figures/exchange-db.png
index f99e2664..7a4050c6 100644
--- a/texinfo/taler-developer-manual-figures/exchange-db.png
+++ b/texinfo/taler-developer-manual-figures/exchange-db.png
diff --git a/texinfo/taler-developer-manual.texi b/texinfo/taler-developer-manual.texi
index 247338d7..0df117ea 100644
--- a/texinfo/taler-developer-manual.texi
+++ b/texinfo/taler-developer-manual.texi
@@ -3,7 +3,7 @@
 @setfilename taler-developer-manual.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 3.4.3.@*
+@*Generated by Sphinx 5.3.0.@*
 @end ifinfo
 @settitle Taler Developer Manual
 @defindex ge
@@ -15,13 +15,11 @@
 * MENU ENTRY: (taler-developer-manual.info). DESCRIPTION
 @end direntry
 
-@definfoenclose strong,`,'
-@definfoenclose emph,`,'
 @c %**end of header
 
 @copying
 @quotation
-GNU Taler 0.9.0, Nov 03, 2022
+GNU Taler 0.9.0, Sep 24, 2023
 
 GNU Taler team
 
@@ -68,6 +66,8 @@ Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 @menu
 * GNU Taler Release Checklists:: 
 * GNU Taler Demo Upgrade Checklist:: 
+* Guidelines for Python Packages:: 
+* Project Overview:: 
 * Fundamentals:: 
 * Debian and Ubuntu Repositories:: 
 * Language-Specific Guidelines:: 
@@ -77,6 +77,7 @@ Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 * Releases:: 
 * Continuous integration:: 
 * Internationalization:: 
+* iOS Apps:: 
 * Android Apps:: 
 * Code Coverage:: 
 * Coding Conventions:: 
@@ -99,10 +100,10 @@ For exchange:
 @itemize -
 
 @item 
- no compiler warnings at "-Wall" with gcc
+ no compiler warnings at “-Wall” with gcc
 
 @item 
- no compiler warnings at "-Wall" with clang
+ no compiler warnings at “-Wall” with clang
 
 @item 
  ensure Coverity static analysis passes
@@ -111,19 +112,22 @@ For exchange:
  make check.
 
 @item 
- make dist, make check on result of 'make dist'.
+ make dist, make check on result of ‘make dist’.
 
 @item 
  Change version number in configure.ac.
 
 @item 
+ update man pages / info page documentation (prebuilt branch)
+
+@item 
  make dist for release
 
 @item 
  verify dist builds from source
 
 @item 
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
 
 @item 
  run @ref{4,,demo upgrade checklist}
@@ -132,13 +136,13 @@ For exchange:
  tag repo.
 
 @item 
- use deployment.git/packaging/>>*<<-docker/ to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
 
 @item 
- upload packages to deb.taler.net/ (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
 
 @item 
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
 
 @item 
  Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -150,10 +154,10 @@ For merchant (C backend):
 @itemize -
 
 @item 
- no compiler warnings at "-Wall" with gcc
+ no compiler warnings at “-Wall” with gcc
 
 @item 
- no compiler warnings at "-Wall" with clang
+ no compiler warnings at “-Wall” with clang
 
 @item 
  ensure Coverity static analysis passes
@@ -162,7 +166,10 @@ For merchant (C backend):
  make check.
 
 @item 
- make dist, make check on result of 'make dist'.
+ make dist, make check on result of ‘make dist’.
+
+@item 
+ update SPA (prebuilt branch)
 
 @item 
  Change version number in configure.ac.
@@ -174,7 +181,58 @@ For merchant (C backend):
  verify dist builds from source
 
 @item 
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
+
+@item 
+ run @ref{4,,demo upgrade checklist}
+
+@item 
+ tag repo.
+
+@item 
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
+
+@item 
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
+
+@item 
+ change ‘demo.taler.net’ deployment to use new tag.
+
+@item 
+ Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
+@end itemize
+
+For sync:
+
+
+@itemize -
+
+@item 
+ no compiler warnings at “-Wall” with gcc
+
+@item 
+ no compiler warnings at “-Wall” with clang
+
+@item 
+ ensure Coverity static analysis passes
+
+@item 
+ make check.
+
+@item 
+ make dist, make check on result of ‘make dist’.
+
+@item 
+ Change version number in configure.ac.
+
+@item 
+ make dist for release
+
+@item 
+ verify dist builds from source
+
+@item 
+ upgrade ‘demo.taler.net’
 
 @item 
  run @ref{4,,demo upgrade checklist}
@@ -183,13 +241,85 @@ For merchant (C backend):
  tag repo.
 
 @item 
- use deployment.git/packaging/>>*<<-docker/ to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
 
 @item 
- upload packages to deb.taler.net/ (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
 
 @item 
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
+
+@item 
+ Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
+@end itemize
+
+For taler-mdb:
+
+
+@itemize -
+
+@item 
+ no compiler warnings at “-Wall” with gcc
+
+@item 
+ ensure Coverity static analysis passes
+
+@item 
+ Change version number in configure.ac.
+
+@item 
+ make dist for release.
+
+@item 
+ tag repo.
+
+@item 
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
+
+@item 
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
+
+@item 
+ Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
+@end itemize
+
+For taler-twister:
+
+
+@itemize -
+
+@item 
+ no compiler warnings at “-Wall” with gcc
+
+@item 
+ no compiler warnings at “-Wall” with clang
+
+@item 
+ ensure Coverity static analysis passes
+
+@item 
+ make check.
+
+@item 
+ make dist, make check on result of ‘make dist’.
+
+@item 
+ Change version number in configure.ac.
+
+@item 
+ make dist for release.
+
+@item 
+ verify dist builds from source
+
+@item 
+ upgrade ‘demo.taler.net’
+
+@item 
+ run @ref{4,,demo upgrade checklist}
+
+@item 
+ tag repo.
 
 @item 
  Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -207,7 +337,7 @@ For libeufin:
  build libeufin
 
 @item 
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
 
 @item 
  run @ref{4,,demo upgrade checklist}
@@ -222,13 +352,13 @@ For libeufin:
  tag repo.
 
 @item 
- use deployment.git/packaging/>>*<<-docker/ to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
 
 @item 
- upload packages to deb.taler.net/ (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
 
 @item 
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
 
 @item 
  Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -240,13 +370,13 @@ For Python merchant frontend:
 @itemize -
 
 @item 
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
 
 @item 
  run @ref{4,,demo upgrade checklist}
 
 @item 
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
 @end itemize
 
 Wallet-core:
@@ -270,7 +400,13 @@ Wallet-core:
  tag repo.
 
 @item 
- change 'demo.taler.net' deployment to use new tag.
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
+
+@item 
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
+
+@item 
+ change ‘demo.taler.net’ deployment to use new tag.
 
 @item 
  Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -330,7 +466,7 @@ Release announcement:
  Send announcement to @email{coordinator@@translationproject.org}
 @end itemize
 
-@node GNU Taler Demo Upgrade Checklist,Fundamentals,GNU Taler Release Checklists,Top
+@node GNU Taler Demo Upgrade Checklist,Guidelines for Python Packages,GNU Taler Release Checklists,Top
 @anchor{checklist-demo-upgrade doc}@anchor{4}@anchor{checklist-demo-upgrade gnu-taler-demo-upgrade-checklist}@anchor{5}
 @chapter GNU Taler Demo Upgrade Checklist
 
@@ -341,9 +477,6 @@ Post-upgrade checks:
 @itemize -
 
 @item 
- Run @code{taler-deployment-arm -I} to verify that all services are running.
-
-@item 
  Run the headless wallet to check that services are actually working:
 
 @example
@@ -418,7 +551,7 @@ Blog demo:
 
 @item 
  Go back to @indicateurl{https://shop.demo.taler.net/} and click on the same article
-link.  Verify that the article is shown and @strong{no} repeated payment is
+link.  Verify that the article is shown and `no' repeated payment is
 requested.
 
 @item 
@@ -469,13 +602,67 @@ that the payment is requested again, instead of showing the previous
 fulfillment page.
 @end itemize
 
-Survey/Tipping:
+Merchant SPA:
 
 
 @itemize -
 
 @item 
- Visit @indicateurl{https://survey.demo.taler.net/} and receive a tip.
+ test SPA loads
+
+@item 
+ try to login with wrong password
+
+@item 
+ try to login with correct password
+
+@item 
+ create instance
+
+@item 
+ modify instance
+
+@item 
+ add product
+
+@item 
+ add order with inventory product
+
+@item 
+ pay for order with wallet
+
+@item 
+ trigger refund
+
+@item 
+ accept refund with wallet
+
+@item 
+ TBD: rewards
+
+@item 
+ TBD: products with previews
+
+@item 
+ TBD: inventory management
+
+@item 
+ TBD: adding transactions
+
+@item 
+ TBD: test various settings
+
+@item 
+ TBD: …
+@end itemize
+
+Survey/Rewards:
+
+
+@itemize -
+
+@item 
+ Visit @indicateurl{https://survey.demo.taler.net/} and receive a reward.
 
 @item 
  Verify that the survey stats page (@indicateurl{https://survey.demo.taler.net/survey-stats}) is working,
@@ -509,6 +696,124 @@ P2P payments:
  delete history entry
 @end itemize
 
+@node Guidelines for Python Packages,Project Overview,GNU Taler Demo Upgrade Checklist,Top
+@anchor{python-guidelines doc}@anchor{6}@anchor{python-guidelines guidelines-for-python-packages}@anchor{7}
+@chapter Guidelines for Python Packages
+
+
+This document describes conventions used for Python repos in the Taler project.
+
+@menu
+* Packaging:: 
+* GNU Compatibility Layer:: 
+* Formatting:: 
+* Distro Packaging:: 
+
+@end menu
+
+@node Packaging,GNU Compatibility Layer,,Guidelines for Python Packages
+@anchor{python-guidelines packaging}@anchor{8}
+@section Packaging
+
+
+
+@itemize *
+
+@item 
+We use poetry@footnote{https://github.com/python-poetry/poetry} for managing dependencies and dev-dependencies.
+
+@item 
+The @code{poetry.lock} file must be committed to repo.
+
+@item 
+Entry points `must not' be defined as shell scripts.  Instead, use poetry’s script facility to define entry points.  This makes the package work on different platforms properly.
+@end itemize
+
+@node GNU Compatibility Layer,Formatting,Packaging,Guidelines for Python Packages
+@anchor{python-guidelines gnu-compatibility-layer}@anchor{9}
+@section GNU Compatibility Layer
+
+
+In addition to the Python-native tooling, we provide a GNU-style interface for the build system.
+The commands supported by every Python repo should be:
+
+
+@itemize *
+
+@item 
+@code{./bootstrap}:  Only necessary when the repo is checked out via git.
+Initializes the build system and checks out git submodules if applicable.
+
+@item 
+@code{./configure}:  Should check for build-time dependencies, `including' Python tooling.
+
+@item 
+@code{make}: Invoking make without a target should create the Python wheel for the project.
+
+@item 
+@code{make install}: Installation should `only' install the Python package
+based on the wheel via @code{pip}.  Note that we can’t do dependency tracking
+properly, so the @code{install} target will always re-build the wheel and
+install it.
+
+@item 
+@code{make pretty}: Should invoke the pretty-printer (@code{black} for Python projects).
+
+@item 
+@code{make dist}: This should create the source tarball.
+
+@item 
+@code{make clean}: Should delete generated files.
+@end itemize
+
+The build-common.git@footnote{https://git.taler.net/build-common.git/} repository contains helpers
+to make the GNU compatibility easier.  Here are some hints for using it:
+
+
+@itemize *
+
+@item 
+The @code{build-common.git} repo should added as a submodule in the path @code{build-system/taler-build-scripts}
+of the repository.
+
+@item 
+The bootstrap template@footnote{https://git.taler.net/build-common.git/tree/bootstrap.template} should
+be copied as @code{./bootstrap} to the root of the repository.
+
+@item 
+The configure script is automatically created by @code{./bootstrap}.
+
+@item 
+Dependencies for the configure file are defined in @code{build-system/configure.py}.
+There is no documentation yet, but adjusting the example file@footnote{https://git.taler.net/build-common.git/tree/testconfigure.py} is a good starting point.
+
+@item 
+The source distribution (@code{make dist}) should either be created via @code{poetry build -f sdist}
+or using the git-archive-all@footnote{https://git.taler.net/build-common.git/tree/archive-with-submodules/git_archive_all.py}.
+@end itemize
+
+@node Formatting,Distro Packaging,GNU Compatibility Layer,Guidelines for Python Packages
+@anchor{python-guidelines formatting}@anchor{a}
+@section Formatting
+
+
+
+@itemize *
+
+@item 
+We follow pep8@footnote{https://www.python.org/dev/peps/pep-0008/}.
+
+@item 
+Code should be auto-formatted with black@footnote{https://github.com/psf/black}.
+@end itemize
+
+@node Distro Packaging,,Formatting,Guidelines for Python Packages
+@anchor{python-guidelines distro-packaging}@anchor{b}
+@section Distro Packaging
+
+
+For Debian, we should try to use wheel2deb@footnote{https://github.com/upciti/wheel2deb}.
+
 @cartouche
 @quotation Note 
 This manual contains information for developers working on GNU Taler
@@ -516,8 +821,124 @@ and related components.  It is not intended for a general audience.
 @end quotation
 @end cartouche
 
-@node Fundamentals,Debian and Ubuntu Repositories,GNU Taler Demo Upgrade Checklist,Top
-@anchor{taler-developer-manual fundamentals}@anchor{6}
+@node Project Overview,Fundamentals,Guidelines for Python Packages,Top
+@anchor{taler-developer-manual project-overview}@anchor{c}
+@chapter Project Overview
+
+
+GNU Taler consists of a large (and growing) number of components
+in various Git repositories.  The following list gives a first
+overview:
+
+@quotation
+
+
+@itemize *
+
+@item 
+exchange: core payment processing logic with a REST API, plus various
+helper processes for interaction with banks and cryptographic
+computations. Also includes the logic for the auditor and an
+in-memory “bank” API implementation for testing.
+
+@item 
+libeufin: implementation of the “bank” API using the EBICS protocol
+used by banks in the EU.  Allows an exchange to interact with
+European banks.
+
+@item 
+deploymerization: implementation of the “bank” API on top of
+blockchains, specifically Bitcoin and Ethereum. Allows an exchange
+to interact with crypto-currencies.
+
+@item 
+merchant: payment processing backend to be run by merchants,
+offering a REST API.
+
+@item 
+wallet-core: platform-independent implementation of a wallet to be run by
+normal users. Includes also the WebExtension for various browsers.
+Furthermore, includes various single-page apps used by other
+components (especially as libeufin and merchant).  Also includes
+command-line wallet and tools for testing.
+
+@item 
+taler-android: Android Apps including the Android wallet, the
+Android point-of-sale App and the Android casher app.
+
+@item 
+taler-ios: iOS wallet App.
+
+@item 
+sync: backup service, provides a simple REST API to allow users to
+make encrypted backups of their wallet state.
+
+@item 
+anastasis: key escrow service, provides a simple REST API to allow
+users to distribute encryption keys across multiple providers and
+define authorization policies for key recovery.
+
+@item 
+taler-mdb: integration of Taler with the multi-drop-bus (MDB) API
+used by vending machines. Allows Taler payments to be integrated
+with vending machines.
+
+@item 
+gnu-taler-payment-for-woocommerce: payment plugin for the
+woocommerce (wordpress) E-commerce solution.
+
+@item 
+twister: man-in-the-middle proxy for tests that require fuzzing a
+REST/JSON protocol.  Used for some of our testing.
+
+@item 
+challenger: implementation of an OAuth 2.0 provider that can be used
+to verify that a user can receive SMS or E-mail at particular addresses.
+Used as part of KYC processes of the exchange.
+
+@item 
+taler-mailbox: messaging service used to store and forward payment
+messages to Taler wallets.
+
+@item 
+taldir: directory service used to lookup Taler wallet addresses for
+sending invoices or payments to other wallets.
+
+@item 
+taler-merchant-demos: various demonstration services operated at
+‘demo.taler.net’, including a simple shop, donation page and a
+survey with reward functionality.
+@end itemize
+@end quotation
+
+There are other important repositories without code, including:
+
+@quotation
+
+
+@itemize *
+
+@item 
+gana: Hosted on git.gnunet.org, this repository defines various
+constants used in the GNU Taler project.
+
+@item 
+docs: documentation, including this very document.
+
+@item 
+marketing: various presentations, papers and other resources for
+outreach.
+
+@item 
+large-media: very large data objects, such as videos.
+
+@item 
+www: the taler.net website.
+@end itemize
+@end quotation
+
+@node Fundamentals,Debian and Ubuntu Repositories,Project Overview,Top
+@anchor{taler-developer-manual fundamentals}@anchor{d}
 @chapter Fundamentals
 
 
@@ -534,7 +955,7 @@ and related components.  It is not intended for a general audience.
 @end menu
 
 @node Testing Tools,Manual Testing Database Reset,,Fundamentals
-@anchor{taler-developer-manual testing-tools}@anchor{7}
+@anchor{taler-developer-manual testing-tools}@anchor{e}
 @section Testing Tools
 
 
@@ -557,7 +978,7 @@ The @code{make check} should be able to function without them, but
 their presence permits some tests to run that would otherwise be skipped.
 
 @node Manual Testing Database Reset,Bug Tracking,Testing Tools,Fundamentals
-@anchor{taler-developer-manual manual-testing-database-reset}@anchor{8}
+@anchor{taler-developer-manual manual-testing-database-reset}@anchor{f}
 @section Manual Testing Database Reset
 
 
@@ -578,7 +999,7 @@ doing these steps automatically in the @code{make check} flow.
 (If @code{make check} still fails after the reset, file a bug report as usual.)
 
 @node Bug Tracking,Code Repositories,Manual Testing Database Reset,Fundamentals
-@anchor{taler-developer-manual bug-tracking}@anchor{9}
+@anchor{taler-developer-manual bug-tracking}@anchor{10}
 @section Bug Tracking
 
 
@@ -588,7 +1009,7 @@ needed in order to use the bug tracker, only read access is granted without a
 login.
 
 @node Code Repositories,Committing code,Bug Tracking,Fundamentals
-@anchor{taler-developer-manual code-repositories}@anchor{a}
+@anchor{taler-developer-manual code-repositories}@anchor{11}
 @section Code Repositories
 
 
@@ -603,13 +1024,13 @@ A complete list of all the existing repositories is currently found at
 @indicateurl{https://git.taler.net/}.
 
 @node Committing code,Observing changes,Code Repositories,Fundamentals
-@anchor{taler-developer-manual committing-code}@anchor{b}
+@anchor{taler-developer-manual committing-code}@anchor{12}
 @section Committing code
 
 
 Before you can obtain Git write access, you must sign the copyright
 agreement. As we collaborate closely with GNUnet, we use their
-copyright agreement -- with the understanding that your contributions
+copyright agreement – with the understanding that your contributions
 to GNU Taler are included in the assignment.  You can find the
 agreement on the GNUnet site@footnote{https://gnunet.org/en/copyright.html}.
 Please sign and mail it to Christian Grothoff as he currently collects
@@ -672,7 +1093,7 @@ $ git pull --rebase -S
 @end example
 
 @node Observing changes,Communication,Committing code,Fundamentals
-@anchor{taler-developer-manual observing-changes}@anchor{c}
+@anchor{taler-developer-manual observing-changes}@anchor{13}
 @section Observing changes
 
 
@@ -685,18 +1106,18 @@ it can be high volume, the lists is a good way to follow overall
 development.
 
 @node Communication,What to put in bootstrap,Observing changes,Fundamentals
-@anchor{taler-developer-manual communication}@anchor{d}
+@anchor{taler-developer-manual communication}@anchor{14}
 @section Communication
 
 
-We use the #taler channel on the Freenode IRC network and the @email{taler@@gnu.org}
-public mailinglist for discussions.  Not all developers are active on IRC, but
-all developers should probably subscribe to the low-volume Taler mailinglist.
-There are separate low-volume mailinglists for gnunet-developers (@@gnu.org)
-and for libmicrohttpd (@@gnu.org).
+For public discussions we use the @email{taler@@gnu.org} mailinglist.  All developers
+should subscribe to the low-volume Taler mailinglist.  There are separate
+low-volume mailinglists for gnunet-developers (@@gnu.org) and for libmicrohttpd
+(@@gnu.org).  For internal discussions we use @indicateurl{https://mattermost.taler.net/}
+(invitation only, but also achieved).
 
 @node What to put in bootstrap,,Communication,Fundamentals
-@anchor{taler-developer-manual what-to-put-in-bootstrap}@anchor{e}
+@anchor{taler-developer-manual what-to-put-in-bootstrap}@anchor{15}
 @section What to put in bootstrap
 
 
@@ -712,10 +1133,9 @@ One common submodule is @code{contrib/gana}, which pulls from the
 GNUnet GANA repository@footnote{https://git.gnunet.org/gana.git/}.
 For example, in the
 Taler exchange repository@footnote{https://git.taler.net/exchange.git},
-the bootstrap script eventually runs the @code{git submodule update} command
-early on, and later runs script @code{./contrib/gana.sh}, which in turn
-runs script @code{./contrib/gana-update.sh}, which performs various tasks,
-such as generating the file @code{src/include/taler_signatures.h}.
+the bootstrap script eventually runs the @code{git submodule update --init} command
+early on, and later runs script @code{./contrib/gana-generate.sh}, which
+generates files such as @code{src/include/taler_signatures.h}.
 
 Thus, to update that file, you need to:
 
@@ -734,8 +1154,7 @@ Add it to GANA, in @code{gnunet-signatures/registry.rec}.
 Commit the change, and push it to the GANA Git repo.
 
 @item 
-(in Taler Repo) Change directory to @code{contrib/gana} and run
-command @code{git pull} there.
+(in Taler Repo) Run the @code{contrib/gana-latest.sh} script.
 
 @item 
 Bootstrap, configure, do @code{make install}, @code{make check}, etc.
@@ -749,7 +1168,7 @@ A similar procedure is required for other databases in GANA.
 See file @code{README} in the various directories for specific instructions.
 
 @node Debian and Ubuntu Repositories,Language-Specific Guidelines,Fundamentals,Top
-@anchor{taler-developer-manual debian-and-ubuntu-repositories}@anchor{f}
+@anchor{taler-developer-manual debian-and-ubuntu-repositories}@anchor{16}
 @chapter Debian and Ubuntu Repositories
 
 
@@ -761,7 +1180,7 @@ We package our software for Debian and Ubuntu.
 @end menu
 
 @node Nightly Repositories,,,Debian and Ubuntu Repositories
-@anchor{taler-developer-manual nightly-repositories}@anchor{10}
+@anchor{taler-developer-manual nightly-repositories}@anchor{17}
 @section Nightly Repositories
 
 
@@ -780,7 +1199,7 @@ $ wget -O - https://taler.net/taler-systems-nightly.gpg.key | apt-key add -
 @end example
 
 @node Language-Specific Guidelines,Taler Deployment on gv taler net,Debian and Ubuntu Repositories,Top
-@anchor{taler-developer-manual language-specific-guidelines}@anchor{11}
+@anchor{taler-developer-manual language-specific-guidelines}@anchor{18}
 @chapter Language-Specific Guidelines
 
 
@@ -788,23 +1207,19 @@ $ wget -O - https://taler.net/taler-systems-nightly.gpg.key | apt-key add -
 @itemize *
 
 @item 
-Python Guidelines
+@ref{6,,Python Guidelines}
 @end itemize
 
 @node Taler Deployment on gv taler net,Demo Upgrade Procedure,Language-Specific Guidelines,Top
-@anchor{taler-developer-manual taler-deployment-on-gv-taler-net}@anchor{12}
+@anchor{taler-developer-manual taler-deployment-on-gv-taler-net}@anchor{19}
 @chapter Taler Deployment on gv.taler.net
 
 
-This section describes the GNU Taler deployment on @code{gv.taler.net}.
-@code{gv} is our server at BFH. It hosts the Git repositories, Web sites,
-CI and other services.  Developers can receive an SSH account and
-e-mail alias for the system.  As with Git, ask your primary team
-contact for shell access if you think you need it.
-
-Our old server, @code{tripwire}, is currently offline and will likely
-go back online to host @code{production} systems for operating real
-Taler payments at BFH in the future.
+This section describes the GNU Taler deployment on @code{gv.taler.net}.  @code{gv}
+is our server at BFH. It hosts the Git repositories, Web sites, CI and other
+services.  Developers can receive an SSH account and e-mail alias for the
+system, you should contact Javier, Christian or Florian.  As with Git, ask
+your primary team contact for shell access if you think you need it.
 
 @menu
 * DNS:: 
@@ -813,16 +1228,16 @@ Taler payments at BFH in the future.
 @end menu
 
 @node DNS,User Acccounts,,Taler Deployment on gv taler net
-@anchor{taler-developer-manual dns}@anchor{13}
+@anchor{taler-developer-manual dns}@anchor{1a}
 @section DNS
 
 
-DNS records for taler.net are controlled by the GNU Taler
-maintainers, specifically Christian and Florian. If you
-need a sub-domain to be added, please contact one of them.
+DNS records for taler.net are controlled by the GNU Taler maintainers,
+specifically Christian and Florian, and our system administrator, Javier. If
+you need a sub-domain to be added, please contact one of them.
 
 @node User Acccounts,,DNS,Taler Deployment on gv taler net
-@anchor{taler-developer-manual user-acccounts}@anchor{14}
+@anchor{taler-developer-manual user-acccounts}@anchor{1b}
 @section User Acccounts
 
 
@@ -837,186 +1252,128 @@ serve Taler on the Internet:
 built by Buildbot.
 
 @item 
-@code{taler-internal}: serves @code{*.int.taler.net}, and does @emph{NOT} get
+@code{taler-internal}: serves @code{*.int.taler.net}, and does `NOT' get
 automatically built.
-@end itemize
-
-The following two users are @emph{never} automatically built, and they both
-serve @code{*.demo.taler.net}. At any given time, only one is active and
-serves the HTTP requests from the outside; the other one can so be
-compiled without any downtime. If the compilation succeeds, the inactive
-user can be switched to become active (see next section), and vice versa.
-
-
-@itemize -
 
 @item 
-@code{demo-blue}
-
-@item 
-@code{demo-green}
+@code{demo}: serves @code{*.demo.taler.net}.  Never automatically built.
 @end itemize
 
 @node Demo Upgrade Procedure,Environments and Builders on taler net,Taler Deployment on gv taler net,Top
-@anchor{taler-developer-manual demo-upgrade-procedure}@anchor{15}
+@anchor{taler-developer-manual demo-upgrade-procedure}@anchor{1c}
 @chapter Demo Upgrade Procedure
 
 
-Upgrading the @code{demo} environment should be done with care, and ideally be
-coordinated on the mailing list before.  It is our goal for @code{demo} to always
-run a "working version" that is compatible with various published wallets.
 
-Before deploying on @code{demo}, the same version of all components @strong{must}
-be deployed @emph{and} tested on @code{int}.
+@enumerate 
 
-Please use the @ref{4,,demo upgrade checklist} to make
-sure everything is working.
-
-@menu
-* Tagging components:: 
-* Environment Layout:: 
-* Using envcfg.py: Using envcfg py. 
-* Bootstrapping an Environment:: 
-* Upgrading an Existing Environment:: 
-* Switching Demo Colors:: 
-
-@end menu
-
-@node Tagging components,Environment Layout,,Demo Upgrade Procedure
-@anchor{taler-developer-manual tagging-components}@anchor{16}
-@section Tagging components
+@item 
+Login as the @code{demo} user on @code{gv.taler.net}.
 
+@item 
+Pull the latest @code{deployment.git} code.
 
-All Taler components must be tagged with git before they are deployed on the
-@code{demo} environment, using a tag of the following form:
+@item 
+Navigate to the @code{deployment.git/docker/demo} directory.
 
-@example
-demo-YYYY-MM-DD-SS
-YYYY = year
-MM = month
-DD = day
-SS = serial
-@end example
+@item 
+Refer to the README, or the smaller cheat sheet below.
+@end enumerate
 
-@node Environment Layout,Using envcfg py,Tagging components,Demo Upgrade Procedure
-@anchor{taler-developer-manual environment-layout}@anchor{17}
-@section Environment Layout
+The deployment is based on rootless Docker, managed by the
+SystemD unit in userspace: @code{docker.service}.  The running daemon
+is reached by every Docker command at the address held into the
+@code{DOCKER_HOST} environment variable.  Normally, it points to
+@code{unix:///run/user/$(id -u)/docker.sock}.  Such variable is automatically
+exported by @code{~/.bashrc}.
 
+@cartouche
+@quotation Note 
+@quotation
 
-Environments have the following layout:
+Should the rootless Docker be installed, run the following command
+or consult the official documentation@footnote{https://docs.docker.com/engine/security/rootless/}.
+@end quotation
 
 @example
-$HOME/
-  deployment (deployment.git checkout)
-  envcfg.py  (configuration of the Taler environment)
-  activate   (bash file, sourced to set environment variables)
-  logs/      (log files)
-  local/     (locally installed software)
-  sources/   (sources repos of locally build components)
-  sockets/   (unix domain sockets of running components)
-  taler-data (on-disk state, public and private keys)
-  .config/taler.conf (main Taler configuration file)
+$ curl -fsSL https://get.docker.com/rootless | sh
 @end example
+@end quotation
+@end cartouche
 
-On @code{demo-blue} and @code{demo-green}, @code{taler-data} is a symlink pointing to @code{$HOME/demo/shared-data}
-instead of a directory.
-
-@node Using envcfg py,Bootstrapping an Environment,Environment Layout,Demo Upgrade Procedure
-@anchor{taler-developer-manual using-envcfg-py}@anchor{18}
-@section Using envcfg.py
-
-
-The @code{$HOME/envcfg.py} file contains (1) the name of the environment and (2) the version
-of all components we build (in the form of a git rev).
-
-The @code{envcfg.py} for demo looks like this:
+Upgrading the @code{demo} environment should be done with care, and ideally be
+coordinated on the mailing list before.  It is our goal for @code{demo} to always
+run a “working version” that is compatible with various published wallets.
+Please use the @ref{4,,demo upgrade checklist} to make
+sure everything is working.
+Nginx is already configured to reach the services as exported by
+Docker Compose.
 
-@example
-env = "demo"
-tag = "demo-2019-10-05-01:
-tag_gnunet = tag
-tag_libmicrohttpd = tag
-tag_exchange = tag
-tag_merchant = tag
-tag_bank = tag
-tag_twister = tag
-tag_landing = tag
-tag_donations = tag
-tag_blog = tag
-tag_survey = tag
-tag_backoffice = tag
-tag_sync = tag
-@end example
+@menu
+* Cheat sheet:: 
+* Tagging components:: 
 
-Currently only the variables @code{env} and @code{tag_$@{component@}} are used.
+@end menu
 
-When deploying to @code{demo}, the @code{envcfg.py} should be committed to @code{deployment.git/envcfg/envcfg-demo-YYYY-MM-DD-SS.py}.
+@node Cheat sheet,Tagging components,,Demo Upgrade Procedure
+@anchor{taler-developer-manual cheat-sheet}@anchor{1d}
+@section Cheat sheet
 
-@node Bootstrapping an Environment,Upgrading an Existing Environment,Using envcfg py,Demo Upgrade Procedure
-@anchor{taler-developer-manual bootstrapping-an-environment}@anchor{19}
-@section Bootstrapping an Environment
 
+All commands run from deployment.git/docker/demo.
 
 @example
-$ git clone https://git.taler.net/deployment.git ~/deployment
-$ cp ~/deployment/envcfg/$ENVCFGFILE ~/envcfg.py
-$ ./deployment/bin/taler-deployment bootstrap
-$ source ~/activate
-$ taler-deployment build
-$ taler-deployment-prepare
-$ taler-deployment-start
-$ taler-deployment-arm -I # check everything works
-# The following command sets up the 'blog' and 'donations' instances.
-$ taler-config-instances
-@end example
+# Start services.
+$ docker-compose start --remove-orphans -d
 
-@node Upgrading an Existing Environment,Switching Demo Colors,Bootstrapping an Environment,Demo Upgrade Procedure
-@anchor{taler-developer-manual upgrading-an-existing-environment}@anchor{1a}
-@section Upgrading an Existing Environment
+# Stop services.
+$ docker-compose stop
 
+# Build base image (without tags-file builds master)
+$ ./build_base.sh images/base/Dockerfile [tags-file]
 
-@example
-$ rm -rf ~/sources ~/local
-$ git -C ~/deployment pull
-$ cp ~/deployment/envcfg/$ENVCFGFILE ~/envcfg.py
-$ taler-deployment bootstrap
-$ taler-deployment build
-$ taler-deployment-prepare
-$ taler-deployment-restart
-$ taler-deployment-arm -I # check everything works
+# Build all the services based on the latest base image
+$ docker-compose build
+
+# View live logs of the daemonized services.
+$ docker-compose logs
 @end example
 
-@node Switching Demo Colors,,Upgrading an Existing Environment,Demo Upgrade Procedure
-@anchor{taler-developer-manual switching-demo-colors}@anchor{1b}
-@section Switching Demo Colors
+@node Tagging components,,Cheat sheet,Demo Upgrade Procedure
+@anchor{taler-developer-manual tagging-components}@anchor{1e}
+@section Tagging components
 
 
-As the @code{demo} user, to switch to color @code{$@{COLOR@}},
-run the following script from @code{deployment/bin}:
+All Taler components must be tagged with git before they are deployed on the
+@code{demo} environment, using a tag of the following form:
 
 @example
-$ taler-deployment switch-demo
+demo-YYYY-MM-DD-SS
+YYYY = year
+MM = month
+DD = day
+SS = serial
 @end example
 
 @node Environments and Builders on taler net,Releases,Demo Upgrade Procedure,Top
-@anchor{taler-developer-manual environments-and-builders-on-taler-net}@anchor{1c}
+@anchor{taler-developer-manual environments-and-builders-on-taler-net}@anchor{1f}
 @chapter Environments and Builders on taler.net
 
 
 @menu
 * Buildbot implementation:: 
+* Test builder:: 
+* Wallet builder:: 
 * Documentation Builder:: 
 * Website Builder:: 
 * Code coverage:: 
-* Service Checker:: 
-* Tipping reserve top-up:: 
 * Producing auditor reports:: 
 * Database schema versioning:: 
 
 @end menu
 
-@node Buildbot implementation,Documentation Builder,,Environments and Builders on taler net
-@anchor{taler-developer-manual buildbot-implementation}@anchor{1d}
+@node Buildbot implementation,Test builder,,Environments and Builders on taler net
+@anchor{taler-developer-manual buildbot-implementation}@anchor{20}
 @section Buildbot implementation
 
 
@@ -1034,7 +1391,7 @@ The WORKER is the config that that lives on a shell account on a localhost (tale
 The WORKER running buildbot-worker receives these commands by authenticating and communicating with the buildbot server using parameters that were specified when the worker was created in that shell account with the @code{buildbot-worker} command.
 
 @item 
-The buildbot server's master.cfg file contains FACTORY declarations which specify the commands that the WORKER will run on localhost.
+The buildbot server’s master.cfg file contains FACTORY declarations which specify the commands that the WORKER will run on localhost.
 
 @item 
 The FACTORY is tied to the WORKER in master.cfg by a BUILDER.
@@ -1052,7 +1409,7 @@ Best Practices:
 @itemize -
 
 @item 
-When creating a new WORKER in the @code{master.cfg} file, leave a comment specifying the server and user account that this WORKER is called from.  (At this time, taler.net is the only server used by this implementation, but it's still good practice.)
+When creating a new WORKER in the @code{master.cfg} file, leave a comment specifying the server and user account that this WORKER is called from.  (At this time, taler.net is the only server used by this implementation, but it’s still good practice.)
 
 @item 
 Create a worker from a shell account with this command: @code{buildbot-worker create-worker <workername> localhost <username> <password>}
@@ -1060,8 +1417,52 @@ Create a worker from a shell account with this command: @code{buildbot-worker cr
 
 Then make sure there is a WORKER defined in master.cfg like: @code{worker.Worker("<username>", "<password>")}
 
-@node Documentation Builder,Website Builder,Buildbot implementation,Environments and Builders on taler net
-@anchor{taler-developer-manual documentation-builder}@anchor{1e}
+@node Test builder,Wallet builder,Buildbot implementation,Environments and Builders on taler net
+@anchor{taler-developer-manual test-builder}@anchor{21}
+@section Test builder
+
+
+This builder (@code{test-builder}) compiles and starts every Taler component.
+The associated worker is run by the @code{taler-test} Gv user, via the SystemD
+unit @code{buildbot-worker-taler}.  The following commands start/stop/restart
+the worker:
+
+@example
+systemctl --user start buildbot-worker-taler
+systemctl --user stop buildbot-worker-taler
+systemctl --user restart buildbot-worker-taler
+@end example
+
+@cartouche
+@quotation Note 
+the mentioned unit file can be found at @code{deployment.git/systemd-services/}
+@end quotation
+@end cartouche
+
+@node Wallet builder,Documentation Builder,Test builder,Environments and Builders on taler net
+@anchor{taler-developer-manual wallet-builder}@anchor{22}
+@section Wallet builder
+
+
+This builder (@code{wallet-builder}) compiles every Taler component
+and runs the wallet integration tests.  The associated worker is
+run by the @code{walletbuilder} Gv user, via the SystemD unit @code{buildbot-worker-wallet}.
+The following commands start/stop/restart the worker:
+
+@example
+systemctl --user start buildbot-worker-wallet
+systemctl --user stop buildbot-worker-wallet
+systemctl --user restart buildbot-worker-wallet
+@end example
+
+@cartouche
+@quotation Note 
+the mentioned unit file can be found at @code{deployment.git/systemd-services/}
+@end quotation
+@end cartouche
+
+@node Documentation Builder,Website Builder,Wallet builder,Environments and Builders on taler net
+@anchor{taler-developer-manual documentation-builder}@anchor{23}
 @section Documentation Builder
 
 
@@ -1083,7 +1484,7 @@ $ buildbot-worker start worker/
 @end example
 
 @node Website Builder,Code coverage,Documentation Builder,Environments and Builders on taler net
-@anchor{taler-developer-manual website-builder}@anchor{1f}
+@anchor{taler-developer-manual website-builder}@anchor{24}
 @section Website Builder
 
 
@@ -1104,8 +1505,8 @@ $ ./deployment/bootstrap-sitesbuilder
 $ buildbot-worker start worker/
 @end example
 
-@node Code coverage,Service Checker,Website Builder,Environments and Builders on taler net
-@anchor{taler-developer-manual code-coverage}@anchor{20}
+@node Code coverage,Producing auditor reports,Website Builder,Environments and Builders on taler net
+@anchor{taler-developer-manual code-coverage}@anchor{25}
 @section Code coverage
 
 
@@ -1127,55 +1528,12 @@ $ buildbot-worker start worker/
 
 The results are then published at @code{https://lcov.taler.net/}.
 
-@node Service Checker,Tipping reserve top-up,Code coverage,Environments and Builders on taler net
-@anchor{taler-developer-manual service-checker}@anchor{21}
-@section Service Checker
-
-
-The user @code{demo-checker} runs periodic checks to see if all the
-@code{*.demo.taler.net} services are up and running.  It is driven by
-Buildbot, and can be bootstrapped as follows.
-
-@example
-# Log-in as the 'demo-checker' user
-
-$ cd $HOME
-$ git clone git://git.taler.net/deployment
-$ ./deployment/bootstrap-demochecker
-
-# If the previous step worked, the setup is
-# complete and the Buildbot worker can be started.
-
-$ buildbot-worker start worker/
-@end example
-
-@node Tipping reserve top-up,Producing auditor reports,Service Checker,Environments and Builders on taler net
-@anchor{taler-developer-manual tipping-reserve-top-up}@anchor{22}
-@section Tipping reserve top-up
-
-
-Both 'test' and 'demo' setups get their tip reserve topped up
-by a Buildbot worker.  The following steps get the reserve topper
-prepared.
-
-@example
-# Log-in as <env>-topper, with <env> being either 'test' or 'demo'
-
-$ git clone git://git.taler.net/deployment
-$ ./deployment/prepare-reservetopper <env>
-
-# If the previous steps worked, then it should suffice to start
-# the worker, with:
-
-$ buildbot-worker start worker/
-@end example
-
-@node Producing auditor reports,Database schema versioning,Tipping reserve top-up,Environments and Builders on taler net
-@anchor{taler-developer-manual producing-auditor-reports}@anchor{23}
+@node Producing auditor reports,Database schema versioning,Code coverage,Environments and Builders on taler net
+@anchor{taler-developer-manual producing-auditor-reports}@anchor{26}
 @section Producing auditor reports
 
 
-Both 'test' and 'demo' setups get their auditor reports compiled
+Both ‘test’ and ‘demo’ setups get their auditor reports compiled
 by a Buildbot worker.  The following steps get the reports compiler
 prepared.
 
@@ -1183,7 +1541,7 @@ prepared.
 # Log-in as <env>-auditor, with <env> being either 'test' or 'demo'
 
 $ git clone git://git.taler.net/deployment
-$ ./deployment/prepare-auditorreporter <env>
+$ ./deployment/buildbot/bootstrap-scripts/prepare-auditorreporter <env>
 
 # If the previous steps worked, then it should suffice to start
 # the worker, with:
@@ -1192,12 +1550,12 @@ $ buildbot-worker start worker/
 @end example
 
 @node Database schema versioning,,Producing auditor reports,Environments and Builders on taler net
-@anchor{taler-developer-manual database-schema-versioning}@anchor{24}
+@anchor{taler-developer-manual database-schema-versioning}@anchor{27}
 @section Database schema versioning
 
 
 The PostgreSQL databases of the exchange and the auditor are versioned.
-See the 0000.sql file in the respective directory for documentation.
+See the @code{versioning.sql} file in the respective directory for documentation.
 
 Every set of changes to the database schema must be stored in a new
 versioned SQL script. The scripts must have contiguous numbers. After
@@ -1205,10 +1563,10 @@ any release (or version being deployed to a production or staging
 environment), existing scripts MUST be immutable.
 
 Developers and operators MUST NOT make changes to database schema
-outside of this versioning.
+outside of this versioning.  All tables of a GNU Taler component should live in their own schema.
 
 @node Releases,Continuous integration,Environments and Builders on taler net,Top
-@anchor{taler-developer-manual releases}@anchor{25}
+@anchor{taler-developer-manual releases}@anchor{28}
 @chapter Releases
 
 
@@ -1224,7 +1582,7 @@ outside of this versioning.
 @end menu
 
 @node Release Process and Checklists,Tagging,,Releases
-@anchor{taler-developer-manual release-process-and-checklists}@anchor{26}
+@anchor{taler-developer-manual release-process-and-checklists}@anchor{29}
 @section Release Process and Checklists
 
 
@@ -1258,11 +1616,11 @@ taler-wallet-webex (wallet-webex.git)
 @end itemize
 
 @node Tagging,Database for tests,Release Process and Checklists,Releases
-@anchor{taler-developer-manual tagging}@anchor{27}
+@anchor{taler-developer-manual tagging}@anchor{2a}
 @section Tagging
 
 
-Tag releases with an @strong{annotated} commit, like
+Tag releases with an `annotated' commit, like
 
 @example
 $ git tag -a v0.1.0 -m "Official release v0.1.0"
@@ -1270,25 +1628,24 @@ $ git push origin v0.1.0
 @end example
 
 @node Database for tests,Exchange merchant,Tagging,Releases
-@anchor{taler-developer-manual database-for-tests}@anchor{28}
+@anchor{taler-developer-manual database-for-tests}@anchor{2b}
 @section Database for tests
 
 
 For tests in the exchange and merchant to run, make sure that a database
-@emph{talercheck} is accessible by @emph{$USER}. Otherwise tests involving the
+`talercheck' is accessible by `$USER'. Otherwise tests involving the
 database logic are skipped.
 
 @cartouche
 @quotation Note 
-The Taler merchant backend stores private keys and other sensitive
-business and customer data in the database.  The backend operator
-SHOULD ensure that backup operations are encrypted and secured from
-unauthorized access.
+Taler may store sensitive business and customer data in the database.  Any
+operator SHOULD thus ensure that backup operations are encrypted and
+secured from unauthorized access.
 @end quotation
 @end cartouche
 
 @node Exchange merchant,Wallet WebExtension,Database for tests,Releases
-@anchor{taler-developer-manual exchange-merchant}@anchor{29}
+@anchor{taler-developer-manual exchange-merchant}@anchor{2c}
 @section Exchange, merchant
 
 
@@ -1335,7 +1692,7 @@ For bootstrap, you will need to install
 GNU Recutils@footnote{https://www.gnu.org/software/recutils/}.
 
 For the exchange test cases to pass, @code{make install} must be run first.
-Without it, test cases will fail because plugins can't be located.
+Without it, test cases will fail because plugins can’t be located.
 
 @example
 $ ./bootstrap
@@ -1347,12 +1704,12 @@ $ make install check
 @end example
 
 @node Wallet WebExtension,Upload to GNU mirrors,Exchange merchant,Releases
-@anchor{taler-developer-manual wallet-webextension}@anchor{2a}
+@anchor{taler-developer-manual wallet-webextension}@anchor{2d}
 @section Wallet WebExtension
 
 
-The version of the wallet is in @emph{manifest.json}. The @code{version_name}
-should be adjusted, and @emph{version} should be increased independently on
+The version of the wallet is in `manifest.json'. The @code{version_name}
+should be adjusted, and `version' should be increased independently on
 every upload to the WebStore.
 
 @example
@@ -1361,7 +1718,7 @@ $ make dist
 @end example
 
 @node Upload to GNU mirrors,Creating Debian packages,Wallet WebExtension,Releases
-@anchor{taler-developer-manual upload-to-gnu-mirrors}@anchor{2b}
+@anchor{taler-developer-manual upload-to-gnu-mirrors}@anchor{2e}
 @section Upload to GNU mirrors
 
 
@@ -1375,10 +1732,10 @@ directory: taler
 filename: taler-exchange-0.1.0.tar.gz
 @end example
 
-Upload the files in @strong{binary mode} to the ftp servers.
+Upload the files in `binary mode' to the ftp servers.
 
 @node Creating Debian packages,,Upload to GNU mirrors,Releases
-@anchor{taler-developer-manual creating-debian-packages}@anchor{2c}
+@anchor{taler-developer-manual creating-debian-packages}@anchor{2f}
 @section Creating Debian packages
 
 
@@ -1395,6 +1752,8 @@ $ dpkg-buildpackage -rfakeroot -b -uc -us
 in the respective source directory (GNUnet, exchange, merchant) to create the
 @code{.deb} files. Note that they will be created in the parent directory.  This
 can be done on gv.taler.net, or on another (secure) machine.
+Actual release builds should be done via the Docker images
+that can be found in @code{deployment.git} under packaging.
 
 On @code{gv}, we use the @code{aptbuilder} user to manage the reprepro repository.
 
@@ -1415,7 +1774,7 @@ Finally, make sure to clean up @code{~/incoming/} (by deleting the
 now imported @code{*.deb} files).
 
 @node Continuous integration,Internationalization,Releases,Top
-@anchor{taler-developer-manual continuous-integration}@anchor{2d}
+@anchor{taler-developer-manual continuous-integration}@anchor{30}
 @chapter Continuous integration
 
 
@@ -1423,21 +1782,21 @@ CI is done with Buildbot (@indicateurl{https://buildbot.net/}), and builds are
 triggered by the means of Git hooks. The results are published at
 @indicateurl{https://buildbot.taler.net/} .
 
-In order to avoid downtimes, CI uses a "blue/green" deployment
+In order to avoid downtimes, CI uses a “blue/green” deployment
 technique. In detail, there are two users building code on the system,
-the "green" and the "blue" user; and at any given time, one is running
+the “green” and the “blue” user; and at any given time, one is running
 Taler services and the other one is either building the code or waiting
 for that.
 
 There is also the possibility to trigger builds manually, but this is
-only reserved to "admin" users.
+only reserved to “admin” users.
 
-@node Internationalization,Android Apps,Continuous integration,Top
-@anchor{taler-developer-manual internationalization}@anchor{2e}
+@node Internationalization,iOS Apps,Continuous integration,Top
+@anchor{taler-developer-manual internationalization}@anchor{31}
 @chapter Internationalization
 
 
-Internationalization (a.k.a "Translation") is handled with Weblate (@indicateurl{https://weblate.org}) via our instance at @indicateurl{https://weblate.taler.net/} .
+Internationalization (a.k.a “Translation”) is handled with Weblate (@indicateurl{https://weblate.org}) via our instance at @indicateurl{https://weblate.taler.net/} .
 
 At this time, this system is still very new for Taler.net and this documentation may be incorrect and is certainly incomplete.
 
@@ -1454,14 +1813,14 @@ At this time, this system is still very new for Taler.net and this documentation
 @end menu
 
 @node Who can Register,About Privilege Levels,,Internationalization
-@anchor{taler-developer-manual who-can-register}@anchor{2f}
+@anchor{taler-developer-manual who-can-register}@anchor{32}
 @section Who can Register
 
 
-At this time, anyone can register an account at @indicateurl{https://weblate.taler.net/} to create translations.  Registered users default to the @strong{Users} and @strong{Viewers} privilege level.
+At this time, anyone can register an account at @indicateurl{https://weblate.taler.net/} to create translations.  Registered users default to the `Users' and `Viewers' privilege level.
 
 @node About Privilege Levels,Upgrading Privileges,Who can Register,Internationalization
-@anchor{taler-developer-manual about-privilege-levels}@anchor{30}
+@anchor{taler-developer-manual about-privilege-levels}@anchor{33}
 @section About Privilege Levels
 
 
@@ -1471,113 +1830,169 @@ This is the breakdown of privilege levels in Weblate:
 @itemize *
 
 @item 
-@strong{Users}/@strong{Viewers} = Can log in, view Translations  (@emph{applies to new users})
+`Users'/`Viewers' = Can log in, view Translations  (`applies to new users')
 
 @item 
-@strong{Reviewers} = Can contribute Translations to existing @emph{Components}
+`Reviewers' = Can contribute Translations to existing `Components'
 
 @item 
-@strong{Managers} = Can create new @emph{Components} of existing @emph{Projects}
+`Managers' = Can create new `Components' of existing `Projects'
 
 @item 
-@strong{Superusers} = Can create new @emph{Projects}
+`Superusers' = Can create new `Projects'
 @end itemize
 
 @node Upgrading Privileges,How to Create a Project,About Privilege Levels,Internationalization
-@anchor{taler-developer-manual upgrading-privileges}@anchor{31}
+@anchor{taler-developer-manual upgrading-privileges}@anchor{34}
 @section Upgrading Privileges
 
 
-To upgrade from @strong{Users}/@strong{Viewers}, a superuser must manually augment your privileges.  At this time, superusers are Christian, Florian, and Buck.
+To upgrade from `Users'/`Viewers', a superuser must manually augment your privileges.  At this time, superusers are Christian, Florian, and Buck.
 
 @node How to Create a Project,How to Create a Component,Upgrading Privileges,Internationalization
-@anchor{taler-developer-manual how-to-create-a-project}@anchor{32}
+@anchor{taler-developer-manual how-to-create-a-project}@anchor{35}
 @section How to Create a Project
 
 
-The @emph{GNU Taler} project is probably the correct project for most Components and Translations falling under this guide.  Please contact a superuser if you need another Project created.
+The `GNU Taler' project is probably the correct project for most Components and Translations falling under this guide.  Please contact a superuser if you need another Project created.
 
 @node How to Create a Component,How to Create a Translation,How to Create a Project,Internationalization
-@anchor{taler-developer-manual how-to-create-a-component}@anchor{33}
+@anchor{taler-developer-manual how-to-create-a-component}@anchor{36}
 @section How to Create a Component
 
 
 Reference: @indicateurl{https://docs.weblate.org/en/weblate-4.0.3/admin/projects.html#component-configuration}
 
-In Weblate, a @emph{Component} is a subset of a @emph{Project} and each Component contains N translations.  A Component is generally associated with a Git repo.
+In Weblate, a `Component' is a subset of a `Project' and each Component contains N translations.  A Component is generally associated with a Git repo.
 
-To create a Component, log into @indicateurl{https://weblate.taler.net/} with your @emph{Manager} or higher credentials and choose @strong{+ Add} from the upper-right corner.
+To create a Component, log into @indicateurl{https://weblate.taler.net/} with your `Manager' or higher credentials and choose `+ Add' from the upper-right corner.
 
 What follows is a sort of Wizard.  You can find detailed docs at @indicateurl{https://docs.weblate.org/}.  Here are some important notes about connecting your Component to the Taler Git repository:
 
-Under @emph{https://weblate.taler.net/create/component/vcs/}:
+Under `https://weblate.taler.net/create/component/vcs/':
 
 
 @itemize *
 
 @item 
-@strong{Source code repository} - Generally @code{git+ssh://git@@git.taler.net/<reponame>`}.  Check with @code{git remote -v}.
+`Source code repository' - Generally @code{git+ssh://git@@git.taler.net/<reponame>`}.  Check with @code{git remote -v}.
 
 @item 
-@strong{Repository branch} - Choose the correct branch to draw from and commit to.
+`Repository branch' - Choose the correct branch to draw from and commit to.
 
 @item 
-@strong{Repository push URL} - This is generally @code{git+ssh://git@@git.taler.net/<reponame>`}  Check with @code{git remote -v}.
+`Repository push URL' - This is generally @code{git+ssh://git@@git.taler.net/<reponame>`}  Check with @code{git remote -v}.
 
 @item 
-@strong{Repository browser} - This is the www URL of the Git repo's file browser.  Example @code{https://git.taler.net/<repositoryname>.git/tree/@{@{filename@}@}?h=@{@{branch@}@}#n@{@{line@}@}} where @code{<repositoryname>} gets replaced but @code{@{@{filename@}@}} and other items in braces are actual variables in the string.
+`Repository browser' - This is the www URL of the Git repo’s file browser.  Example @code{https://git.taler.net/<repositoryname>.git/tree/@{@{filename@}@}?h=@{@{branch@}@}#n@{@{line@}@}} where @code{<repositoryname>} gets replaced but @code{@{@{filename@}@}} and other items in braces are actual variables in the string.
 
 @item 
-@strong{Merge style} - @emph{Rebase}, in line with GNU Taler development procedures
+`Merge style' - `Rebase', in line with GNU Taler development procedures
 
 @item 
-@strong{Translation license} - @emph{GNU Affero General Public License v3.0 or Later}
+`Translation license' - `GNU Affero General Public License v3.0 or Later'
 
 @item 
-@strong{Adding new translation} - Decide how to handle adding new translations
+`Adding new translation' - Decide how to handle adding new translations
 @end itemize
 
 @node How to Create a Translation,Translation Standards and Practices,How to Create a Component,Internationalization
-@anchor{taler-developer-manual how-to-create-a-translation}@anchor{34}
+@anchor{taler-developer-manual how-to-create-a-translation}@anchor{37}
 @section How to Create a Translation
 
 
 1 - Log into @indicateurl{https://weblate.taler.net}
 
-2 - Navigate to @emph{Projects} > @emph{Browse all projects}
+2 - Navigate to `Projects' > `Browse all projects'
 
-3 - Choose the @emph{Project} you wish to contribute to.
+3 - Choose the `Project' you wish to contribute to.
 
-4 - Choose the @emph{Component} you wish to contribute to.
+4 - Choose the `Component' you wish to contribute to.
 
-5 - Find the language you want to translate into.  Click "Translate" on that line.
+5 - Find the language you want to translate into.  Click “Translate” on that line.
 
 6 - Find a phrase and translate it.
 
 You may also wish to refer to @indicateurl{https://docs.weblate.org/} .
 
 @node Translation Standards and Practices,GPG Signing of Translations,How to Create a Translation,Internationalization
-@anchor{taler-developer-manual translation-standards-and-practices}@anchor{35}
+@anchor{taler-developer-manual translation-standards-and-practices}@anchor{38}
 @section Translation Standards and Practices
 
 
-By default, our Weblate instance is set to accept translations in English, French, German, Italian, Russian, Spanish, and Portuguese.  If you want to contribute a translation in a different language, navigate to the @emph{Component} you want to translate for, and click "Start new translation" to begin.  If you require a privilege upgrade, please contact a superuser with your request.
+By default, our Weblate instance is set to accept translations in English, French, German, Italian, Russian, Spanish, and Portuguese.  If you want to contribute a translation in a different language, navigate to the `Component' you want to translate for, and click “Start new translation” to begin.  If you require a privilege upgrade, please contact a superuser with your request.
 
 When asked, set the license to GPLv3 or later.
 
 Set commit/push to manual only.
 
 @node GPG Signing of Translations,,Translation Standards and Practices,Internationalization
-@anchor{taler-developer-manual gpg-signing-of-translations}@anchor{36}
+@anchor{taler-developer-manual gpg-signing-of-translations}@anchor{39}
 @section GPG Signing of Translations
 
 
 weblate.taler.net signs GPG commits with the GPG key CD33CE35801462FA5EB0B695F2664BF474BFE502, and the corresponding public key can be found at @indicateurl{https://weblate.taler.net/keys/}.
 
-This means that contributions made through weblate will not be signed with the individual contributor's key when they are checked into the Git repository, but with the weblate key.
+This means that contributions made through weblate will not be signed with the individual contributor’s key when they are checked into the Git repository, but with the weblate key.
+
+@node iOS Apps,Android Apps,Internationalization,Top
+@anchor{taler-developer-manual ios-apps}@anchor{3a}
+@chapter iOS Apps
+
+
+@menu
+* Building Taler Wallet for iOS from source:: 
+
+@end menu
 
-@node Android Apps,Code Coverage,Internationalization,Top
-@anchor{taler-developer-manual android-apps}@anchor{37}
+@node Building Taler Wallet for iOS from source,,,iOS Apps
+@anchor{taler-developer-manual build-ios-from-source}@anchor{3b}@anchor{taler-developer-manual building-taler-wallet-for-ios-from-source}@anchor{3c}
+@section Building Taler Wallet for iOS from source
+
+
+Currently the iOS Wallet app is in
+the official Git repository@footnote{https://git.taler.net/taler-ios.git}:
+
+@menu
+* Compatibility:: 
+* Building:: 
+
+@end menu
+
+@node Compatibility,Building,,Building Taler Wallet for iOS from source
+@anchor{taler-developer-manual compatibility}@anchor{3d}
+@subsection Compatibility
+
+
+The minimum version of iOS supported is 15.0.
+This app runs on all iPhone models at least as new as the iPhone 6S.
+
+@node Building,,Compatibility,Building Taler Wallet for iOS from source
+@anchor{taler-developer-manual building}@anchor{3e}
+@subsection Building
+
+
+Before building the iOS wallet, you must first checkout the
+quickjs-tart repo@footnote{https://git.taler.net/quickjs-tart.git}
+and the
+wallet-core repo@footnote{https://git.taler.net/wallet-core.git}.
+
+Build wallet-core first, then copy/move its product “taler-wallet-core-qjs.mjs”
+into your quickjs-tart folder right at the top level.
+
+Open Taler.xcworkspace, and set scheme / target to Taler_Wallet. Build&run…
+
+Don’t open QuickJS-rt.xcodeproj or TalerWallet.xcodeproj and build anything
+there - all needed libraries and frameworks will be built automatically from
+Taler.xcworkspace.
+
+Have all 3 local repos (wallet-core, quickjs-tart, and this one) adjacent at
+the same level (e.g. in a “GNU Taler” folder).
+Taler.xcworkspace expects the QuickJS framework sub-project to be at
+@code{../quickjs-tart/QuickJS-rt.xcodeproj}.
+
+@node Android Apps,Code Coverage,iOS Apps,Top
+@anchor{taler-developer-manual android-apps}@anchor{3f}
 @chapter Android Apps
 
 
@@ -1590,7 +2005,7 @@ This means that contributions made through weblate will not be signed with the i
 @end menu
 
 @node Android App Nightly Builds,Building apps from source,,Android Apps
-@anchor{taler-developer-manual android-app-nightly-builds}@anchor{38}
+@anchor{taler-developer-manual android-app-nightly-builds}@anchor{40}
 @section Android App Nightly Builds
 
 
@@ -1615,7 +2030,7 @@ Cashier
 
 Their git repositories are mirrored at Gitlab@footnote{https://gitlab.com/gnu-taler/taler-android}
 to utilize their CI
-and F-Droid@footnote{https://f-droid.org}'s Gitlab integration
+and F-Droid@footnote{https://f-droid.org}’s Gitlab integration
 to publish automatic nightly builds@footnote{https://f-droid.org/docs/Publishing_Nightly_Builds/}
 for each change on the @code{master} branch.
 
@@ -1635,13 +2050,13 @@ GNU Taler Nightly F-Droid Repository@footnote{fdroidrepos://gnu-taler.gitlab.io/
 @cartouche
 @quotation Note 
 Nightly apps can be installed alongside official releases
-and thus are meant @strong{only for testing purposes}.
+and thus are meant `only for testing purposes'.
 Use at your own risk!
 @end quotation
 @end cartouche
 
 @node Building apps from source,Update translations,Android App Nightly Builds,Android Apps
-@anchor{taler-developer-manual build-apps-from-source}@anchor{39}@anchor{taler-developer-manual building-apps-from-source}@anchor{3a}
+@anchor{taler-developer-manual build-apps-from-source}@anchor{41}@anchor{taler-developer-manual building-apps-from-source}@anchor{42}
 @section Building apps from source
 
 
@@ -1665,7 +2080,7 @@ git
 unzip
 @end itemize
 
-Then you can get the app's source code using git:
+Then you can get the app’s source code using git:
 
 @example
 # Start by cloning the Android git repository
@@ -1682,12 +2097,12 @@ The last command will return something like @code{compileSdkVersion 29}.
 So visit the Android Rebuilds@footnote{http://android-rebuilds.beuc.net/} project
 and look for that version of the Android SDK there.
 If the SDK version is not yet available as a free rebuild,
-you can try to lower the @code{compileSdkVersion} in the app's @code{merchant-terminal/build.gradle} file.
+you can try to lower the @code{compileSdkVersion} in the app’s @code{merchant-terminal/build.gradle} file.
 Note that this might break things
 or require you to also lower other versions such as @code{targetSdkVersion}.
 
 In our example, the version is @code{29} which is available,
-so download the "SDK Platform" package of "Android 10.0.0 (API 29)"
+so download the “SDK Platform” package of “Android 10.0.0 (API 29)”
 and unpack it:
 
 @example
@@ -1720,18 +2135,18 @@ build-tools;29.0.3 Android SDK Build-Tools 29.0.3
 @end table
 @end quotation
 
-you can try changing the @code{buildToolsVersion} in the app's @code{merchant-terminal/build.gradle} file
-to the latest "Android SDK build tools" version supported by the Android Rebuilds project.
+you can try changing the @code{buildToolsVersion} in the app’s @code{merchant-terminal/build.gradle} file
+to the latest “Android SDK build tools” version supported by the Android Rebuilds project.
 
 After the build finished successfully,
 you will find your APK in @code{merchant-terminal/build/outputs/apk/release/}.
 
 @node Update translations,Release process,Building apps from source,Android Apps
-@anchor{taler-developer-manual update-translations}@anchor{3b}
+@anchor{taler-developer-manual update-translations}@anchor{43}
 @section Update translations
 
 
-Translations are managed with Taler's weblate instance:
+Translations are managed with Taler’s weblate instance:
 @indicateurl{https://weblate.taler.net/projects/gnu-taler/}
 
 To update translations, enter the taler-android git repository
@@ -1761,7 +2176,7 @@ Afterwards, build the entire project from source and test the UI
 to ensure that no erroneous translations (missing placeholders) are breaking things.
 
 @node Release process,,Update translations,Android Apps
-@anchor{taler-developer-manual release-process}@anchor{3c}
+@anchor{taler-developer-manual release-process}@anchor{44}
 @section Release process
 
 
@@ -1792,12 +2207,12 @@ $ git tag -s $APP-$VERSION
 @end menu
 
 @node F-Droid,Google Play,,Release process
-@anchor{taler-developer-manual id1}@anchor{3d}
+@anchor{taler-developer-manual id1}@anchor{45}
 @subsection F-Droid
 
 
 Nightly builds get published automatically (see above) after pushing code to the official repo.
-Actual releases get picked up by F-Droid's official repository via git tags.
+Actual releases get picked up by F-Droid’s official repository via git tags.
 So ensure that all releases get tagged properly.
 
 Some information for F-Droid official repository debugging:
@@ -1816,7 +2231,7 @@ PoS: [metadata@footnote{https://gitlab.com/fdroid/fdroiddata/-/blob/master/metad
 @end itemize
 
 @node Google Play,,F-Droid,Release process
-@anchor{taler-developer-manual google-play}@anchor{3e}
+@anchor{taler-developer-manual google-play}@anchor{46}
 @subsection Google Play
 
 
@@ -1838,7 +2253,7 @@ All uploads are going to the beta track by default.
 These can be promoted to production later or immediately after upload if you feel daring.
 
 @node Code Coverage,Coding Conventions,Android Apps,Top
-@anchor{taler-developer-manual id2}@anchor{3f}@anchor{taler-developer-manual id3}@anchor{40}
+@anchor{taler-developer-manual id2}@anchor{47}@anchor{taler-developer-manual id3}@anchor{48}
 @chapter Code Coverage
 
 
@@ -1848,22 +2263,24 @@ nightly (once a day) by a Buildbot worker. The coverage results are
 then published at @indicateurl{https://lcov.taler.net/} .
 
 @node Coding Conventions,Testing library,Code Coverage,Top
-@anchor{taler-developer-manual coding-conventions}@anchor{41}
+@anchor{taler-developer-manual coding-conventions}@anchor{49}
 @chapter Coding Conventions
 
 
-GNU Taler is developed primarily in C, Kotlin, Python and TypeScript.
+GNU Taler is developed primarily in C, Kotlin, Python, Swift and TypeScript.
 
 @menu
 * Components written in C:: 
 * Shell Scripts:: 
 * Kotlin:: 
 * Python:: 
+* Swift:: 
+* TypeScript:: 
 
 @end menu
 
 @node Components written in C,Shell Scripts,,Coding Conventions
-@anchor{taler-developer-manual components-written-in-c}@anchor{42}
+@anchor{taler-developer-manual components-written-in-c}@anchor{4a}
 @section Components written in C
 
 
@@ -1883,7 +2300,7 @@ by the GNUnet style: @indicateurl{https://docs.gnunet.org/handbook/gnunet.html#C
 @end menu
 
 @node Naming conventions,,,Components written in C
-@anchor{taler-developer-manual naming-conventions}@anchor{43}
+@anchor{taler-developer-manual naming-conventions}@anchor{4b}
 @subsection Naming conventions
 
 
@@ -1897,22 +2314,22 @@ include files (very similar to GNUnet):
 @itemize *
 
 @item 
-if installed, must start with "@code{taler_}" (exception: platform.h),
+if installed, must start with “@code{taler_}” (exception: platform.h),
 and MUST live in src/include/
 
 @item 
-if NOT installed, must NOT start with "@code{taler_}" and
+if NOT installed, must NOT start with “@code{taler_}” and
 MUST NOT live in src/include/ and
 SHOULD NOT be included from outside of their own directory
 
 @item 
-end in "_lib" for "simple" libraries
+end in “_lib” for “simple” libraries
 
 @item 
-end in "_plugin" for plugins
+end in “_plugin” for plugins
 
 @item 
-end in "_service" for libraries accessing a service, i.e. the exchange
+end in “_service” for libraries accessing a service, i.e. the exchange
 @end itemize
 
 @item 
@@ -1945,22 +2362,22 @@ logging
 
 @item 
 tools use their full name in GNUNET_log_setup
-(i.e. 'taler-exchange-offline') and log using plain 'GNUNET_log'.
+(i.e. ‘taler-exchange-offline’) and log using plain ‘GNUNET_log’.
 
 @item 
-pure libraries (without associated service) use 'GNUNET_log_from'
-with the component set to their library name (without lib or '.so'),
-which should also be their directory name (i.e. 'util')
+pure libraries (without associated service) use ‘GNUNET_log_from’
+with the component set to their library name (without lib or ‘.so’),
+which should also be their directory name (i.e. ‘util’)
 
 @item 
-plugin libraries (without associated service) use 'GNUNET_log_from'
-with the component set to their type and plugin name (without lib or '.so'),
-which should also be their directory name (i.e. 'exchangedb-postgres')
+plugin libraries (without associated service) use ‘GNUNET_log_from’
+with the component set to their type and plugin name (without lib or ‘.so’),
+which should also be their directory name (i.e. ‘exchangedb-postgres’)
 
 @item 
-libraries with associated service) use 'GNUNET_log_from'
+libraries with associated service) use ‘GNUNET_log_from’
 with the name of the service,  which should also be their
-directory name (i.e. 'exchange')
+directory name (i.e. ‘exchange’)
 
 @item 
 for tools with @code{-l LOGFILE}, its absence means write logs to stderr
@@ -2002,14 +2419,14 @@ structs:
 @itemize *
 
 @item 
-structs that are 'packed' and do not contain pointers and are
+structs that are ‘packed’ and do not contain pointers and are
 thus suitable for hashing or similar operations are distinguished
-by adding a "P" at the end of the name. (NEW)  Note that this
+by adding a “P” at the end of the name. (NEW)  Note that this
 convention does not hold for the GNUnet-structs (yet).
 
 @item 
 structs that are used with a purpose for signatures, additionally
-get an "S" at the end of the name.
+get an “S” at the end of the name.
 @end itemize
 
 @item 
@@ -2029,7 +2446,7 @@ testcases
 @itemize *
 
 @item 
-must be called "test_module-under-test_case-description.c"
+must be called “test_module-under-test_case-description.c”
 @end itemize
 
 @item 
@@ -2039,12 +2456,12 @@ performance tests
 @itemize *
 
 @item 
-must be called "perf_module-under-test_case-description.c"
+must be called “perf_module-under-test_case-description.c”
 @end itemize
 @end itemize
 
 @node Shell Scripts,Kotlin,Components written in C,Coding Conventions
-@anchor{taler-developer-manual shell-scripts}@anchor{44}
+@anchor{taler-developer-manual shell-scripts}@anchor{4c}
 @section Shell Scripts
 
 
@@ -2071,15 +2488,15 @@ $ set -eu
 @end example
 
 @node Kotlin,Python,Shell Scripts,Coding Conventions
-@anchor{taler-developer-manual kotlin}@anchor{45}
+@anchor{taler-developer-manual kotlin}@anchor{4d}
 @section Kotlin
 
 
 We so far have no specific guidelines, please follow best practices
 for the language.
 
-@node Python,,Kotlin,Coding Conventions
-@anchor{taler-developer-manual python}@anchor{46}
+@node Python,Swift,Kotlin,Coding Conventions
+@anchor{taler-developer-manual python}@anchor{4e}
 @section Python
 
 
@@ -2091,14 +2508,14 @@ for the language.
 @end menu
 
 @node Supported Python Versions,Style,,Python
-@anchor{taler-developer-manual supported-python-versions}@anchor{47}
+@anchor{taler-developer-manual supported-python-versions}@anchor{4f}
 @subsection Supported Python Versions
 
 
 Python code should be written and build against version 3.7 of Python.
 
 @node Style,Python for Scripting,Supported Python Versions,Python
-@anchor{taler-developer-manual style}@anchor{48}
+@anchor{taler-developer-manual style}@anchor{50}
 @subsection Style
 
 
@@ -2108,7 +2525,7 @@ A reusable yapf style file can be found in @code{build-common},
 which is intended to be used as a git submodule.
 
 @node Python for Scripting,,Style,Python
-@anchor{taler-developer-manual python-for-scripting}@anchor{49}
+@anchor{taler-developer-manual python-for-scripting}@anchor{51}
 @subsection Python for Scripting
 
 
@@ -2125,12 +2542,26 @@ are useful:
 @code{pathlib} for path manipulation (part of the standard library)
 
 @item 
-@code{subprocess} for "shelling out" to other programs.  Prefer @code{subprocess.run}
+@code{subprocess} for “shelling out” to other programs.  Prefer @code{subprocess.run}
 over the older APIs.
 @end itemize
 
+@node Swift,TypeScript,Python,Coding Conventions
+@anchor{taler-developer-manual swift}@anchor{52}
+@section Swift
+
+
+Please follow best practices for the language.
+
+@node TypeScript,,Swift,Coding Conventions
+@anchor{taler-developer-manual typescript}@anchor{53}
+@section TypeScript
+
+
+Please follow best practices for the language.
+
 @node Testing library,User-Facing Terminology,Coding Conventions,Top
-@anchor{taler-developer-manual testing-library}@anchor{4a}
+@anchor{taler-developer-manual testing-library}@anchor{54}
 @chapter Testing library
 
 
@@ -2156,11 +2587,11 @@ former contains the main logic to test feature @code{x}, whereas the latter
 cleans the memory up after execution.
 
 In a test life, each CMD needs some internal state, made by values it
-keeps in memory. Often, the test has to @emph{share} those values with other
+keeps in memory. Often, the test has to `share' those values with other
 CMDs: for example, CMD1 may create some key material and CMD2 needs this
 key material to encrypt data.
 
-The offering of internal values from CMD1 to CMD2 is made by @emph{traits}. A
+The offering of internal values from CMD1 to CMD2 is made by `traits'. A
 trait is a @code{struct TALER_TESTING_Trait}, and each CMD contains an array
 of traits, that it offers via the public trait interface to other
 commands. The definition and filling of such array happens transparently
@@ -2195,7 +2626,7 @@ of supposedly well-behaved components. This is needed when, for example,
 we want the exchange to return some corrupted signature in order to
 check if the merchant backend detects it.
 
-This alteration is accomplished by another service called @emph{twister}. The
+This alteration is accomplished by another service called `twister'. The
 twister acts as a proxy between service A and B, and can be programmed
 to tamper with the data exchanged by A and B.
 
@@ -2203,7 +2634,7 @@ Please refer to the Twister codebase (under the @code{test} directory) in
 order to see how to configure it.
 
 @node User-Facing Terminology,Developer Glossary,Testing library,Top
-@anchor{taler-developer-manual user-facing-terminology}@anchor{4b}
+@anchor{taler-developer-manual user-facing-terminology}@anchor{55}
 @chapter User-Facing Terminology
 
 
@@ -2217,7 +2648,7 @@ used in the user interface and help materials.
 @end menu
 
 @node Terms to Avoid,Terms to Use,,User-Facing Terminology
-@anchor{taler-developer-manual terms-to-avoid}@anchor{4c}
+@anchor{taler-developer-manual terms-to-avoid}@anchor{56}
 @section Terms to Avoid
 
 
@@ -2229,29 +2660,36 @@ used in the user interface and help materials.
 Refreshing is the internal technical terminology for the protocol to
 give change for partially spent coins
 
-@strong{Use instead}: "Obtaining change"
+`Use instead': “Obtaining change”
+
+@item Charge
+
+Charge has two opposite meanings (charge to a credit card vs. charge a battery).
+This can confuse users.
+
+`Use instead': “Obtain”, “Credit”, “Debit”, “Withdraw”, “Top up”
 
 @item Coin
 
 Coins are an internal construct, the user should never be aware that their balance
-is represented by coins if different denominations.
+is represented by coins of different denominations.
 
-@strong{Use instead}: "(Digital) Cash" or "(Wallet) Balance"
+`Use instead': “(Digital) Cash” or “(Wallet) Balance”
 
 @item Consumer
 
 Has bad connotation of consumption.
 
-@strong{Use instead}: Customer or user.
+`Use instead': Customer or user.
 
 @item Proposal
 
 The term used to describe the process of the merchant facilitating the download
 of the signed contract terms for an order.
 
-@strong{Avoid}.  Generally events that relate to proposal downloads
+`Avoid'.  Generally events that relate to proposal downloads
 should not be shown to normal users, only developers.  Instead, use
-"communication with mechant failed" if a proposed order can't be downloaded.
+“communication with mechant failed” if a proposed order can’t be downloaded.
 
 @item Anonymous E-Cash
 
@@ -2259,14 +2697,14 @@ Should be generally avoided, since Taler is only anonymous for
 the customer. Also some people are scared of anonymity (which as
 a term is also way too absolute, as anonymity is hardly ever perfect).
 
-@strong{Use instead}:  "Privacy-preserving", "Privacy-friendly"
+`Use instead':  “Privacy-preserving”, “Privacy-friendly”
 
 @item Payment Replay
 
 The process of proving to the merchant that the customer is entitled
 to view a digital product again, as they already paid for it.
 
-@strong{Use instead}:  In the event history, "re-activated digital content purchase"
+`Use instead':  In the event history, “re-activated digital content purchase”
 could be used. (FIXME: this is still not nice.)
 
 @item Session ID
@@ -2277,7 +2715,7 @@ See Payment Replay.
 
 Too ambiguous in the wallet.
 
-@strong{Use instead}: Purchase
+`Use instead': Purchase
 
 @item Fulfillment URL
 
@@ -2286,7 +2724,7 @@ with their payment.  Can also be something like a donation receipt.
 @end table
 
 @node Terms to Use,,Terms to Avoid,User-Facing Terminology
-@anchor{taler-developer-manual terms-to-use}@anchor{4d}
+@anchor{taler-developer-manual terms-to-use}@anchor{57}
 @section Terms to Use
 
 
@@ -2302,16 +2740,16 @@ Regulatory entity that certifies exchanges and oversees their operation.
 The entity/service that gives out digital cash in exchange for some
 other means of payment.
 
-In some contexts, using "Issuer" could also be appropriate.
+In some contexts, using “Issuer” could also be appropriate.
 When showing a balance breakdown,
-we can say "100 Eur (issued by exchange.euro.taler.net)".
-Sometimes we may also use the more generic term "Payment Service Provider"
-when the concept of an "Exchange" is still unclear to the reader.
+we can say “100 Eur (issued by exchange.euro.taler.net)”.
+Sometimes we may also use the more generic term “Payment Service Provider”
+when the concept of an “Exchange” is still unclear to the reader.
 
 @item Refund
 
-A refund is given by a merchant to the customer (rather the customer's wallet)
-and "undoes" a previous payment operation.
+A refund is given by a merchant to the customer (rather the customer’s wallet)
+and “undoes” a previous payment operation.
 
 @item Payment
 
@@ -2319,12 +2757,12 @@ The act of sending digital cash to a merchant to pay for an order.
 
 @item Purchase
 
-Used to refer to the "result" of a payment, as in "view purchase".
-Use sparsingly, as the word doesn't fit for all payments, such as donations.
+Used to refer to the “result” of a payment, as in “view purchase”.
+Use sparsingly, as the word doesn’t fit for all payments, such as donations.
 
 @item Contract Terms
 
-Partially machine-readable representation of the merchant's obligation after the
+Partially machine-readable representation of the merchant’s obligation after the
 customer makes a payment.
 
 @item Merchant
@@ -2333,12 +2771,12 @@ Party that receives a payment.
 
 @item Wallet
 
-Also "Taler Wallet".  Software component that manages the user's digital cash
+Also “Taler Wallet”.  Software component that manages the user’s digital cash
 and payments.
 @end table
 
 @node Developer Glossary,Developer Tools,User-Facing Terminology,Top
-@anchor{taler-developer-manual developer-glossary}@anchor{4e}
+@anchor{taler-developer-manual developer-glossary}@anchor{58}
 @chapter Developer Glossary
 
 
@@ -2347,168 +2785,168 @@ use when talking to end users or even system administrators.
 
 
 @table @asis
-@anchor{taler-developer-manual term-absolute-time}@anchor{4f}
+@anchor{taler-developer-manual term-absolute-time}@anchor{59}
 @geindex absolute time
 
 @item absolute time
 
-method of keeping time in @ref{50,,GNUnet} where the time is represented
+method of keeping time in @ref{5a,,GNUnet} where the time is represented
 as the number of microseconds since 1.1.1970 (UNIX epoch).  Called
-absolute time in contrast to @ref{51,,relative time}.
-@anchor{taler-developer-manual term-aggregate}@anchor{52}
+absolute time in contrast to @ref{5b,,relative time}.
+@anchor{taler-developer-manual term-aggregate}@anchor{5c}
 @geindex aggregate
 
 @item aggregate
 
-the @ref{53,,exchange} combines multiple payments received by the
-same @ref{54,,merchant} into one larger @ref{55,,wire transfer} to
-the respective merchant's @ref{56,,bank} account
-@anchor{taler-developer-manual term-auditor}@anchor{57}
+the @ref{5d,,exchange} combines multiple payments received by the
+same @ref{5e,,merchant} into one larger @ref{5f,,wire transfer} to
+the respective merchant’s @ref{60,,bank} account
+@anchor{taler-developer-manual term-auditor}@anchor{61}
 @geindex auditor
 
 @item auditor
 
-trusted third party that verifies that the @ref{53,,exchange} is operating correctly
-@anchor{taler-developer-manual term-bank}@anchor{56}
+trusted third party that verifies that the @ref{5d,,exchange} is operating correctly
+@anchor{taler-developer-manual term-bank}@anchor{60}
 @geindex bank
 
 @item bank
 
-traditional financial service provider who offers wire @ref{58,,transfers} between accounts
-@anchor{taler-developer-manual term-buyer}@anchor{59}
+traditional financial service provider who offers wire @ref{62,,transfers} between accounts
+@anchor{taler-developer-manual term-buyer}@anchor{63}
 @geindex buyer
 
 @item buyer
 
-individual in control of a Taler @ref{5a,,wallet}, usually using it to
-@ref{5b,,spend} the @ref{5c,,coins} on @ref{5d,,contracts} (see also @ref{5e,,customer}).
-@anchor{taler-developer-manual term-close}@anchor{5f}
+individual in control of a Taler @ref{64,,wallet}, usually using it to
+@ref{65,,spend} the @ref{66,,coins} on @ref{67,,contracts} (see also @ref{68,,customer}).
+@anchor{taler-developer-manual term-close}@anchor{69}
 @geindex close
 
-@item close@anchor{taler-developer-manual term-closes}@anchor{60}
+@item close@anchor{taler-developer-manual term-closes}@anchor{6a}
 @geindex closes
 
-@itemx closes@anchor{taler-developer-manual term-closed}@anchor{61}
+@itemx closes@anchor{taler-developer-manual term-closed}@anchor{6b}
 @geindex closed
 
-@itemx closed@anchor{taler-developer-manual term-closing}@anchor{62}
+@itemx closed@anchor{taler-developer-manual term-closing}@anchor{6c}
 @geindex closing
 
 @itemx closing
 
-operation an @ref{53,,exchange} performs on a @ref{63,,reserve} that has not been
-@ref{64,,drained} by @ref{65,,withdraw} operations. When closing a reserve, the
-exchange wires the remaining funds back to the customer, minus a @ref{66,,fee}
+operation an @ref{5d,,exchange} performs on a @ref{6d,,reserve} that has not been
+@ref{6e,,drained} by @ref{6f,,withdraw} operations. When closing a reserve, the
+exchange wires the remaining funds back to the customer, minus a @ref{70,,fee}
 for closing
-@anchor{taler-developer-manual term-coin}@anchor{67}
+@anchor{taler-developer-manual term-coin}@anchor{71}
 @geindex coin
 
-@item coin@anchor{taler-developer-manual term-coins}@anchor{5c}
+@item coin@anchor{taler-developer-manual term-coins}@anchor{66}
 @geindex coins
 
 @itemx coins
 
-coins are individual token representing a certain amount of value, also known as the @ref{68,,denomination} of the coin
-@anchor{taler-developer-manual term-commitment}@anchor{69}
+coins are individual token representing a certain amount of value, also known as the @ref{72,,denomination} of the coin
+@anchor{taler-developer-manual term-commitment}@anchor{73}
 @geindex commitment
 
-@item commitment@anchor{taler-developer-manual term-refresh-commitment}@anchor{6a}
+@item commitment@anchor{taler-developer-manual term-refresh-commitment}@anchor{74}
 @geindex refresh commitment
 
 @itemx refresh commitment
 
-data that the wallet commits to during the @ref{6b,,melt} stage of the
-@ref{6c,,refresh} protocol where it
-has to prove to the @ref{53,,exchange} that it is deriving the @ref{6d,,fresh}
+data that the wallet commits to during the @ref{75,,melt} stage of the
+@ref{76,,refresh} protocol where it
+has to prove to the @ref{5d,,exchange} that it is deriving the @ref{77,,fresh}
 coins as specified by the Taler protocol.  The commitment is verified
-probabilistically (see: @ref{6e,,kappa}) during the @ref{6f,,reveal} stage.
-@anchor{taler-developer-manual term-contract}@anchor{70}
+probabilistically (see: @ref{78,,kappa}) during the @ref{79,,reveal} stage.
+@anchor{taler-developer-manual term-contract}@anchor{7a}
 @geindex contract
 
-@item contract@anchor{taler-developer-manual term-contracts}@anchor{5d}
+@item contract@anchor{taler-developer-manual term-contracts}@anchor{67}
 @geindex contracts
 
 @itemx contracts
 
-formal agreement between @ref{54,,merchant} and @ref{5e,,customer} specifying the
-@ref{71,,contract terms} and signed by the merchant and the @ref{5c,,coins} of the
+formal agreement between @ref{5e,,merchant} and @ref{68,,customer} specifying the
+@ref{7b,,contract terms} and signed by the merchant and the @ref{66,,coins} of the
 customer
-@anchor{taler-developer-manual term-contract-terms}@anchor{71}
+@anchor{taler-developer-manual term-contract-terms}@anchor{7b}
 @geindex contract terms
 
 @item contract terms
 
 the individual clauses specifying what the buyer is purchasing from the
-@ref{54,,merchant}
-@anchor{taler-developer-manual term-customer}@anchor{5e}
+@ref{5e,,merchant}
+@anchor{taler-developer-manual term-customer}@anchor{68}
 @geindex customer
 
 @item customer
 
 individual that directs the buyer (perhaps the same individual) to make a purchase
-@anchor{taler-developer-manual term-denomination}@anchor{68}
+@anchor{taler-developer-manual term-denomination}@anchor{72}
 @geindex denomination
 
 @item denomination
 
-unit of currency, specifies both the currency and the face value of a @ref{67,,coin},
+unit of currency, specifies both the currency and the face value of a @ref{71,,coin},
 as well as associated fees and validity periods
-@anchor{taler-developer-manual term-denomination-key}@anchor{72}
+@anchor{taler-developer-manual term-denomination-key}@anchor{7c}
 @geindex denomination key
 
 @item denomination key
 
-(RSA) key used by the exchange to certify that a given @ref{67,,coin} is valid and of a
-particular @ref{68,,denomination}
-@anchor{taler-developer-manual term-deposit}@anchor{73}
+(RSA) key used by the exchange to certify that a given @ref{71,,coin} is valid and of a
+particular @ref{72,,denomination}
+@anchor{taler-developer-manual term-deposit}@anchor{7d}
 @geindex deposit
 
-@item deposit@anchor{taler-developer-manual term-deposits}@anchor{74}
+@item deposit@anchor{taler-developer-manual term-deposits}@anchor{7e}
 @geindex deposits
 
-@itemx deposits@anchor{taler-developer-manual term-depositing}@anchor{75}
+@itemx deposits@anchor{taler-developer-manual term-depositing}@anchor{7f}
 @geindex depositing
 
 @itemx depositing
 
 operation by which a merchant passes coins to an exchange, expecting the
 exchange to credit his bank account in the future using an
-@ref{52,,aggregate} @ref{55,,wire transfer}
-@anchor{taler-developer-manual term-dirty}@anchor{76}
+@ref{5c,,aggregate} @ref{5f,,wire transfer}
+@anchor{taler-developer-manual term-dirty}@anchor{80}
 @geindex dirty
 
-@item dirty@anchor{taler-developer-manual term-dirty-coin}@anchor{77}
+@item dirty@anchor{taler-developer-manual term-dirty-coin}@anchor{81}
 @geindex dirty coin
 
 @itemx dirty coin
 
 a coin is dirty if its public key may be known to an entity other than
 the customer, thereby creating the danger of some entity being able to
-link multiple transactions of coin's owner if the coin is not refreshed
-@anchor{taler-developer-manual term-drain}@anchor{78}
+link multiple transactions of coin’s owner if the coin is not refreshed
+@anchor{taler-developer-manual term-drain}@anchor{82}
 @geindex drain
 
-@item drain@anchor{taler-developer-manual term-drained}@anchor{64}
+@item drain@anchor{taler-developer-manual term-drained}@anchor{6e}
 @geindex drained
 
 @itemx drained
 
-a @ref{63,,reserve} is being drained when a @ref{5a,,wallet} is using the
-reserve's private key to @ref{65,,withdraw} coins from it. This reduces
+a @ref{6d,,reserve} is being drained when a @ref{64,,wallet} is using the
+reserve’s private key to @ref{6f,,withdraw} coins from it. This reduces
 the balance of the reserve. Once the balance reaches zero, we say that
 the reserve has been (fully) drained.  Reserves that are not drained
-(which is the normal process) are @ref{61,,closed} by the exchange.
-@anchor{taler-developer-manual term-exchange}@anchor{53}
+(which is the normal process) are @ref{6b,,closed} by the exchange.
+@anchor{taler-developer-manual term-exchange}@anchor{5d}
 @geindex exchange
 
 @item exchange
 
-Taler's payment service operator.  Issues electronic coins during
+Taler’s payment service operator.  Issues electronic coins during
 withdrawal and redeems them when they are deposited by merchants
-@anchor{taler-developer-manual term-expired}@anchor{79}
+@anchor{taler-developer-manual term-expired}@anchor{83}
 @geindex expired
 
-@item expired@anchor{taler-developer-manual term-expiration}@anchor{7a}
+@item expired@anchor{taler-developer-manual term-expiration}@anchor{84}
 @geindex expiration
 
 @itemx expiration
@@ -2517,52 +2955,52 @@ Various operations come with time limits. In particular, denomination keys
 come with strict time limits for the various operations involving the
 coin issued under the denomination. The most important limit is the
 deposit expiration, which specifies until when wallets are allowed to
-use the coin in deposit or refreshing operations. There is also a "legal"
+use the coin in deposit or refreshing operations. There is also a “legal”
 expiration, which specifies how long the exchange keeps records beyond the
 deposit expiration time.  This latter expiration matters for legal disputes
 in courts and also creates an upper limit for refreshing operations on
 special zombie coin
-@anchor{taler-developer-manual term-fakebank}@anchor{7b}
+@anchor{taler-developer-manual term-fakebank}@anchor{85}
 @geindex fakebank
 
 @item fakebank
 
-implementation of the @ref{56,,bank} API in memory to be used only for test
+implementation of the @ref{60,,bank} API in memory to be used only for test
 cases.
-@anchor{taler-developer-manual term-fee}@anchor{66}
+@anchor{taler-developer-manual term-fee}@anchor{70}
 @geindex fee
 
 @item fee
 
-an @ref{53,,exchange} charges various fees for its service. The different
+an @ref{5d,,exchange} charges various fees for its service. The different
 fees are specified in the protocol. There are fees per coin for
-@ref{7c,,withdrawing}, @ref{75,,depositing}, @ref{7d,,melting}, and
-@ref{7e,,refunding}.  Furthermore, there are fees per wire transfer
-for @ref{62,,closing} a @ref{63,,reserve}: and for
-@ref{52,,aggregate} @ref{7f,,wire transfers} to the @ref{54,,merchant}.
-@anchor{taler-developer-manual term-fresh}@anchor{6d}
+@ref{86,,withdrawing}, @ref{7f,,depositing}, @ref{87,,melting}, and
+@ref{88,,refunding}.  Furthermore, there are fees per wire transfer
+for @ref{6c,,closing} a @ref{6d,,reserve}: and for
+@ref{5c,,aggregate} @ref{89,,wire transfers} to the @ref{5e,,merchant}.
+@anchor{taler-developer-manual term-fresh}@anchor{77}
 @geindex fresh
 
-@item fresh@anchor{taler-developer-manual term-fresh-coin}@anchor{80}
+@item fresh@anchor{taler-developer-manual term-fresh-coin}@anchor{8a}
 @geindex fresh coin
 
 @itemx fresh coin
 
 a coin is fresh if its public key is only known to the customer
-@anchor{taler-developer-manual term-GNUnet}@anchor{50}
+@anchor{taler-developer-manual term-GNUnet}@anchor{5a}
 @geindex GNUnet
 
 @item GNUnet
 
 Codebase of various libraries for a better Internet, some of which
 GNU Taler depends upon.
-@anchor{taler-developer-manual term-json}@anchor{81}
+@anchor{taler-developer-manual term-json}@anchor{8b}
 @geindex json
 
-@item json@anchor{taler-developer-manual term-JSON}@anchor{82}
+@item json@anchor{taler-developer-manual term-JSON}@anchor{8c}
 @geindex JSON
 
-@itemx JSON@anchor{taler-developer-manual term-JavaScript-Object-Notation}@anchor{83}
+@itemx JSON@anchor{taler-developer-manual term-JavaScript-Object-Notation}@anchor{8d}
 @geindex JavaScript Object Notation
 
 @itemx JavaScript Object Notation
@@ -2570,190 +3008,192 @@ GNU Taler depends upon.
 serialization format derived from the JavaScript language which is
 commonly used in the Taler protocol as the payload of HTTP requests
 and responses.
-@anchor{taler-developer-manual term-kappa}@anchor{6e}
+@anchor{taler-developer-manual term-kappa}@anchor{78}
 @geindex kappa
 
 @item kappa
 
-security parameter used in the @ref{6c,,refresh} protocol. Defined to be 3.
+security parameter used in the @ref{76,,refresh} protocol. Defined to be 3.
 The probability of successfully evading the income transparency with the
 refresh protocol is 1:kappa.
-@anchor{taler-developer-manual term-LibEuFin}@anchor{84}
+@anchor{taler-developer-manual term-LibEuFin}@anchor{8e}
 @geindex LibEuFin
 
 @item LibEuFin
 
 FIXME: explain
-@anchor{taler-developer-manual term-link}@anchor{85}
+@anchor{taler-developer-manual term-link}@anchor{8f}
 @geindex link
 
-@item link@anchor{taler-developer-manual term-linking}@anchor{86}
+@item link@anchor{taler-developer-manual term-linking}@anchor{90}
 @geindex linking
 
 @itemx linking
 
-specific step in the @ref{6c,,refresh} protocol that an exchange must offer
-to prevent abuse of the @ref{6c,,refresh} mechanism.  The link step is
+specific step in the @ref{76,,refresh} protocol that an exchange must offer
+to prevent abuse of the @ref{76,,refresh} mechanism.  The link step is
 not needed in normal operation, it just must be offered.
-@anchor{taler-developer-manual term-master-key}@anchor{87}
+@anchor{taler-developer-manual term-master-key}@anchor{91}
 @geindex master key
 
 @item master key
 
 offline key used by the exchange to certify denomination keys and
 message signing keys
-@anchor{taler-developer-manual term-melt}@anchor{6b}
+@anchor{taler-developer-manual term-melt}@anchor{75}
 @geindex melt
 
-@item melt@anchor{taler-developer-manual term-melted}@anchor{88}
+@item melt@anchor{taler-developer-manual term-melted}@anchor{92}
 @geindex melted
 
-@itemx melted@anchor{taler-developer-manual term-melting}@anchor{7d}
+@itemx melted@anchor{taler-developer-manual term-melting}@anchor{87}
 @geindex melting
 
 @itemx melting
 
-step of the @ref{6c,,refresh} protocol where a @ref{77,,dirty coin}
-is invalidated to be reborn @ref{6d,,fresh} in a subsequent
-@ref{6f,,reveal} step.
-@anchor{taler-developer-manual term-merchant}@anchor{54}
+step of the @ref{76,,refresh} protocol where a @ref{81,,dirty coin}
+is invalidated to be reborn @ref{77,,fresh} in a subsequent
+@ref{79,,reveal} step.
+@anchor{taler-developer-manual term-merchant}@anchor{5e}
 @geindex merchant
 
 @item merchant
 
 party receiving payments (usually in return for goods or services)
-@anchor{taler-developer-manual term-message-signing-key}@anchor{89}
+@anchor{taler-developer-manual term-message-signing-key}@anchor{93}
 @geindex message signing key
 
 @item message signing key
 
 key used by the exchange to sign online messages, other than coins
-@anchor{taler-developer-manual term-order}@anchor{8a}
+@anchor{taler-developer-manual term-order}@anchor{94}
 @geindex order
 
 @item order
 
-FIXME: to be written!
-@anchor{taler-developer-manual term-owner}@anchor{8b}
+offer made by the merchant to a wallet; pre-cursor to
+a contract where the wallet is not yet fixed. Turns
+into a @ref{7a,,contract} when a wallet claims the order.
+@anchor{taler-developer-manual term-owner}@anchor{95}
 @geindex owner
 
 @item owner
 
 a coin is owned by the entity that knows the private key of the coin
-@anchor{taler-developer-manual term-planchet}@anchor{8c}
+@anchor{taler-developer-manual term-planchet}@anchor{96}
 @geindex planchet
 
 @item planchet
 
-precursor data for a @ref{67,,coin}. A planchet includes the coin's internal
+precursor data for a @ref{71,,coin}. A planchet includes the coin’s internal
 secrets (coin private key, blinding factor), but lacks the RSA signature
-of the @ref{53,,exchange}.  When @ref{7c,,withdrawing}, a @ref{5a,,wallet}
+of the @ref{5d,,exchange}.  When @ref{86,,withdrawing}, a @ref{64,,wallet}
 creates and persists a planchet before asking the exchange to sign it to
 get the coin.
-@anchor{taler-developer-manual term-privacy-policy}@anchor{8d}
+@anchor{taler-developer-manual term-privacy-policy}@anchor{97}
 @geindex privacy policy
 
 @item privacy policy
 
 Statement of an operator how they will protect the privacy of users.
-@anchor{taler-developer-manual term-proof}@anchor{8e}
+@anchor{taler-developer-manual term-proof}@anchor{98}
 @geindex proof
 
 @item proof
 
 Message that cryptographically demonstrates that a particular claim is correct.
-@anchor{taler-developer-manual term-proposal}@anchor{8f}
+@anchor{taler-developer-manual term-proposal}@anchor{99}
 @geindex proposal
 
 @item proposal
 
-a list of @ref{71,,contract terms} that has been completed and signed by the
+a list of @ref{7b,,contract terms} that has been completed and signed by the
 merchant backend.
-@anchor{taler-developer-manual term-purchase}@anchor{90}
+@anchor{taler-developer-manual term-purchase}@anchor{9a}
 @geindex purchase
 
 @item purchase
 
-Refers to the overall process of negotiating a @ref{70,,contract} and then
-making a payment with @ref{5c,,coins} to a @ref{54,,merchant}.
-@anchor{taler-developer-manual term-recoup}@anchor{91}
+Refers to the overall process of negotiating a @ref{7a,,contract} and then
+making a payment with @ref{66,,coins} to a @ref{5e,,merchant}.
+@anchor{taler-developer-manual term-recoup}@anchor{9b}
 @geindex recoup
 
 @item recoup
 
 Operation by which an exchange returns the value of coins affected
-by a @ref{92,,revocation} to their @ref{8b,,owner}, either by allowing the owner to
-withdraw new coins or wiring funds back to the bank account of the @ref{8b,,owner}.
-@anchor{taler-developer-manual term-refresh}@anchor{6c}
+by a @ref{9c,,revocation} to their @ref{95,,owner}, either by allowing the owner to
+withdraw new coins or wiring funds back to the bank account of the @ref{95,,owner}.
+@anchor{taler-developer-manual term-refresh}@anchor{76}
 @geindex refresh
 
-@item refresh@anchor{taler-developer-manual term-refreshing}@anchor{93}
+@item refresh@anchor{taler-developer-manual term-refreshing}@anchor{9d}
 @geindex refreshing
 
 @itemx refreshing
 
-operation by which a @ref{77,,dirty coin} is converted into one or more
-@ref{6d,,fresh} coins.  Involves @ref{7d,,melting} the @ref{77,,dirty coin} and
-then @ref{94,,revealing} so-called @ref{95,,transfer keys}.
-@anchor{taler-developer-manual term-refund}@anchor{96}
+operation by which a @ref{81,,dirty coin} is converted into one or more
+@ref{77,,fresh} coins.  Involves @ref{87,,melting} the @ref{81,,dirty coin} and
+then @ref{9e,,revealing} so-called @ref{9f,,transfer keys}.
+@anchor{taler-developer-manual term-refund}@anchor{a0}
 @geindex refund
 
-@item refund@anchor{taler-developer-manual term-refunding}@anchor{7e}
+@item refund@anchor{taler-developer-manual term-refunding}@anchor{88}
 @geindex refunding
 
 @itemx refunding
 
 operation by which a merchant steps back from the right to funds that he
-obtained from a @ref{73,,deposit} operation, giving the right to the funds back
+obtained from a @ref{7d,,deposit} operation, giving the right to the funds back
 to the customer
-@anchor{taler-developer-manual term-refund-transaction-id}@anchor{97}
+@anchor{taler-developer-manual term-refund-transaction-id}@anchor{a1}
 @geindex refund transaction id
 
 @item refund transaction id
 
-unique number by which a merchant identifies a @ref{96,,refund}. Needed
+unique number by which a merchant identifies a @ref{a0,,refund}. Needed
 as refunds can be partial and thus there could be multiple refunds for
-the same @ref{90,,purchase}.
-@anchor{taler-developer-manual term-relative-time}@anchor{51}
+the same @ref{9a,,purchase}.
+@anchor{taler-developer-manual term-relative-time}@anchor{5b}
 @geindex relative time
 
 @item relative time
 
-method of keeping time in @ref{50,,GNUnet} where the time is represented
+method of keeping time in @ref{5a,,GNUnet} where the time is represented
 as a relative number of microseconds.  Thus, a relative time specifies
 an offset or a duration, but not a date.  Called relative time in
-contrast to @ref{4f,,absolute time}.
-@anchor{taler-developer-manual term-reserve}@anchor{63}
+contrast to @ref{59,,absolute time}.
+@anchor{taler-developer-manual term-reserve}@anchor{6d}
 @geindex reserve
 
 @item reserve
 
 accounting mechanism used by the exchange to track customer funds
-from incoming @ref{7f,,wire transfers}.  A reserve is created whenever
+from incoming @ref{89,,wire transfers}.  A reserve is created whenever
 a customer wires money to the exchange using a well-formed public key
-in the subject.  The exchange then allows the customer's @ref{5a,,wallet}
-to @ref{65,,withdraw} up to the amount received in @ref{6d,,fresh}
-@ref{5c,,coins} from the reserve, thereby draining the reserve. If a
-reserve is not drained, the exchange eventually @ref{60,,closes} it.
+in the subject.  The exchange then allows the customer’s @ref{64,,wallet}
+to @ref{6f,,withdraw} up to the amount received in @ref{77,,fresh}
+@ref{66,,coins} from the reserve, thereby draining the reserve. If a
+reserve is not drained, the exchange eventually @ref{6a,,closes} it.
 
 Other definition: Funds set aside for future use; either the balance of a customer at the
 exchange ready for withdrawal, or the funds kept in the exchange;s bank
 account to cover obligations from coins in circulation.
-@anchor{taler-developer-manual term-reveal}@anchor{6f}
+@anchor{taler-developer-manual term-reveal}@anchor{79}
 @geindex reveal
 
-@item reveal@anchor{taler-developer-manual term-revealing}@anchor{94}
+@item reveal@anchor{taler-developer-manual term-revealing}@anchor{9e}
 @geindex revealing
 
 @itemx revealing
 
-step in the @ref{6c,,refresh} protocol where some of the transfer private
+step in the @ref{76,,refresh} protocol where some of the transfer private
 keys are revealed to prove honest behavior on the part of the wallet.
-In the reveal step, the exchange returns the signed @ref{6d,,fresh} coins.
-@anchor{taler-developer-manual term-revoke}@anchor{98}
+In the reveal step, the exchange returns the signed @ref{77,,fresh} coins.
+@anchor{taler-developer-manual term-revoke}@anchor{a2}
 @geindex revoke
 
-@item revoke@anchor{taler-developer-manual term-revocation}@anchor{92}
+@item revoke@anchor{taler-developer-manual term-revocation}@anchor{9c}
 @geindex revocation
 
 @itemx revocation
@@ -2762,109 +3202,109 @@ exceptional operation by which an exchange withdraws a denomination from
 circulation, either because the signing key was compromised or because
 the exchange is going out of operation; unspent coins of a revoked
 denomination are subjected to recoup.
-@anchor{taler-developer-manual term-sharing}@anchor{99}
+@anchor{taler-developer-manual term-sharing}@anchor{a3}
 @geindex sharing
 
 @item sharing
 
-users can share ownership of a @ref{67,,coin} by sharing access to the coin&#39;s
+users can share ownership of a @ref{71,,coin} by sharing access to the coin's
 private key, thereby allowing all co-owners to spend the coin at any
 time.
-@anchor{taler-developer-manual term-spend}@anchor{5b}
+@anchor{taler-developer-manual term-spend}@anchor{65}
 @geindex spend
 
-@item spend@anchor{taler-developer-manual term-spending}@anchor{9a}
+@item spend@anchor{taler-developer-manual term-spending}@anchor{a4}
 @geindex spending
 
 @itemx spending
 
 operation by which a customer gives a merchant the right to deposit
 coins in return for merchandise
-@anchor{taler-developer-manual term-terms}@anchor{9b}
+@anchor{taler-developer-manual term-terms}@anchor{a5}
 @geindex terms
 
 @item terms
 
 the general terms of service of an operator, possibly including
-the @ref{8d,,privacy policy}.  Not to be confused with the
-@ref{71,,contract terms} which are about the specific purchase.
-@anchor{taler-developer-manual term-transaction}@anchor{9c}
+the @ref{97,,privacy policy}.  Not to be confused with the
+@ref{7b,,contract terms} which are about the specific purchase.
+@anchor{taler-developer-manual term-transaction}@anchor{a6}
 @geindex transaction
 
 @item transaction
 
 method by which ownership is exclusively transferred from one entity
-@anchor{taler-developer-manual term-transfer}@anchor{58}
+@anchor{taler-developer-manual term-transfer}@anchor{62}
 @geindex transfer
 
-@item transfer@anchor{taler-developer-manual term-transfers}@anchor{9d}
+@item transfer@anchor{taler-developer-manual term-transfers}@anchor{a7}
 @geindex transfers
 
-@itemx transfers@anchor{taler-developer-manual term-wire-transfer}@anchor{55}
+@itemx transfers@anchor{taler-developer-manual term-wire-transfer}@anchor{5f}
 @geindex wire transfer
 
-@itemx wire transfer@anchor{taler-developer-manual term-wire-transfers}@anchor{7f}
+@itemx wire transfer@anchor{taler-developer-manual term-wire-transfers}@anchor{89}
 @geindex wire transfers
 
 @itemx wire transfers
 
-method of sending funds between @ref{56,,bank} accounts
-@anchor{taler-developer-manual term-transfer-key}@anchor{9e}
+method of sending funds between @ref{60,,bank} accounts
+@anchor{taler-developer-manual term-transfer-key}@anchor{a8}
 @geindex transfer key
 
-@item transfer key@anchor{taler-developer-manual term-transfer-keys}@anchor{95}
+@item transfer key@anchor{taler-developer-manual term-transfer-keys}@anchor{9f}
 @geindex transfer keys
 
 @itemx transfer keys
 
-special cryptographic key used in the @ref{6c,,refresh} protocol, some of which
-are revealed during the @ref{6f,,reveal} step. Note that transfer keys have,
-despite the name, no relationship to @ref{7f,,wire transfers}.  They merely
-help to transfer the value from a @ref{77,,dirty coin} to a @ref{80,,fresh coin}
-@anchor{taler-developer-manual term-user}@anchor{9f}
+special cryptographic key used in the @ref{76,,refresh} protocol, some of which
+are revealed during the @ref{79,,reveal} step. Note that transfer keys have,
+despite the name, no relationship to @ref{89,,wire transfers}.  They merely
+help to transfer the value from a @ref{81,,dirty coin} to a @ref{8a,,fresh coin}
+@anchor{taler-developer-manual term-user}@anchor{a9}
 @geindex user
 
 @item user
 
 any individual using the Taler payment system
-(see @ref{5e,,customer}, @ref{59,,buyer}, @ref{54,,merchant}).
-@anchor{taler-developer-manual term-version}@anchor{a0}
+(see @ref{68,,customer}, @ref{63,,buyer}, @ref{5e,,merchant}).
+@anchor{taler-developer-manual term-version}@anchor{aa}
 @geindex version
 
 @item version
 
 Taler uses various forms of versioning. There is a database
 schema version (stored itself in the database, see *-0000.sql) describing
-the state of the table structure in the database of an @ref{53,,exchange},
-@ref{57,,auditor} or @ref{54,,merchant}. There is a protocol
+the state of the table structure in the database of an @ref{5d,,exchange},
+@ref{61,,auditor} or @ref{5e,,merchant}. There is a protocol
 version (CURRENT:REVISION:AGE, see GNU libtool) which specifies
-the network protocol spoken by an @ref{53,,exchange} or @ref{54,,merchant}
+the network protocol spoken by an @ref{5d,,exchange} or @ref{5e,,merchant}
 including backwards-compatibility. And finally there is the software
 release version (MAJOR.MINOR.PATCH, see @indicateurl{https://semver.org/}) of
 the respective code base.
-@anchor{taler-developer-manual term-wallet}@anchor{5a}
+@anchor{taler-developer-manual term-wallet}@anchor{64}
 @geindex wallet
 
 @item wallet
 
-software running on a customer's computer; withdraws, stores and
+software running on a customer’s computer; withdraws, stores and
 spends coins
-@anchor{taler-developer-manual term-WebExtension}@anchor{a1}
+@anchor{taler-developer-manual term-WebExtension}@anchor{ab}
 @geindex WebExtension
 
 @item WebExtension
 
 Cross-browser API used to implement the GNU Taler wallet browser extension.
-@anchor{taler-developer-manual term-wire-gateway}@anchor{a2}
+@anchor{taler-developer-manual term-wire-gateway}@anchor{ac}
 @geindex wire gateway
 
 @item wire gateway
 
 FIXME: explain
-@anchor{taler-developer-manual term-wire-transfer-identifier}@anchor{a3}
+@anchor{taler-developer-manual term-wire-transfer-identifier}@anchor{ad}
 @geindex wire transfer identifier
 
-@item wire transfer identifier@anchor{taler-developer-manual term-wtid}@anchor{a4}
+@item wire transfer identifier@anchor{taler-developer-manual term-wtid}@anchor{ae}
 @geindex wtid
 
 @itemx wtid
@@ -2872,35 +3312,35 @@ FIXME: explain
 Subject of a wire transfer from the exchange to a merchant;
 set by the aggregator to a random nonce which uniquely
 identifies the transfer.
-@anchor{taler-developer-manual term-withdraw}@anchor{65}
+@anchor{taler-developer-manual term-withdraw}@anchor{6f}
 @geindex withdraw
 
-@item withdraw@anchor{taler-developer-manual term-withdrawing}@anchor{7c}
+@item withdraw@anchor{taler-developer-manual term-withdrawing}@anchor{86}
 @geindex withdrawing
 
-@itemx withdrawing@anchor{taler-developer-manual term-withdrawal}@anchor{a5}
+@itemx withdrawing@anchor{taler-developer-manual term-withdrawal}@anchor{af}
 @geindex withdrawal
 
 @itemx withdrawal
 
-operation by which a @ref{5a,,wallet} can convert funds from a @ref{63,,reserve} to
+operation by which a @ref{64,,wallet} can convert funds from a @ref{6d,,reserve} to
 fresh coins
-@anchor{taler-developer-manual term-zombie}@anchor{a6}
+@anchor{taler-developer-manual term-zombie}@anchor{b0}
 @geindex zombie
 
-@item zombie@anchor{taler-developer-manual term-zombie-coin}@anchor{a7}
+@item zombie@anchor{taler-developer-manual term-zombie-coin}@anchor{b1}
 @geindex zombie coin
 
 @itemx zombie coin
 
-coin where the respective @ref{72,,denomination key} is past its
-@ref{73,,deposit} @ref{7a,,expiration} time, but which is still (again) valid
-for an operation because it was @ref{88,,melted} while it was still
-valid, and then later again credited during a @ref{91,,recoup} process
+coin where the respective @ref{7c,,denomination key} is past its
+@ref{7d,,deposit} @ref{84,,expiration} time, but which is still (again) valid
+for an operation because it was @ref{92,,melted} while it was still
+valid, and then later again credited during a @ref{9b,,recoup} process
 @end table
 
 @node Developer Tools,Index,Developer Glossary,Top
-@anchor{taler-developer-manual developer-tools}@anchor{a8}
+@anchor{taler-developer-manual developer-tools}@anchor{b2}
 @chapter Developer Tools
 
 
@@ -2913,100 +3353,100 @@ developer.
 @end menu
 
 @node taler-config-generate,,,Developer Tools
-@anchor{taler-developer-manual taler-config-generate}@anchor{a9}
+@anchor{taler-developer-manual taler-config-generate}@anchor{b3}
 @section taler-config-generate
 
 
-@strong{taler-config-generate} - tool to simplify Taler configuration generation
-
-@strong{taler-config-generate}
-[@strong{-C} @emph{CURRENCY} | @strong{--currency=}‌@emph{CURRENCY}]
-[@strong{-c} @emph{FILENAME} | @strong{--config=}‌@emph{FILENAME}]
-[@strong{-e} | @strong{--exchange}]
-[@strong{-f} @emph{AMOUNT} | @emph{--wirefee=}‌@emph{AMOUNT}]
-[@strong{-h} | @strong{--help}]
-[@strong{-J} @emph{JSON} | @strong{--wire-json-exchange=}‌@emph{JSON}]
-[@strong{-j} @emph{JSON} | @strong{--wire-json-merchant=}‌@emph{JSON}]
-[@strong{-L} @emph{LOGLEVEL} | @strong{--loglevel=}‌@emph{LOGLEVEL}]
-[@strong{-m} | @strong{--merchant}]
-[@strong{-t} | @strong{--trusted}]
-[@strong{-v} | @strong{--version}]
-[@strong{-w} @emph{WIREFORMAT} | @strong{--wire} @emph{WIREFORMAT}]
-[@strong{--bank-uri}]
-[@strong{--exchange-bank-account}]
-[@strong{--merchant-bank-account}]
-
-@strong{taler-config-generate} can be used to generate configuration files
+`taler-config-generate' - tool to simplify Taler configuration generation
+
+`taler-config-generate'
+[`-C' `CURRENCY' | `–currency='‌`CURRENCY']
+[`-c' `FILENAME' | `–config='‌`FILENAME']
+[`-e' | `–exchange']
+[`-f' `AMOUNT' | `–wirefee='‌`AMOUNT']
+[`-h' | `–help']
+[`-J' `JSON' | `–wire-json-exchange='‌`JSON']
+[`-j' `JSON' | `–wire-json-merchant='‌`JSON']
+[`-L' `LOGLEVEL' | `–loglevel='‌`LOGLEVEL']
+[`-m' | `–merchant']
+[`-t' | `–trusted']
+[`-v' | `–version']
+[`-w' `WIREFORMAT' | `–wire' `WIREFORMAT']
+[`–bank-uri']
+[`–exchange-bank-account']
+[`–merchant-bank-account']
+
+`taler-config-generate' can be used to generate configuration files
 for the Taler exchange or Taler merchants.
 
 
 @table @asis
 
-@item @strong{-C} @emph{CURRENCY} | @strong{--currency=}‌@emph{CURRENCY}
+@item `-C' `CURRENCY' | `–currency='‌`CURRENCY'
 
 Which currency should we use in the configuration.
 
-@item @strong{-c} @emph{FILENAME} | @strong{--config=}‌@emph{FILENAME}
+@item `-c' `FILENAME' | `–config='‌`FILENAME'
 
 Location where to write the generated configuration. Existing file
 will be updated, not overwritten.
 
-@item @strong{-e} | @strong{--exchange}
+@item `-e' | `–exchange'
 
 Generate configuration for a Taler exchange.
 
-@item @strong{-f} @emph{AMOUNT} | @emph{-wirefee=}‌@emph{AMOUNT}
+@item `-f' `AMOUNT' | `-wirefee='‌`AMOUNT'
 
 Setup wire transfer fees for the next 5 years for the exchange (for
 all wire methods).
 
-@item @strong{-h} | @strong{--help}
+@item `-h' | `–help'
 
 Shows this man page.
 
-@item @strong{-J} @emph{JSON} | @strong{--wire-json-exchange=}‌@emph{JSON}
+@item `-J' `JSON' | `–wire-json-exchange='‌`JSON'
 
 Wire configuration to use for the exchange.
 
-@item @strong{-j} @emph{JSON} | @strong{--wire-json-merchant=}‌@emph{JSON}
+@item `-j' `JSON' | `–wire-json-merchant='‌`JSON'
 
 Wire configuration to use for the merchant.
 
-@item @strong{-L} @emph{LOGLEVEL} | @strong{--loglevel=}‌@emph{LOGLEVEL}
+@item `-L' `LOGLEVEL' | `–loglevel='‌`LOGLEVEL'
 
 Use LOGLEVEL for logging. Valid values are DEBUG, INFO, WARNING and
 ERROR.
 
-@item @strong{-m} | @strong{--merchant}
+@item `-m' | `–merchant'
 
 Generate configuration for a Taler merchant.
 
-@item @strong{-t} | @strong{--trusted}
+@item `-t' | `–trusted'
 
 Setup current exchange as trusted with current merchant. Generally
 only useful when configuring for testcases.
 
-@item @strong{-v} | @strong{--version}
+@item `-v' | `–version'
 
 Print version information.
 
-@item @strong{-w} @emph{WIREFORMAT} | @strong{--wire} @emph{WIREFORMAT}
+@item `-w' `WIREFORMAT' | `–wire' `WIREFORMAT'
 
 Specifies which wire format to use (i.e. “x-talerbank” or “iban”)
 
-@item @strong{--bank-uri}
+@item `–bank-uri'
 
 Alternative to specify wire configuration to use for the exchange and
 merchant for the “test” wire method. Only useful if WIREFORMAT was
 set to “test”. Specifies the URI of the bank.
 
-@item @strong{--exchange-bank-account}
+@item `–exchange-bank-account'
 
 Alternative to specify wire configuration to use for the exchange for
 the “test” wire method. Only useful if WIREFORMAT was set to “test”.
 Specifies the bank account number of the exchange.
 
-@item @strong{--merchant-bank-account}
+@item `–merchant-bank-account'
 
 Alternative to specify wire configuration to use for the merchant for
 the “test” wire method. Only useful if WIREFORMAT was set to “test”.
diff --git a/texinfo/taler-exchange-figures/exchange-db.png b/texinfo/taler-exchange-figures/exchange-db.png
index f99e2664..7a4050c6 100644
--- a/texinfo/taler-exchange-figures/exchange-db.png
+++ b/texinfo/taler-exchange-figures/exchange-db.png
diff --git a/texinfo/taler-exchange.texi b/texinfo/taler-exchange.texi
index 6690110a..d6f5b79f 100644
--- a/texinfo/taler-exchange.texi
+++ b/texinfo/taler-exchange.texi
@@ -3,7 +3,7 @@
 @setfilename taler-exchange.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 3.4.3.@*
+@*Generated by Sphinx 5.3.0.@*
 @end ifinfo
 @settitle Taler Exchange Manual
 @defindex ge
@@ -15,13 +15,11 @@
 * MENU ENTRY: (taler-exchange.info). DESCRIPTION
 @end direntry
 
-@definfoenclose strong,`,'
-@definfoenclose emph,`,'
 @c %**end of header
 
 @copying
 @quotation
-GNU Taler 0.9.0, Nov 03, 2022
+GNU Taler 0.9.0, Sep 24, 2023
 
 GNU Taler team
 
@@ -50,7 +48,7 @@ Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 @anchor{taler-exchange-manual doc}@anchor{0}
 @c This file is part of GNU TALER.
 @c 
-@c Copyright (C) 2014-2020 Taler Systems SA
+@c Copyright (C) 2014-2023 Taler Systems SA
 @c 
 @c TALER is free software; you can redistribute it and/or modify it under the
 @c terms of the GNU Affero General Public License as published by the Free Software
@@ -64,15 +62,22 @@ Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 @c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
 @c 
 @c @author Christian Grothoff
+@c @author Florian Dold
 
 @menu
 * Introduction:: 
 * Installation:: 
-* Configuration: Configuration<2>. 
+* Configuration Fundamentals:: 
+* Exchange Database Setup:: 
+* Basic Setup; Currency@comma{} Denominations and Keys: Basic Setup Currency Denominations and Keys. 
+* Wire Gateway Setup:: 
+* Legal Setup:: 
 * Deployment:: 
-* Testing a deployment:: 
-* Diagnostics:: 
+* Offline Signing Setup@comma{} Key Maintenance and Tear-Down: Offline Signing Setup Key Maintenance and Tear-Down. 
+* Setup Linting:: 
+* Testing and Troubleshooting:: 
 * Benchmarking:: 
+* FIXMEs:: 
 * Index:: 
 
 @detailmenu
@@ -84,6 +89,7 @@ Introduction
 * About this manual:: 
 * Organizational prerequisites:: 
 * Architecture overview:: 
+* Key Types:: 
 * Offline keys:: 
 * Online signing key security:: 
 
@@ -96,48 +102,94 @@ Online signing key security
 
 Installation
 
+* Before you start:: 
 * Installing from source:: 
 * Installing the GNU Taler binary packages on Debian:: 
 * Installing the GNU Taler binary packages on Trisquel:: 
 * Installing the GNU Taler binary packages on Ubuntu:: 
+* Services@comma{} users@comma{} groups and file system hierarchy: Services users groups and file system hierarchy. 
 
-Configuration
+Configuration Fundamentals
 
 * Configuration format:: 
 * Using taler-config:: 
-* Keying:: 
-* Serving:: 
-* Currency:: 
-* Database:: 
+
+Basic Setup: Currency, Denominations and Keys
+
 * Coins (denomination keys): Coins denomination keys. 
 * Sign keys:: 
+* Setting up the offline signing key:: 
+
+Wire Gateway Setup
+
+* Installation and Basic Configuration:: 
+* Connecting Nexus with an EBICS account:: 
+* Exchange Bank Account Configuration:: 
+
+Connecting Nexus with an EBICS account
+
+* Testing; Requesting the transaction history: Testing Requesting the transaction history. 
+* Testing; Making payments: Testing Making payments. 
+* Automatic scheduling:: 
+* Creating a Taler facade:: 
+* Managing Permissions and Users:: 
+
+Legal Setup
+
+* Legal conditions for using the service:: 
 * Terms of Service:: 
-* Bank account:: 
-* Auditor configuration:: 
+* Privacy Policy:: 
+* Legal policies directory layout:: 
+* Generating the Legal Terms:: 
+* Adding translations:: 
+* Updating legal documents:: 
+* KYC Configuration:: 
+* KYC AID specifics:: 
 
-Terms of Service
+Legal policies directory layout
 
 * Example:: 
 
-Bank account
+KYC Configuration
 
-* Wire fee structure:: 
+* Taler KYC Terminology:: 
+* KYC Configuration Options:: 
+* OAuth 2.0 specifics: OAuth 2 0 specifics. 
+* Persona specifics:: 
 
 Deployment
 
+* Serving:: 
+* Reverse Proxy Setup:: 
 * Launching an exchange:: 
-* Keys generation:: 
-* Private key storage:: 
-* Database upgrades:: 
 
-Database upgrades
+Offline Signing Setup, Key Maintenance and Tear-Down
 
+* Signing the online signing keys:: 
+* Account signing:: 
+* Wire fee structure:: 
+* Auditor configuration:: 
 * Revocations:: 
+* AML Configuration:: 
+
+AML Configuration
+
+* AML Officer Setup:: 
+* AML Triggers:: 
 
-Diagnostics
+Testing and Troubleshooting
 
+* Private key storage:: 
 * Internal audits:: 
 * Database Scheme:: 
+* Database upgrades:: 
+
+Benchmarking
+
+* Choosing a bank:: 
+* taler-bank-benchmark:: 
+* taler-exchange-benchmark:: 
+* taler-aggregator-benchmark:: 
 
 @end detailmenu
 @end menu
@@ -147,14 +199,12 @@ Diagnostics
 @chapter Introduction
 
 
-This manual is an early draft that still needs significant editing work
-to become readable.
-
 @menu
 * About GNU Taler:: 
 * About this manual:: 
 * Organizational prerequisites:: 
 * Architecture overview:: 
+* Key Types:: 
 * Offline keys:: 
 * Online signing key security:: 
 
@@ -165,6 +215,21 @@ to become readable.
 @section About GNU Taler
 
 
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+
 GNU Taler is an open protocol for an electronic payment system with a
 free software reference implementation. GNU Taler offers secure, fast
 and easy payment processing using well understood cryptographic
@@ -174,18 +239,12 @@ GNU Taler is compatible with anti-money-laundering (AML) and
 know-your-customer (KYC) regulation, as well as data protection
 regulation (such as GDPR).
 
-GNU Taler is not yet production-ready, after following this manual you
-will have a backend that can process payments in “KUDOS”, but not
-regular currencies. This is not so much because of limitations in the
-backend, but because we are not aware of a Taler exchange operator
-offering regular currencies today.
-
 @node About this manual,Organizational prerequisites,About GNU Taler,Introduction
 @anchor{taler-exchange-manual about-this-manual}@anchor{4}
 @section About this manual
 
 
-This tutorial targets system administrators who want to install and
+This manual targets system administrators who want to install and
 operate a GNU Taler exchange.
 
 @node Organizational prerequisites,Architecture overview,About this manual,Introduction
@@ -193,70 +252,75 @@ operate a GNU Taler exchange.
 @section Organizational prerequisites
 
 
-Operating a GNU Taler exchange means that you are operating a payment
-service provider, which means that you will most likely need a bank
-license and/or follow applicable financial regulation.
+Operating a GNU Taler exchange means that you are operating a payment service
+provider, which means that you will most likely need a bank license and/or
+follow applicable financial regulation. Exceptions may apply, especially if
+you are operating a regional currency or a payment system for an event with a
+closed user group.
 
-GNU Taler payment service providers generally need to ensure high
-availability and have @emph{really} good backups (synchronous replication,
-asynchronous remote replication, off-site backup, 24/7 monitoring,
-etc.).  This manual will not cover these aspects of operating a
-payment service provider.
+GNU Taler payment service providers generally need to ensure high availability
+and should have `really' good backups (synchronous replication, asynchronous
+remote replication, off-site backup, 24/7 monitoring, etc.).  This manual will
+not cover these aspects of operating a payment service provider.
 
-We will assume that you can operate a (high-availability,
+We will assume that you can operate a (sufficiently high-availability,
 high-assurance) PostgreSQL database. Furthermore, we expect some moderate
 familiarity with the compilation and installation of free software
-packages. You need to understand the cryptographic concepts of private
-and public keys and must be able to protect private keys stored in files
-on disk.
+packages. You need to understand the cryptographic concepts of private and
+public keys and must be able to protect private keys stored in files on disk.
 
 @cartouche
 @quotation Note 
-The Taler merchant backend stores private keys and other sensitive
-business and customer data in the database.  The backend operator
-SHOULD ensure that backup operations are encrypted and secured from
-unauthorized access.
+Taler may store sensitive business and customer data in the database.  Any
+operator SHOULD thus ensure that backup operations are encrypted and
+secured from unauthorized access.
 @end quotation
 @end cartouche
 
-@node Architecture overview,Offline keys,Organizational prerequisites,Introduction
+@node Architecture overview,Key Types,Organizational prerequisites,Introduction
 @anchor{taler-exchange-manual architecture-overview}@anchor{6}
 @section Architecture overview
 
 
-Taler is a pure payment system, not a new crypto-currency. As such, it
-operates in a traditional banking context. In particular, this means
-that in order to receive funds via Taler, the merchant must have a
-regular bank account, and payments can be executed in ordinary
-currencies such as USD or EUR. Similarly, the Taler exchange must
-interact with a bank. The bank of the exchange holds the exchange’s
-funds in an escrow account.
-
-Note that, given the technical burden (XML-based communications,
-additional cryptography, and a vast variety of standards) due to
-interact with banks, the exchange uses an intermediary system to talk
-to its bank.  Such intermediary system abstracts the native banking
-protocol by exposing the @emph{Taler Wire Gateway API}; this way, the exchange
-can conduct its banking operations in a simplified and JSON-based style.
-
-When customers wire money to the escrow account, the bank notifies the
-exchange about the incoming wire transfers. The exchange then creates a
-@emph{reserve} based on the subject of the wire transfer. The wallet which
-knows the secret key matching the wire transfer subject can then
-withdraw coins from the reserve, thereby draining it. The liability of
-the exchange against the reserve is thereby converted into a liability
-against digital coins issued by the exchange. When the customer later
-spends the coins at a merchant, and the merchant @emph{deposits} the coins at
-the exchange, the exchange first @emph{aggregates} the amount from multiple
-deposits from the same merchant and then instructs its bank to make a
-wire transfer to the merchant, thereby fulfilling its obligation and
-eliminating the liability. The exchange charges @emph{fees} for some or all
-of its operations to cover costs and possibly make a profit.
-
-@emph{Auditors} are third parties, for example financial regulators, that
-verify that the exchange operates correctly. The same software is also
-used to calculate the exchange’s profits, risk and liabilities by the
-accountants of the exchange.
+GNU Taler is a pure payment system, not a crypto-currency. As such, it
+operates in a traditional banking context. In particular, this means that
+payments can be executed in ordinary currencies such as USD or EUR.
+Furthermore, a typical merchant in Taler has a regular bank account, and would
+use it to receive funds via Taler.
+
+Consequently, a typical Taler exchange must interact with a bank. The bank of
+the exchange holds funds in an account where the balance is basically
+equivalent to the value of all coins in circulation. (Small mismatches arise
+whenever customers are about to withdraw coins and have already send the funds
+into the bank account, or if merchants just deposited coins and are about to
+receive wire transfers for deposited coins, or due to fees charged by the
+exchange and the operator not yet having drained the fees from the account.)
+
+The exchange uses an intermediary system to talk to its bank.  This shifts the
+technical burden (XML-based communications, additional cryptography, and a
+vast variety of standards) for this interaction into another bank-specific
+subsystem.  Such intermediary system abstracts the native banking protocol by
+exposing the `Taler Wire Gateway API'; this way, the exchange can conduct its
+banking operations in a simplified and JSON-based style.
+
+When customers wire money to the exchange’s bank account, the Taler Wire
+Gateway API must notify the exchange about the incoming wire transfers. The
+exchange then creates a `reserve' based on the subject of the wire
+transfer. The wallet which knows the secret key matching the wire transfer
+subject can then withdraw coins from the reserve, thereby draining it. The
+liability of the exchange against the reserve is thereby converted into a
+liability against digital coins issued by the exchange. When the customer
+later spends the coins at a merchant, and the merchant `deposits' the coins at
+the exchange, the exchange first `aggregates' the amount from multiple
+deposits from the same merchant and then instructs its bank to make a wire
+transfer to the merchant, thereby fulfilling its obligation and eliminating
+the liability. The exchange charges `fees' for some or all of its operations
+to cover costs and possibly make a profit.
+
+`Auditors' are third parties, for example financial regulators, that verify
+that the exchange operates correctly. The same software is also used to
+calculate the exchange’s profits, risk and liabilities by the accountants of
+the exchange.
 
 The Taler software stack for an exchange consists of the following
 components:
@@ -265,7 +329,7 @@ components:
 @itemize -
 
 @item 
-HTTP frontend
+`HTTP frontend':
 The HTTP frontend interacts with Taler wallets and merchant backends.
 It is used to withdraw coins, deposit coins, refresh coins, issue
 refunds, map wire transfers to Taler transactions, inquire about the
@@ -273,15 +337,16 @@ exchange’s bank account details, signing keys and fee structure. The
 binary is the @code{taler-exchange-httpd}.
 
 @item 
-Crypto-Helpers
-The @code{taler-exchange-secmod-rsa} and @code{taler-exchange-secmod-eddsa}
-are two programs that are responsible for managing the exchange's
+`Crypto-Helpers':
+The @code{taler-exchange-secmod-rsa}, @code{taler-exchange-secmod-cs} and
+@code{taler-exchange-secmod-eddsa}
+are three programs that are responsible for managing the exchange’s
 online signing keys. They must run on the same machine as the
 @code{taler-exchange-httpd} as the HTTP frontend communicates with the
 crypto helpers using UNIX Domain Sockets.
 
 @item 
-Aggregator
+`Aggregator':
 The aggregator combines multiple deposits made by the same merchant
 and (eventually) triggers wire transfers for the aggregate amount.
 The merchant can control how quickly wire transfers are made. The
@@ -290,15 +355,15 @@ excessively frequent transfers. The binary is the
 @code{taler-exchange-aggregator}.
 
 @item 
-Closer
+`Closer':
 The @code{taler-exchange-closer} tool check that reserves are properly
 closed. If a customer wires funds to an exchange and then fails
 to withdraw them, the closer will (eventually) trigger a wire
-transfer that sends the customer's funds back to the originating
+transfer that sends the customer’s funds back to the originating
 wire account.
 
 @item 
-Transfer
+`Transfer':
 The @code{taler-exchange-transfer} tool is responsible for actually
 executing the aggregated wire transfers. It is the only process
 that needs to have the credentials to execute outgoing wire
@@ -309,7 +374,7 @@ by LibEuFin.  LibEuFin is an adapter which maps the Taler Wire
 REST API to traditional banking protocols like EBICS and FinTS.
 
 @item 
-Wirewatch
+`Wirewatch':
 The @code{taler-exchange-wirewatch} tool is responsible for observing
 incoming wire transfers to the exchange. It needs to have the
 credentials to obtain a list of incoming wire transfers.
@@ -319,33 +384,38 @@ making outgoing wire transfers is done via different bank accounts
 and/or credentials.
 
 @item 
-Wire adapter
+`Wire adapter':
 A wire adapter is a component that enables exchange to talk to a bank.
+Each wire adapter must implement the Taler Wire Gateway API.  Three
+wire adapters are currently provided:
 
 
 @enumerate 
 
 @item 
-The libtalerfakebank implements a bank with a wire adapter API
-inside of a testcase.
+The `libtalerfakebank' implements a bank with a wire adapter API
+inside of a testcase.  @code{taler-fakebank-run} is a stand-alone
+process using libtalerfakebank.  Note that this adapter is only
+useful for tests, as all transaction data is kept in memory.
 
 @item 
-For the demonstration Web site (or local currencies),
-the Python bank provides a bank that directly provides
-the wire adapter API.
+For production, `libeufin'’s @code{libeufin-nexus} component
+implements a wire adapter towards the traditional SEPA banking
+system with IBAN accounts using the EBICS protocol.
 
 @item 
-For production, libeufin's Nexus component implements a wire
-adapter towards the traditional SEPA banking system with IBAN
-accounts.
+To use GNU Taler with blockchains, the `Depolymerization'
+component provides a wire gateway API that runs on top of
+blockchains like Bitcoin and Ethereum.
 @end enumerate
 
-The client-side wire adapter API is implemented in libtalerbank and
-is used by the transfer to execute wire transfers and for the
-auditor to query bank transaction histories.
+The client-side wire adapter API is implemented in `libtalerbank' and
+is used by @code{taler-exchange-transfer} to execute wire transfers and by
+@code{taler-exchange-wirewatch} and the Taler auditor auditor to query bank
+transaction histories.
 
 @item 
-DBMS
+`DBMS':
 The exchange requires a DBMS to stores the transaction history for
 the Taler exchange and aggregator, and a (typically separate) DBMS
 for the Taler auditor. For now, the GNU Taler reference implementation
@@ -354,7 +424,7 @@ support another DBMS.
 .. index:: PostgreSQL
 
 @item 
-Auditor
+`Auditor':
 The auditor verifies that the transactions performed by the exchange
 were done properly. It checks the various signatures, totals up the
 amounts and alerts the operator to any inconsistencies. It also
@@ -362,17 +432,49 @@ computes the expected bank balance, revenue and risk exposure of the
 exchange operator. The main binary is the @code{taler-auditor}.
 Aside from the key setup procedures, the most critical setup for
 deploying an auditor is providing the auditor with an up-to-date
-copy of the database.
+copy of the exchange’s database.
 @end itemize
 
-@node Offline keys,Online signing key security,Architecture overview,Introduction
-@anchor{taler-exchange-manual offline-keys}@anchor{7}
+@node Key Types,Offline keys,Architecture overview,Introduction
+@anchor{taler-exchange-manual key-types}@anchor{7}@anchor{taler-exchange-manual keytypes}@anchor{8}
+@section Key Types
+
+
+The exchange works with four types of keys:
+
+
+@itemize -
+
+@item 
+master key (kept offline, configured manually at merchants and wallets)
+
+@item 
+online message signing keys (signs normal messages from the exchange)
+
+@item 
+denomination keys (signs digital coins)
+
+@item 
+security module keys (signs online message signing keys and denomination keys)
+@end itemize
+
+Additionally, the exchange is sometimes concerned with the auditor’s public
+key (to verify messages signed by auditors approved by the exchange operator)
+and the merchant’s public key (to verify refunds are authorized by the
+merchant).
+
+Most of the keys are managed fully automatically or configured as part of the
+denomination configuration.  Some configuration settings must be manually
+set with regards to the exchange’s master key.
+
+@node Offline keys,Online signing key security,Key Types,Introduction
+@anchor{taler-exchange-manual offline-keys}@anchor{9}
 @section Offline keys
 
 
-The exchange (and ideally also auditors) uses a long-term offline master
+The exchange (and ideally also its auditor(s)) uses a long-term offline master
 siging key that identifies the operator and is used to authenticate critical
-information, such as the exchange's bank account and the actual keys the
+information, such as the exchange’s bank account and the actual keys the
 exchange uses online.
 
 Interactions with the offline system are performed using the
@@ -383,20 +485,20 @@ computing power, a Raspberry-Pi is perfectly sufficient and the form-factor
 might be good for safe-keeping! (You should keep a copy of the (encrypted)
 private offline key on more than one physical medium though.)
 
-Exchange operators are strongly advised to secure your private master key and
-any copies on encrypted, always-offline computers. Again, we assume that you
-are familiar with good best practices in operational security, including
-securing key material.
+Exchange operators are strongly advised to secure their private master key and
+any copies on encrypted, always-offline computers. Again, this manual assumes
+that you are familiar with good best practices in operational security,
+including securing key material.
 
 @node Online signing key security,,Offline keys,Introduction
-@anchor{taler-exchange-manual online-signing-key-security}@anchor{8}
+@anchor{taler-exchange-manual online-signing-key-security}@anchor{a}
 @section Online signing key security
 
 
-To provide an additional level of protection for the private @emph{online} signing
+To provide an additional level of protection for the private `online' signing
 keys used by the exchange, the actual cryptographic signing operations are
-performed by two helper processes, the @code{taler-exchange-secmod-rsa} and the
-@code{taler-exchange-secmod-eddsa}.
+performed by three helper processes, @code{taler-exchange-secmod-rsa},
+@code{taler-exchange-secmod-cs} and @code{taler-exchange-secmod-eddsa}.
 
 The current implementation does not yet support the use of a hardware security
 module (HSM).  If you have such a device with adequate functionality and are
@@ -412,12 +514,14 @@ integration support.
 @end menu
 
 @node Functionality,Security goals,,Online signing key security
-@anchor{taler-exchange-manual functionality}@anchor{9}
+@anchor{taler-exchange-manual functionality}@anchor{b}
 @subsection Functionality
 
 
-The UNIX domain sockets have mode 0620 (u+rw, g+w).  The exchange process
-MUST be in the same group as the crypto helper processes.
+The UNIX domain sockets of the `secmod' helpers have mode 0620 (u+rw, g+w).
+The exchange process MUST thus be in the same group as the crypto helper
+processes to enable access to the keys. No other users should be in that
+group!
 
 The two helper processes will create the required private keys, and allow
 anyone with access to the UNIX domain socket to sign arbitrary messages with
@@ -426,12 +530,12 @@ are also responsible for deleting the private keys if their validity period
 expires or if they are informed about a key having been revoked.
 
 @node Security goals,Setup,Functionality,Online signing key security
-@anchor{taler-exchange-manual security-goals}@anchor{a}
+@anchor{taler-exchange-manual security-goals}@anchor{c}
 @subsection Security goals
 
 
-From a security point of view, the helpers are designed to @emph{only} make it
-harder for an attacker who took control of the HTTP daemon's account to
+From a security point of view, the helpers are designed to `only' make it
+harder for an attacker who took control of the HTTP daemon’s account to
 extract the private keys, limiting the attackers ability to creating
 signatures to the duration of their control of that account.
 
@@ -443,54 +547,153 @@ to track the total number of signatures they have made for the various keys.
 @end cartouche
 
 @node Setup,Configuration,Security goals,Online signing key security
-@anchor{taler-exchange-manual setup}@anchor{b}
+@anchor{taler-exchange-manual setup}@anchor{d}
 @subsection Setup
 
 
 The helper processes should be run under a user ID that is separate from that
-of the user running the main @code{taler-exchange-httpd} service.  For security,
-it is important that helpers run under a different user ID than the main HTTP
-frontend, in fact ideally each helper should run under its own user ID.  The
-@code{taler-exchange-httpd} service's will securely communicate with the helpers
-using UNIX domain sockets.  To enable access to the keys, the service's user
-must be in the group of the helper processes (and no other users should be in
-that group).
+of the user running the main @code{taler-exchange-httpd} service.  To get any
+security benefit from this, it is important that helpers run under a different
+user ID than the main HTTP frontend. In fact, ideally, each helper should run
+under its own user ID.  The @code{taler-exchange-httpd} service’s will securely
+communicate with the helpers using UNIX domain sockets.
 
 @node Configuration,,Setup,Online signing key security
-@anchor{taler-exchange-manual configuration}@anchor{c}
+@anchor{taler-exchange-manual configuration}@anchor{e}
 @subsection Configuration
 
 
-The helpers and the HTTP service need both access to the same configuration
-information.  Having divergent configurations may result in run-time failures.
-It is recommended that the configuration file (@code{-c} option) is simply shared
-between all of the different processes, even though they run as different
-system users. The configuration does not contain any sensitive information.
+The helpers and the exchange HTTP service need both access to the same
+configuration information.  Having divergent configurations may result in
+run-time failures.  It is recommended that the configuration file (@code{-c}
+option) is simply shared between all of the different processes, even though
+they run as different system users. The configuration does not contain any
+sensitive information.
 
-@node Installation,Configuration<2>,Introduction,Top
-@anchor{taler-exchange-manual installation}@anchor{d}
+@node Installation,Configuration Fundamentals,Introduction,Top
+@anchor{taler-exchange-manual exchangeinstallation}@anchor{f}@anchor{taler-exchange-manual installation}@anchor{10}
 @chapter Installation
 
 
-Before installing a Taler exchange, please make sure that your
-system does not have swap space enabled.  Swap space is a security
-risk that Taler does not try to mitigate against.
+Before installing a Taler exchange, please make sure that your system does not
+have swap space enabled.  Swap space is a security risk that Taler does not
+try to mitigate against.
 
-Please install the following packages before proceeding with the
-exchange compilation.
+We recommend the setup of offline signing keys to be done on a second machine that
+does not have Internet access.
 
+In this guide’s shell-session fragments, the command prompt shows two pieces
+of information:
 
-@itemize -
+
+@itemize *
 
 @item 
-Python3 module @code{jinja2}
+Who is performing the command
+(@code{$user} vs @code{root}, and ending character @code{$} vs @code{#}).
+
+@item 
+Host where the command is supposed to be executed
+(@code{exchange-offline} vs @code{exchange-online}).
+It is possible to do the entire setup on one machine,
+but we do not recommend this for security reasons.
 @end itemize
 
+@menu
+* Before you start:: 
+* Installing from source:: 
+* Installing the GNU Taler binary packages on Debian:: 
+* Installing the GNU Taler binary packages on Trisquel:: 
+* Installing the GNU Taler binary packages on Ubuntu:: 
+* Services@comma{} users@comma{} groups and file system hierarchy: Services users groups and file system hierarchy. 
+
+@end menu
+
+@node Before you start,Installing from source,,Installation
+@anchor{taler-exchange-manual before-you-start}@anchor{11}
+@section Before you start
+
+
+To deploy this with a real bank, you need:
+
+@quotation
+
+
+@itemize *
+
+@item 
+IBAN of the bank account to use
+
+@item 
+BIC of the bank
+
+@item 
+EBICS host, user and partner IDs
+@end itemize
+@end quotation
+
+Information to write down during the installation:
+
+@quotation
+
+
+@itemize *
+
+@item 
+LibEuFin Nexus superuser password
+
+@item 
+Taler facade base URL
+
+@item 
+exchange Nexus username and password
+@end itemize
+@end quotation
+
+@node Installing from source,Installing the GNU Taler binary packages on Debian,Before you start,Installation
+@anchor{taler-exchange-manual installing-from-source}@anchor{12}
+@section Installing from source
+
+
+The following instructions will show how to install libgnunetutil and
+the GNU Taler exchange from source.
+
+The package sources can be find in our
+download directory@footnote{http://ftpmirror.gnu.org/taler/}.
+
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
+
+GNU Taler components version numbers follow the @code{MAJOR.MINOR.MICRO} format.
+The general rule for compatibility is that @code{MAJOR} and @code{MINOR} must match.
+Exceptions to this general rule are documented in the release notes.
+For example, Taler merchant 1.3.0 should be compatible with Taler exchange 1.4.x
+as the MAJOR version matches.  A MAJOR version of 0 indicates experimental
+development, and you are expected to always run all of the `latest' releases
+together (no compatibility guarantees).
+
+First, the following packages need to be installed before we can compile the
+backend:
+
 
 @itemize -
 
 @item 
-"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
+“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
 on Debian-based systems (for GNUnet documentation support, can be
 omitted if GNUnet is configured with @code{--disable-documentation})
 
@@ -504,10 +707,10 @@ GNU libunistring >= 0.9.3
 libcurl >= 7.26 (or libgnurl >= 7.26)
 
 @item 
-libqrencode >= 4.0.0
+libqrencode >= 4.0.0 (Taler merchant only)
 
 @item 
-GNU libgcrypt >= 1.6
+GNU libgcrypt >= 1.6 (1.10 or later highly recommended)
 
 @item 
 libsodium >= 1.0
@@ -525,32 +728,31 @@ PostgreSQL >= 13, including libpq
 GNU libmicrohttpd >= 0.9.71
 
 @item 
-GNUnet >= 0.16 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
+GNUnet >= 0.19 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
 
 @item 
-GNU Taler exchange (from download directory@footnote{http://ftpmirror.gnu.org/taler/},
-see release announcement@footnote{https://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=taler&idxname=info-gnu&max=20&result=normal&sort=date:late})
+Python3 with @code{jinja2}
 @end itemize
 
-Except for the last two, these are available in most GNU/Linux
-distributions and should just be installed using the respective package
-manager.
+If you are on Debian stable or later, the following command may help you
+install these dependencies:
 
-@menu
-* Installing from source:: 
-* Installing the GNU Taler binary packages on Debian:: 
-* Installing the GNU Taler binary packages on Trisquel:: 
-* Installing the GNU Taler binary packages on Ubuntu:: 
-
-@end menu
-
-@node Installing from source,Installing the GNU Taler binary packages on Debian,,Installation
-@anchor{taler-exchange-manual installing-from-source}@anchor{e}
-@section Installing from source
-
-
-The following instructions will show how to install libgnunetutil and
-the GNU Taler exchange from source.
+@example
+# apt-get install \
+  libqrencode-dev \
+  libsqlite3-dev \
+  libltdl-dev \
+  libunistring-dev \
+  libsodium-dev \
+  libargon2-dev \
+  libcurl4-gnutls-dev \
+  libgcrypt20-dev \
+  libjansson-dev \
+  libpq-dev \
+  libmicrohttpd-dev \
+  python3-jinja2 \
+  postgresql-13
+@end example
 
 Before you install GNUnet, you must download and install the dependencies
 mentioned in the previous section, otherwise the build may succeed, but could
@@ -574,6 +776,17 @@ The @code{ldconfig} command (also run as @code{root}) makes the
 shared object libraries (@code{.so} files)
 visible to the various installed programs.
 
+Please note that unlike most packages, if you want to run the @code{make check}
+command, you should run it only `after' having done @code{make install}.  The
+latter ensures that necessary binaries are copied to the right place.
+
+In any case, if @code{make check} fails, please consider filing a
+bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
+
+There is no need to actually run a GNUnet peer to use the Taler merchant
+backend – all the merchant needs from GNUnet is a number of headers and
+libraries!
+
 After installing GNUnet, unpack the GNU Taler exchange tarball,
 change into the resulting directory, and proceed as follows:
 
@@ -592,44 +805,41 @@ which requires you to run the last step as @code{root}.  You have to specify
 previous step.
 
 Please note that unlike most packages, if you want to run the @code{make check}
-command, you should run it only @emph{after} having done @code{make install}.  The
+command, you should run it only `after' having done @code{make install}.  The
 latter ensures that necessary binaries are copied to the right place.
 
-Gratuitous editorial note by TTN: I think this is a quirk that we should
-fix in the long-term as such weirdness might hide other build issues.
-However, this is probably a minority viewpoint.
-
 In any case, if @code{make check} fails, please consider filing a
 bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
 
 @node Installing the GNU Taler binary packages on Debian,Installing the GNU Taler binary packages on Trisquel,Installing from source,Installation
-@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-debian}@anchor{f}
+@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-debian}@anchor{13}
 @section Installing the GNU Taler binary packages on Debian
 
 
 To install the GNU Taler Debian packages, first ensure that you have
 the right Debian distribution. At this time, the packages are built for
-Bullseye.
+Debian bookworm.
 
 You need to add a file to import the GNU Taler packages. Typically,
 this is done by adding a file @code{/etc/apt/sources.list.d/taler.list} that
 looks like this:
 
 @example
-deb https://deb.taler.net/apt/debian bullseye main
+deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/debian stable main
 @end example
 
 Next, you must import the Taler Systems SA public package signing key
 into your keyring and update the package lists:
 
 @example
-# wget -O - https://taler.net/taler-systems.gpg.key | apt-key add -
+# wget -O /etc/apt/keyrings/taler-systems.gpg \
+    https://taler.net/taler-systems.gpg
 # apt update
 @end example
 
 @cartouche
 @quotation Note 
-You may want to verify the correctness of the Taler Systems key out-of-band.
+You may want to verify the correctness of the Taler Systems SA key out-of-band.
 @end quotation
 @end cartouche
 
@@ -639,7 +849,7 @@ using apt.
 To install the Taler exchange, you can now simply run:
 
 @example
-# apt install -t sid taler-exchange
+[root@@exchange-online]# apt install taler-exchange
 @end example
 
 Note that the package does not perform any configuration work except for
@@ -648,33 +858,38 @@ configure at least the database, HTTP reverse proxy (typically with TLS
 certificates), denomination and fee structure, bank account, auditor(s),
 offline signing and the terms of service.
 
-Sample configuration files for the HTTP reverse proxy can be found in
-@code{/etc/taler-exchange/}.
+On the offline system, you should run at least:
+
+@example
+[root@@exchange-offline]# apt install taler-exchange-offline
+@end example
 
 @node Installing the GNU Taler binary packages on Trisquel,Installing the GNU Taler binary packages on Ubuntu,Installing the GNU Taler binary packages on Debian,Installation
-@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-trisquel}@anchor{10}
+@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-trisquel}@anchor{14}
 @section Installing the GNU Taler binary packages on Trisquel
 
 
 To install the GNU Taler Trisquel packages, first ensure that you have
 the right Trisquel distribution. Packages are currently available for
 Trisquel GNU/Linux 10.0.  Simply follow the same instructions provided
-for Ubuntu 20.04 LTS (Focal Fossa).
+for Ubuntu.
 
-@node Installing the GNU Taler binary packages on Ubuntu,,Installing the GNU Taler binary packages on Trisquel,Installation
-@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-ubuntu}@anchor{11}
+@node Installing the GNU Taler binary packages on Ubuntu,Services users groups and file system hierarchy,Installing the GNU Taler binary packages on Trisquel,Installation
+@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-ubuntu}@anchor{15}
 @section Installing the GNU Taler binary packages on Ubuntu
 
 
 To install the GNU Taler Ubuntu packages, first ensure that you have
 the right Ubuntu distribution. At this time, the packages are built for
-Ubuntu 22.04 LTS (Jammy Jellyfish).
+Ubuntu Kinetic and Ubuntu Jammy. Make sure to have @code{universe} in your
+@code{/etc/apt/sources.list} (after @code{main}) as we depend on some packages
+from Ubuntu @code{universe}.
 
 A typical @code{/etc/apt/sources.list.d/taler.list} file for this setup
 would look like this:
 
 @example
-deb https://deb.taler.net/apt/ubuntu/ jammy main
+deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ stable main
 @end example
 
 The last line is crucial, as it adds the GNU Taler packages.
@@ -683,8 +898,8 @@ Next, you must import the Taler Systems SA public package signing key
 into your keyring and update the package lists:
 
 @example
-# wget -O /etc/apt/trusted.gpg.d/taler-systems.asc \
-    https://taler.net/taler-systems.gpg.key
+# wget -O /etc/apt/keyrings/taler-systems.gpg \
+    https://taler.net/taler-systems.gpg
 # apt update
 @end example
 
@@ -700,7 +915,7 @@ using apt.
 To install the Taler exchange, you can now simply run:
 
 @example
-# apt install -t focal-fossa taler-exchange
+[root@@exchange-online]# apt install taler-exchange
 @end example
 
 Note that the package does not perform any configuration work except for
@@ -709,48 +924,205 @@ configure at least the database, HTTP reverse proxy (typically with TLS
 certificates), denomination and fee structure, bank account, auditor(s),
 offline signing and the terms of service.
 
-Sample configuration files for the HTTP reverse proxy can be found in
-@code{/etc/taler-exchange/}.
+On the offline system, you should run at least:
+
+@example
+[root@@exchange-offline]# apt install taler-exchange-offline
+@end example
+
+@node Services users groups and file system hierarchy,,Installing the GNU Taler binary packages on Ubuntu,Installation
+@anchor{taler-exchange-manual services-users-groups-and-file-system-hierarchy}@anchor{16}
+@section Services, users, groups and file system hierarchy
+
+
+The `taler-exchange' package will create several system users
+to compartmentalize different parts of the system:
+
+
+@itemize *
+
+@item 
+@code{taler-exchange-httpd}: runs the HTTP daemon with the core business logic.
+
+@item 
+@code{taler-exchange-secmod-rsa}: manages the RSA private online signing keys.
+
+@item 
+@code{taler-exchange-secmod-cs}: manages the CS private online signing keys.
+
+@item 
+@code{taler-exchange-secmod-eddsa}: manages the EdDSA private online signing keys.
+
+@item 
+@code{taler-exchange-closer}: closes idle reserves by triggering wire transfers that refund the originator.
+
+@item 
+@code{taler-exchange-aggregator}: aggregates deposits into larger wire transfer requests.
+
+@item 
+@code{taler-exchange-transfer}: performs wire transfers with the bank (via LibEuFin/Nexus).
+
+@item 
+@code{taler-exchange-wirewatch}: checks for incoming wire transfers with the bank (via LibEuFin/Nexus).
+
+@item 
+@code{postgres}: runs the PostgreSQL database (from `postgresql' package).
+
+@item 
+@code{www-data}: runs the frontend HTTPS service with the TLS keys (from `nginx' package).
+@end itemize
+
+@cartouche
+@quotation Note 
+The `taler-merchant' package additionally creates a @code{taler-merchant-httpd} user
+to run the HTTP daemon with the merchant business logic.
+@end quotation
+@end cartouche
+
+The exchange setup uses the following system groups:
 
-@node Configuration<2>,Deployment,Installation,Top
-@anchor{taler-exchange-manual id1}@anchor{12}
-@chapter Configuration
 
+@itemize *
+
+@item 
+@code{taler-exchange-db}: group for all Taler users with direct database access, specifically taler-exchange-httpd, taler-exchange-wire, taler-exchange-closer and taler-exchange-aggregator.
 
-This chapter provides an overview of the exchange configuration. Or at
-least eventually will do so, for now it is a somewhat wild description
-of some of the options.
+@item 
+@code{taler-exchange-secmod}: group for processes with access to online signing keys; this group must have four users: taler-exchange-secmod-rsa, taler-exchange-secmod-cs, taler-exchange-secmod-eddsa and taler-exchange-httpd.
+
+@item 
+@code{taler-exchange-offline}: group for the access to the offline private key (only used on the offline host and not used on the online system).
+@end itemize
+
+The package will deploy systemd service files in
+@code{/usr/lib/systemd/system/} for the various components:
+
+
+@itemize *
+
+@item 
+@code{taler-exchange-aggregator.service}: service that schedules wire transfers
+which combine multiple deposits to the same merchant.
+
+@item 
+@code{taler-exchange-closer.service}: service that watches for reserves that have been abandoned and schedules wire transfers to send the money back to the originator.
+
+@item 
+@code{taler-exchange-httpd.service}: main Taler exchange logic with the public REST API.
+
+@item 
+@code{taler-exchange-httpd.socket}: systemd socket activation for the Taler exchange HTTP daemon.
+
+@item 
+@code{taler-exchange-secmod-eddsa.service}: software security module for making EdDSA signatures.
+
+@item 
+@code{taler-exchange-secmod-rsa.service}: software security module for making RSA signatures.
+
+@item 
+@code{taler-exchange-secmod-cs.service}: software security module for making CS signatures.
+
+@item 
+@code{taler-exchange-transfer.service}: service that triggers outgoing wire transfers (pays merchants).
+
+@item 
+@code{taler-exchange-wirewatch.service}: service that watches for incoming wire transfers (first step of withdraw).
+
+@item 
+@code{taler-exchange.target}: Main target for the Taler exchange to be operational.
+@end itemize
+
+The deployment creates the following key locations in the system:
+
+
+@itemize *
+
+@item 
+@code{/etc/taler/}: configuration files.
+
+@item 
+@code{/run/taler/}: contains the UNIX domain sockets for inter-process communication (IPC).
+
+@item 
+@code{/var/lib/taler/}: serves as the $HOME for all Taler users and contains sub-directories
+with the private keys; which keys are stored here depends on the host:
+
+
+@itemize *
+
+@item 
+online system: exchange-secmod-eddsa, exchange-secmod-cs and exchange-secmod-rsa keys.
+
+@item 
+offline system: exchange-offline keys.
+@end itemize
+@end itemize
+
+@node Configuration Fundamentals,Exchange Database Setup,Installation,Top
+@anchor{taler-exchange-manual configuration-fundamentals}@anchor{17}
+@chapter Configuration Fundamentals
+
+
+This chapter provides fundamental details about the exchange configuration.
+
+The configuration for all Taler components uses a single configuration file
+as entry point: @code{/etc/taler/taler.conf}.
+
+System defaults are automatically loaded from files in
+@code{/usr/share/taler/config.d}.  These default files should never be modified.
+
+The default configuration @code{taler.conf} configuration file also includes all
+configuration files in @code{/etc/taler/conf.d}.  The settings from files in
+@code{conf.d} are only relevant to particular components of Taler, while
+@code{taler.conf} contains settings that affect all components.
+
+The directory @code{/etc/taler/secrets} contains configuration file snippets with
+values that should only be readable to certain users.  They are included with the @code{@@inline-secret@@}
+directive and should end with @code{.secret.conf}.
+
+To view the entire configuration annotated with the source of each configuration option, you
+can use the @code{taler-config} helper:
+
+@example
+[root@@exchange-online]# taler-config --diagnostics
+< ... annotated, full configuration ... >
+@end example
+
+@cartouche
+@quotation Warning 
+While @code{taler-config} also supports rewriting configuration files, we strongly
+recommend to edit configuration files manually, as @code{taler-config} does not
+preserve comments and, by default, rewrites @code{/etc/taler/taler.conf}.
+@end quotation
+@end cartouche
 
 @menu
 * Configuration format:: 
 * Using taler-config:: 
-* Keying:: 
-* Serving:: 
-* Currency:: 
-* Database:: 
-* Coins (denomination keys): Coins denomination keys. 
-* Sign keys:: 
-* Terms of Service:: 
-* Bank account:: 
-* Auditor configuration:: 
 
 @end menu
 
-@node Configuration format,Using taler-config,,Configuration<2>
-@anchor{taler-exchange-manual configuration-format}@anchor{13}
+@node Configuration format,Using taler-config,,Configuration Fundamentals
+@anchor{taler-exchange-manual configuration-format}@anchor{18}
 @section Configuration format
 
 
-In Taler realm, any component obeys to the same pattern to get
-configuration values. According to this pattern, once the component has
-been installed, the installation deploys default values in
-$@{prefix@}/share/taler/config.d/, in .conf files. In order to override
-these defaults, the user can write a custom .conf file and either pass
-it to the component at execution time, or name it taler.conf and place
-it under $HOME/.config/.
+All GNU Taler components are designed to possibly share the same
+configuration files.  When installing a GNU Taler component, the
+installation deploys default values in configuration files located
+at $@{prefix@}/share/taler/config.d/ where $@{prefix@} is the installation
+prefix. Different components must be installed to the same prefix.
+
+In order to override these defaults, the user can write a custom configuration
+file and either pass it to the component at execution time using the `-c'
+option, or name it taler.conf and place it under $HOME/.config/ which is where
+components will look by default. Note that the systemd service files pass @code{-c
+/etc/taler.conf}, thus making @code{/etc/taler.conf} the primary location for
+the configuration.
 
 A config file is a text file containing sections, and each section
-contains its values. The right format follows:
+contains maps options to their values.  Configuration files follow
+basically the INI syntax:
 
 @example
 [section1]
@@ -762,14 +1134,23 @@ value21 = string
 value22 = /path22
 @end example
 
-Throughout any configuration file, it is possible to use @code{$}-prefixed
-variables, like @code{$VAR}, especially when they represent filesystem
-paths. It is also possible to provide defaults values for those
+Comments start with a hash (@code{#}).  Throughout the configuration, it is
+possible to use @code{$}-substitution for options relating to names of files or
+directories. It is also possible to provide defaults values for those
 variables that are unset, by using the following syntax:
-@code{$@{VAR:-default@}}. However, there are two ways a user can set
-@code{$}-prefixable variables:
+@code{$@{VAR:-default@}}. There are two ways a user can set the value
+of @code{$}-prefixable variables:
+
+@quotation
+
+
+@enumerate 
+
+@item 
+by defining them under a @code{[paths]} section:
+@end enumerate
 
-by defining them under a @code{[paths]} section, see example below,
+@quotation
 
 @example
 [paths]
@@ -778,47 +1159,43 @@ TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
 [section-x]
 path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
 @end example
+@end quotation
+
+
+@enumerate 2
 
+@item 
 or by setting them in the environment:
+@end enumerate
+
+@quotation
 
 @example
 $ export VAR=/x
 @end example
+@end quotation
+@end quotation
 
 The configuration loader will give precedence to variables set under
-@code{[path]}, though.
+@code{[path]} over environment variables.
 
-The utility @code{taler-config}, which gets installed along with the
-exchange, serves to get and set configuration values without directly
-editing the .conf. The option @code{-f} is particularly useful to resolve
+The utility @code{taler-config}, which gets installed along with the exchange,
+can be used get and set configuration values without directly editing the
+configuration file. The option @code{-f} is particularly useful to resolve
 pathnames, when they use several levels of @code{$}-expanded variables. See
 @code{taler-config --help}.
 
-Note that, in this stage of development, the file
-@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
-component. For example, both an exchange and a bank can read values from
-it.
-
-The repository @code{git://taler.net/deployment} contains examples of
-configuration file used in our demos. See under @code{deployment/config}.
-
-@quotation
-
-@strong{Note}
-
-Expectably, some components will not work just by using default
-values, as their work is often interdependent. For example, a
-merchant needs to know an exchange URL, or a database name.
-@end quotation
+The repository @code{git://git.taler.net/deployment} contains example code
+for generating configuration files under @code{deployment/netzbon/}.
 
-@node Using taler-config,Keying,Configuration format,Configuration<2>
-@anchor{taler-exchange-manual using-taler-002dconfig-exchange}@anchor{14}@anchor{taler-exchange-manual using-taler-config}@anchor{15}
+@node Using taler-config,,Configuration format,Configuration Fundamentals
+@anchor{taler-exchange-manual using-taler-002dconfig-exchange}@anchor{19}@anchor{taler-exchange-manual using-taler-config}@anchor{1a}
 @section Using taler-config
 
 
-The tool @code{taler-config} can be used to extract or manipulate
-configuration values; however, the configuration use the well-known INI
-file format and can also be edited by hand.
+The tool @code{taler-config} can be used to extract or manipulate configuration
+values; however, the configuration use the well-known INI file format and is
+generally better edited by hand to preserve comments and structure.
 
 Run
 
@@ -831,20 +1208,20 @@ to list all of the configuration values in section @code{$SECTION}.
 Run
 
 @example
-$ taler-config -s $section -o $option
+$ taler-config -s $SECTION -o $OPTION
 @end example
 
-to extract the respective configuration value for option @code{$option} in
-section @code{$section}.
+to extract the respective configuration value for option @code{$OPTION} in
+section @code{$SECTION}.
 
 Finally, to change a setting, run
 
 @example
-$ taler-config -s $section -o $option -V $value
+$ taler-config -s $SECTION -o $OPTION -V $VALUE
 @end example
 
-to set the respective configuration value to @code{$value}. Note that you
-have to manually restart the Taler backend after you change the
+to set the respective configuration value to @code{$VALUE}. Note that you
+have to manually restart affected Taler components after you change the
 configuration to make the new configuration go into effect.
 
 Some default options will use $-variables, such as @code{$DATADIR} within
@@ -853,152 +1230,191 @@ configuration, pass the @code{-f} option to @code{taler-config}. For example,
 compare:
 
 @example
-$ taler-config -s ACCOUNT-bank \
-               -o WIRE_RESPONSE
-$ taler-config -f -s ACCOUNT-bank \
-               -o WIRE_RESPONSE
+$ taler-config --section exchange-offline --option MASTER_PRIV_FILE
+$ taler-config -f --section exchange-offline --option MASTER_PRIV_FILE
 @end example
 
 While the configuration file is typically located at
-@code{$HOME/.config/taler.conf}, an alternative location can be specified
-to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
-option.
+@code{$HOME/.config/taler.conf}, an alternative location can be specified to any
+GNU Taler component using the @code{-c} option.
 
-@node Keying,Serving,Using taler-config,Configuration<2>
-@anchor{taler-exchange-manual id2}@anchor{16}@anchor{taler-exchange-manual keying}@anchor{17}
-@section Keying
+@node Exchange Database Setup,Basic Setup Currency Denominations and Keys,Configuration Fundamentals,Top
+@anchor{taler-exchange-manual exchange-database-setup}@anchor{1b}
+@chapter Exchange Database Setup
 
 
-The exchange works with four types of keys:
+The access credentials for the exchange’s database are configured in
+@code{/etc/taler/secrets/exchange-db.secret.conf}.  Currently, only PostgreSQL is
+supported as a database backend.
 
+The following users must have access to the exchange database:
 
-@itemize -
 
-@item 
-master key (kept offline)
+@itemize *
 
-To create a master key, use:
-
-@example
-$ taler-exchange-offline setup
-@end example
+@item 
+taler-exchange-httpd
 
 @item 
-sign keys (signs normal messages from the exchange)
+taler-exchange-wire
 
 @item 
-denomination keys (signs electronic coins, see section Coins)
+taler-exchange-aggregator
 
 @item 
-security module keys (signs sign keys and denomination keys)
+taler-exchange-closer
 @end itemize
 
-Additionally, the exchange is sometimes concerned with the auditor's public
-key (to verify messages signed by auditors approved by the exchange operator)
-and the merchant's public key (to verify refunds are authorized by the
-merchant).
+These users are all in the taler-exchange-db group, and the
+@code{exchange-db.secret.conf} should be only readable by users in
+this group.
 
-Key options include:
+@cartouche
+@quotation Note 
+The `taler-exchange-dbconfig' tool can be used to automate the database
+setup. When using the Debian/Ubuntu packages, the users should already have
+been created, so you can just run the tool without any arguments and should
+have a working database configuration. The rest of this section only
+explains what the `taler-exchange-dbconfig' shell script fully automates.
+@end quotation
+@end cartouche
 
+To create a database for the Taler exchange on the local system, run:
 
-@itemize -
+@example
+[root@@exchange-online]# su - postgres
+[postgres@@exchange-online]# createuser taler-exchange-httpd
+[postgres@@exchange-online]# createuser taler-exchange-wire
+[postgres@@exchange-online]# createuser taler-exchange-aggregator
+[postgres@@exchange-online]# createuser taler-exchange-closer
+[postgres@@exchange-online]# createdb -O taler-exchange-httpd taler-exchange
+[postgres@@exchange-online]# exit
+@end example
 
-@item 
-@code{[exchange-offline/MASTER_PRIV_FILE]}: Path to the exchange’s master private file.  Only needs to be provided on the offline system where the @code{taler-exchange-offline} command is used.
+This will create a @code{taler-exchange} database owned by the
+@code{taler-exchange-httpd} user.  We will use that user later to perform
+database maintenance operations.
 
-@item 
-@code{[exchange/MASTER_PUBLIC_KEY]}: Must specify the exchange’s master public key.  Needed for the exchange to verify information signed by the offline system.
-@end itemize
+Assuming the above database setup, the database credentials to configure
+in the configuration file would simply be:
 
-@node Serving,Currency,Keying,Configuration<2>
-@anchor{taler-exchange-manual id3}@anchor{18}@anchor{taler-exchange-manual serving}@anchor{19}
-@section Serving
 
+@float LiteralBlock
 
-The exchange can serve HTTP over both TCP and UNIX domain socket.
-
-The following options are to be configured in the section @code{[exchange]}:
+@caption{/etc/taler/secrets/exchange-db.secret.conf}
 
+@example
+[exchange]
+DB = postgres
 
-@itemize -
+[exchangedb-postgres]
+CONFIG=postgres:///taler-exchange
+@end example
 
-@item 
-@code{SERVE}: Must be set to @code{tcp} to serve HTTP over TCP, or @code{unix} to serve
-HTTP over a UNIX domain socket.
+@end float
 
-@item 
-@code{PORT}: Set to the TCP port to listen on if @code{SERVE} is @code{tcp}.
 
-@item 
-@code{UNIXPATH}: Set to the UNIX domain socket path to listen on if @code{SERVE} is
-@code{unix}.
+If the database is run on a different host, please follow the instructions
+from the PostgreSQL manual for configuring remote access.
 
-@item 
-@code{UNIXPATH_MODE}: Number giving the mode with the access permission mask
-for the @code{UNIXPATH} (i.e. 660 = @code{rw-rw---}).
-@end itemize
+After configuring the database credentials, the exchange database needs
+to be initialized with the following command:
 
-@node Currency,Database,Serving,Configuration<2>
-@anchor{taler-exchange-manual currency}@anchor{1a}@anchor{taler-exchange-manual id4}@anchor{1b}
-@section Currency
+@example
+[root@@exchange-online]# sudo -u taler-exchange-httpd taler-exchange-dbinit
+
+..note::
+
+  To run this command, the user must have `@w{`}CREATE TABLE`@w{`}, `@w{`}CREATE
+  INDEX`@w{`}, `@w{`}ALTER TABLE`@w{`} and (in the future possibly even) `@w{`}DROP TABLE`@w{`}
+  permissions.  Those permissions are only required for this step (which may
+  have to be repeated when upgrading a deployment).  Afterwards, during
+  normal operation, permissions to `@w{`}CREATE`@w{`} or `@w{`}ALTER`@w{`} tables are not
+  required by any of the Taler exchange processes and thus should not be
+  granted.  For more information, see
+  :doc:`manpages/taler-exchange-dbinit.1`.
+@end example
 
+Finally we need to grant the other accounts limited access:
 
-The exchange supports only one currency. This data is set under the
-respective option @code{CURRENCY} in section @code{[taler]}.
+@example
+[root@@exchange-online]# sudo -u taler-exchange-httpd bash
+[taler-exchange-httpd@@exchange-online]# echo 'GRANT SELECT,INSERT,UPDATE ON ALL TABLES IN SCHEMA exchange TO "taler-exchange-aggregator";' \
+  | psql taler-exchange
+[taler-exchange-httpd@@exchange-online]# echo 'GRANT SELECT,INSERT,UPDATE ON ALL TABLES IN SCHEMA exchange TO "taler-exchange-closer";' \
+  | psql taler-exchange
+[taler-exchange-httpd@@exchange-online]# echo 'GRANT SELECT,INSERT,UPDATE ON ALL TABLES IN SCHEMA exchange TO "taler-exchange-wire";' \
+  | psql taler-exchange
+[taler-exchange-httpd@@exchange-online]# echo 'GRANT USAGE ON ALL SEQUENCES IN SCHEMA exchange TO "taler-exchange-aggregator";' \
+  | psql taler-exchange
+[taler-exchange-httpd@@exchange-online]# echo 'GRANT USAGE ON ALL SEQUENCES IN SCHEMA exchange TO "taler-exchange-closer";' \
+  | psql taler-exchange
+[taler-exchange-httpd@@exchange-online]# echo 'GRANT USAGE ON ALL SEQUENCES IN SCHEMA exchange TO "taler-exchange-wire";' \
+  | psql taler-exchange
+[taler-exchange-httpd@@exchange-online]# exit
+@end example
 
-@node Database,Coins denomination keys,Currency,Configuration<2>
-@anchor{taler-exchange-manual database}@anchor{1c}@anchor{taler-exchange-manual id5}@anchor{1d}
-@section Database
+@cartouche
+@quotation Note 
+The above instructions for changing database permissions only work `after'
+having initialized the database with @code{taler-exchange-dbinit}, as
+the tables need to exist before permissions can be granted on them. The
+@code{taler-exchange-dbinit} tool cannot setup these permissions, as it
+does not know which users will be used for which processes.
+@end quotation
+@end cartouche
 
+@node Basic Setup Currency Denominations and Keys,Wire Gateway Setup,Exchange Database Setup,Top
+@anchor{taler-exchange-manual basic-setup-currency-denominations-and-keys}@anchor{1c}
+@chapter Basic Setup: Currency, Denominations and Keys
 
-The option @code{DB} in section @code{[exchange]} gets the database backend’s name the
-exchange is going to use. So far, only @code{db = postgres} is supported. After
-choosing the backend, it is mandatory to supply the connection string
-(namely, the database name). This is possible in two ways:
 
+A Taler exchange only supports a single currency.  The currency
+and the smallest currency unit supported by the bank system
+must be specified in @code{/etc/taler/taler.conf}.
 
-@itemize -
 
-@item 
-via an environment variable: @code{TALER_EXCHANGEDB_POSTGRES_CONFIG}.
+@float LiteralBlock
 
-@item 
-via configuration option @code{CONFIG}, under section @code{[exchangedb-$BACKEND]}.
-For example, the demo exchange is configured as follows:
-@end itemize
+@caption{/etc/taler/taler.conf}
 
 @example
-[exchange]
-...
-DB = postgres
-...
+ [taler]
+ CURRENCY = EUR
+ CURRENCY_ROUND_UNIT = EUR:0.01
 
-[exchangedb-postgres]
-CONFIG = postgres:///talerdemo
+ # ... rest of file ...
 @end example
 
-Given this database configuration, the database can be initialized using:
+@end float
 
-@example
-$ taler-exchange-dbinit
-@end example
 
-Note that to run this command, the user must have @code{CREATE TABLE}, @code{CREATE
-INDEX}, @code{ALTER TABLE} and (in the future possibly even) @code{DROP TABLE}
-permissions.  Those permissions are only required for this step (which may
-have to be repeated when upgrading a deployment).  Afterwards, during normal
-operation, permissions to @code{CREATE} or @code{ALTER} tables are not required by
-any of the Taler exchange processes and thus should not be granted.
-For more information, see manpages/taler-exchange-dbinit.1.
+@cartouche
+@quotation Warning 
+@quotation
 
-Commands, like @code{taler-exchange-dbinit}, that support the @code{-l LOGFILE}
-command-line option, send logging output to standard error by default.
+When editing @code{/etc/taler/taler.conf}, take care to not accidentally remove
+the @code{@@inline-matching@@} directive to include the configuration files in @code{conf.d}.
+@end quotation
+@anchor{taler-exchange-manual coins-denomination-keys}@anchor{1d}
+@end quotation
+@end cartouche
 
-@node Coins denomination keys,Sign keys,Database,Configuration<2>
-@anchor{taler-exchange-manual coins-denomination-keys}@anchor{1e}@anchor{taler-exchange-manual id6}@anchor{1f}
+@menu
+* Coins (denomination keys): Coins denomination keys. 
+* Sign keys:: 
+* Setting up the offline signing key:: 
+
+@end menu
+
+@node Coins denomination keys,Sign keys,,Basic Setup Currency Denominations and Keys
+@anchor{taler-exchange-manual id1}@anchor{1e}
 @section Coins (denomination keys)
 
 
+Next, the electronic cash denominations that the exchange offers must be
+specified.
+
 Sections specifying denomination (coin) information start with @code{coin_}.  By
 convention, the name continues with @code{$CURRENCY_[$SUBUNIT]_$VALUE_$REVISION},
 i.e. @code{[coin_eur_ct_10_0]} for a 10 cent piece. However, only the @code{coin_}
@@ -1012,7 +1428,7 @@ must then have the following options:
 
 @item 
 @code{VALUE}: How much is the coin worth, the format is
-CURRENCY:VALUE.FRACTION. For example, a 10 cent piece is "EUR:0.10".
+CURRENCY:VALUE.FRACTION. For example, a 10 cent piece is “EUR:0.10”.
 
 @item 
 @code{DURATION_WITHDRAW}: How long can a coin of this type be withdrawn?
@@ -1043,11 +1459,25 @@ the same format as value.
 Specified using the same format as value.
 
 @item 
+@code{CIPHER}: Which cipher to use for this coin? Must be either @code{RSA} or
+@code{CS}.
+
+@item 
 @code{RSA_KEYSIZE}: How many bits should the RSA modulus (product of the two
 primes) have for this type of coin.
+
+@item 
+
+@table @asis
+
+@item @code{AGE_RESTRICTED}: Set to @code{YES} to make this a denomination with support
+
+for age restrictions. See age restriction extension below for details.
+This option is optional and defaults to @code{NO}.
+@end table
 @end itemize
 
-See manpages/taler.conf.5 for information on @emph{duration} values
+See manpages/taler.conf.5 for information on `duration' values
 (i.e. @code{DURATION_WITHDRAW} and @code{DURATION_SPEND} above,
 and @code{OVERLAP_DURATION} and @code{DURATION} below).
 Additionally, there are two global configuration options of note:
@@ -1088,8 +1518,26 @@ to the same configuration file!
 @end quotation
 @end cartouche
 
-@node Sign keys,Terms of Service,Coins denomination keys,Configuration<2>
-@anchor{taler-exchange-manual id7}@anchor{20}@anchor{taler-exchange-manual sign-keys}@anchor{21}
+The @code{taler-wallet-cli} has a helper command that generates a
+reasonable denomination structure.
+
+@example
+[root@@exchange-online]# taler-wallet-cli deployment gen-coin-config \
+                          --min-amount EUR:0.01 \
+                          --max-amount EUR:100 \
+                          > /etc/taler/conf.d/exchange-coins.conf
+@end example
+
+You can manually review and edit the generated configuration file. The main
+change that is possibly required is updating the various fees.  Note that you
+MUST NOT edit a coin configuration section after the initial setup. If you
+must @code{change} the values, you must instead create a new section with a
+different unique name (still with the @code{coin-} prefix) and comment out or
+remove the existing section.  Do take care to not introduce the name of the
+disabled section again in the future.
+
+@node Sign keys,Setting up the offline signing key,Coins denomination keys,Basic Setup Currency Denominations and Keys
+@anchor{taler-exchange-manual id2}@anchor{1f}@anchor{taler-exchange-manual sign-keys}@anchor{20}
 @section Sign keys
 
 
@@ -1126,96 +1574,490 @@ delayed.
 @end quotation
 @end cartouche
 
-@node Terms of Service,Bank account,Sign keys,Configuration<2>
-@anchor{taler-exchange-manual terms-of-service}@anchor{22}
-@section Terms of Service
+@node Setting up the offline signing key,,Sign keys,Basic Setup Currency Denominations and Keys
+@anchor{taler-exchange-manual offlineconfiguration}@anchor{21}@anchor{taler-exchange-manual setting-up-the-offline-signing-key}@anchor{22}
+@section Setting up the offline signing key
 
 
-The exchange has an endpoint "/terms" to return the terms of service
-(in legal language) of the exchange operator.  The wallet will show
-those terms of service to the user when the user is first withdrawing
-coins.  Terms of service are optional for experimental deployments,
-if none are configured, the exchange will return a simple statement
-saying that there are no terms of service available.
+Before launching an exchange, the offline signing (master) key must be
+generated and set in the configuration.  The offline signing keys of the
+exchange should be stored on a different machine.  The responsibilities of
+this offline signing machine are:
 
-To configure the terms of service response, there are two options
-in the @code{[exchange]} section:
+
+@itemize *
+
+@item 
+Generation of the exchange’s offline master signing key.
+
+@item 
+Secure storage of the exchange’s offline master signing key.
+
+@item 
+Generation of certificates (signed with the offline master signing key) that will be imported by the exchange.
+
+@item 
+Revocation of keys when the online system was compromised or is being terminated
+@end itemize
+
+Configuration file options related to the master key are:
 
 
 @itemize -
 
 @item 
-@code{TERMS_ETAG}: The current "Etag" to return for the terms of service.
-This value must be changed whenever the terms of service are
-updated. A common value to use would be a version number.
-Note that if you change the @code{TERMS_ETAG}, you MUST also provide
-the respective files in @code{TERMS_DIR} (see below).
+
+@table @asis
+
+@item @code{[exchange-offline/MASTER_PRIV_FILE]}: Path to the exchange’s master
+
+private file.  Only needs to be provided on the offline system where the
+@code{taler-exchange-offline} command is used.  The default value is usually
+fine and does not require adjustment.
+@end table
 
 @item 
-@code{TERMS_DIR}: The directory that contains the terms of service.
-The files in the directory must be readable to the exchange
-process.
+
+@table @asis
+
+@item @code{[exchange/MASTER_PUBLIC_KEY]}: Must specify the exchange’s master public
+
+key.  Needed for the exchange to verify information signed by the offline
+system.  This value must almost always be set explicitly by hand.
+@end table
 @end itemize
 
-The @code{TERMS_DIR} directory structure must follow a particular layout.
-First, inside of @code{TERMS_DIR}, there should be sub-directories using
-two-letter language codes like "en", "de", or "jp".  Each of these
-directories would then hold translations of the current terms of
-service into the respective language.  Empty directories are
-permitted in case translations are not available.
+@example
+[root@@exchange-offline]# taler-exchange-offline setup
+< ... prints the exchange master public key >
+@end example
+
+The public key printed as the output of this command must be put into the
+configuration of the online machine:
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-business.conf}
+
+@example
+ [exchange]
+ MASTER_PUBLIC_KEY = YE6Q6TR1ED...
+
+ # ... rest of file ...
+@end example
+
+@end float
+
+
+@node Wire Gateway Setup,Legal Setup,Basic Setup Currency Denominations and Keys,Top
+@anchor{taler-exchange-manual wire-gateway-setup}@anchor{23}
+@chapter Wire Gateway Setup
+
+
+The Taler Wire Gateway is an API that connects the Taler exchange to
+the underlying core banking system.
+
+LibEuFin is an implementation of the Wire Gateway API for the EBICS protocol.
+This section will walk through (1) installing and configuring LibEuFin and
+(2) connecting the Taler Exchange to LibEuFin.
 
-Then, inside each language directory, files with the name of the
-value set as the @code{TERMS_ETAG} must be provided. The extension of
-each of the files should be typical for the respective mime type.
-The set of supported mime types is currently hard-coded in the
-exchange, and includes HTML, PDF and TXT files. If other files are
-present, the exchange may show a warning on startup.
+@cartouche
+@quotation Note 
+If you do not have a bank account with EBICS but want to test these instructions,
+you can use the EBICS sandbox as described in the
+LibEuFin Tutorial.
+@end quotation
+@end cartouche
 
 @menu
-* Example:: 
+* Installation and Basic Configuration:: 
+* Connecting Nexus with an EBICS account:: 
+* Exchange Bank Account Configuration:: 
 
 @end menu
 
-@node Example,,,Terms of Service
-@anchor{taler-exchange-manual example}@anchor{23}
-@subsection Example
+@node Installation and Basic Configuration,Connecting Nexus with an EBICS account,,Wire Gateway Setup
+@anchor{taler-exchange-manual installation-and-basic-configuration}@anchor{24}
+@section Installation and Basic Configuration
 
 
-A sample file structure for a @code{TERMS_ETAG} of "v1" would be:
+First, install the @code{libeufin} package.  This can be done on the @code{exchange-online}
+machine or a different one.
 
+@example
+[root@@exchange-online]# apt-get install -y libeufin
+@end example
 
-@itemize -
+The main component of LibEuFin is called the Nexus.  It implements a Web
+service that provides a JSON abstraction layer to access bank accounts.
 
-@item 
-TERMS_DIR/en/v1.txt
+The HTTP port and database connection string can be edited in the configuration:
 
-@item 
-TERMS_DIR/en/v1.html
 
-@item 
-TERMS_DIR/en/v1.pdf
+@float LiteralBlock
 
-@item 
-TERMS_DIR/de/v1.txt
+@caption{/etc/libeufin/nexus.env}
 
-@item 
-TERMS_DIR/de/v1.html
+@example
+LIBEUFIN_NEXUS_PORT=5017
+LIBEUFIN_NEXUS_DB_CONNECTION=jdbc:sqlite:/var/lib/libeufin/nexus/nexus-db.sqlite3
+@end example
 
-@item 
-TERMS_DIR/de/v1.pdf
+@end float
 
-@item 
-TERMS_DIR/fr/v1.pdf
-@end itemize
 
-If the user requests an HTML format with language preferences "fr" followed by "en",
-the exchange would return @code{TERMS_DIR/en/v1.html} lacking an HTML version in
-French.
+After configuring the database, you can start the service.
+The database is initialized automatically.
+
+@example
+[root@@exchange-online]# systemctl enable libeufin-nexus
+[root@@exchange-online]# systemctl start libeufin-nexus
+@end example
+
+You can now create a superuser account.  The command to
+create the superuser needs direct database access, thus
+the configuration file is sourced first, and the relevant
+environment variable is exported.
+
+@example
+[root@@exchange-online]# source /etc/libeufin/nexus.env
+[root@@exchange-online]# export LIBEUFIN_NEXUS_DB_CONNECTION
+[root@@exchange-online]# NEXUS_ADMIN_PW=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 13)
+[root@@exchange-online]# libeufin-nexus superuser admin --password $NEXUS_ADMIN_PW
+@end example
+
+If you omit @code{--password $NEXUS_ADMIN_PW}, you will interactively be asked for a password.
+For simplicity, a superuser can as well act as a normal user, but an API
+to create less privileged users is offered.
+
+@cartouche
+@quotation Note 
+User and permissions management in LibEuFin is still under development.
+In particular, permissions for non-superusers are very limited at the moment.
+@end quotation
+@end cartouche
+
+@node Connecting Nexus with an EBICS account,Exchange Bank Account Configuration,Installation and Basic Configuration,Wire Gateway Setup
+@anchor{taler-exchange-manual connecting-nexus-with-an-ebics-account}@anchor{25}
+@section Connecting Nexus with an EBICS account
+
+
+The command line interface of the LibEuFin Nexus needs the following three
+values to be defined in the environment: @code{LIBEUFIN_NEXUS_URL},
+@code{LIBEUFIN_NEXUS_USERNAME}, and @code{LIBEUFIN_NEXUS_PASSWORD}.  In this example,
+@code{LIBEUFIN_NEXUS_USERNAME} should be set to @code{admin}, and
+@code{LIBEUFIN_NEXUS_PASSWORD} to the value hold in @code{NEXUS_ADMIN_PW} from the
+previous step (the @code{libeufin-nexus superuser} command).  The
+@code{LIBEUFIN_NEXUS_URL} could be given as @code{http://localhost:5017/}.
+
+Next, we create a EBICS `bank connection' that Nexus can use to communicate with the bank.
+
+@example
+[root@@exchange-online]# libeufin-cli \
+    connections \
+      new-ebics-connection \
+        --ebics-url $EBICS_BASE_URL \
+        --host-id $EBICS_HOST_ID \
+        --partner-id $EBICS_PARTNER_ID \
+        --ebics-user-id $EBICS_USER_ID \
+        $CONNECTION_NAME
+@end example
+
+If this step executes correctly, Nexus will have created all the cryptographic
+material that is needed on the client side; in this EBICS example, it created
+the signature and identification keys.  It is therefore advisable to `make
+a backup copy' of such keys.
+
+@example
+[root@@exchange-online]# libeufin-cli \
+    connections \
+      export-backup \
+        --passphrase $SECRET \
+        --output-file $BACKUP_FILE \
+        $CONNECTION_NAME
+@end example
+
+At this point, Nexus needs to both communicate its keys to the bank, and
+download the bank’s keys.  This synchronization happens through the INI, HIA, and
+finally, HPB message types.
+
+After the electronic synchronization, the subscriber must confirm their keys
+by sending a physical mail to the bank.  The following command helps generating
+such letter:
+
+@example
+[root@@exchange-online]# libeufin-cli connections get-key-letter $CONNECTION_NAME out.pdf
+@end example
+
+@example
+[root@@exchange-online]# libeufin-cli \
+    connections \
+      connect \
+        $CONNECTION_NAME
+@end example
+
+@c FIXME: Maybe is not 100% clear that 'connecting' means exchanging keys
+@c with the bank?
+
+Once the connection is synchronized, Nexus needs to import locally the data
+corresponding to the bank accounts offered by the bank connection just made.
+The command below downloads the list of the bank accounts offered by @code{$CONNECTION_NAME}.
+
+@example
+[root@@exchange-online]# libeufin-cli \
+    connections \
+      download-bank-accounts \
+        $CONNECTION_NAME
+@end example
+
+It is now possible to list the accounts offered by the connection.
+
+@example
+[root@@exchange-online]# libeufin-cli \
+    connections \
+      list-offered-bank-accounts \
+        $CONNECTION_NAME
+@end example
+
+@cartouche
+@quotation Note 
+The @code{nexusBankAccountId} field should at this step be @code{null},
+as we have not yet imported the bank account and thus the account
+does not yet have a local name.
+@end quotation
+@end cartouche
+
+Nexus now needs an explicit import of the accounts it should manage.  This
+step is needed to let the user pick a custom name for such accounts.
+
+@example
+[root@@exchange-online]# libeufin-cli \
+    connections \
+      import-bank-account \
+        --offered-account-id testacct01 \
+        --nexus-bank-account-id $LOCAL_ACCOUNT_NAME \
+        $CONNECTION_NAME
+@end example
+
+Once a Nexus user imported a bank account (@code{$LOCAL_ACCOUNT_NAME})
+under a certain connection (@code{$CONNECTION_NAME}), it is possible
+to accomplish the usual operations for any bank account: asking for the
+list of transactions, and making a payment.
+
+@menu
+* Testing; Requesting the transaction history: Testing Requesting the transaction history. 
+* Testing; Making payments: Testing Making payments. 
+* Automatic scheduling:: 
+* Creating a Taler facade:: 
+* Managing Permissions and Users:: 
+
+@end menu
+
+@node Testing Requesting the transaction history,Testing Making payments,,Connecting Nexus with an EBICS account
+@anchor{taler-exchange-manual testing-requesting-the-transaction-history}@anchor{26}
+@subsection Testing: Requesting the transaction history
+
+
+The LibEuFin Nexus keeps a local copy of the bank account’s transaction
+history.  Before querying transactions locally, it is necessary
+to request transactions for the bank account via the bank connection.
+
+This command asks Nexus to download the latest transaction reports/statements
+through the bank connection:
+
+@example
+[root@@exchange-online]# libeufin-cli accounts fetch-transactions $LOCAL_ACCOUNT_NAME
+@end example
+
+@cartouche
+@quotation Note 
+By default, the latest available transactions are fetched.  It is also
+possible to specify a custom date range (or even all available transactions)
+and the type of transactions to fetch (inter-day statements or intra-day
+reports).
+@end quotation
+@end cartouche
 
-@node Bank account,Auditor configuration,Terms of Service,Configuration<2>
-@anchor{taler-exchange-manual bank-account}@anchor{24}@anchor{taler-exchange-manual id8}@anchor{25}
-@section Bank account
+@c FIXME: Possibly the date range filter is still missing, see #6243.
 
+Once Nexus has stored all the information in the database, the
+client can ask to actually see the transactions:
+
+@example
+[root@@exchange-online]# libeufin-cli accounts transactions $LOCAL_ACCOUNT_NAME
+@end example
+
+@node Testing Making payments,Automatic scheduling,Testing Requesting the transaction history,Connecting Nexus with an EBICS account
+@anchor{taler-exchange-manual testing-making-payments}@anchor{27}
+@subsection Testing: Making payments
+
+
+Payments pass through two phases: preparation and submission.  The preparation
+phase assigns the payment initiation a unique ID, which prevents accidental
+double submissions of payments in case of network failures or other
+disruptions.
+
+The following command prepares a payment:
+
+@example
+[root@@exchange-online]# libeufin-cli accounts prepare-payment \
+        --creditor-iban=$IBAN_TO_SEND_MONEY_TO \
+        --creditor-bic=$BIC_TO_SEND_MONEY_TO \
+        --creditor-name=$CREDITOR_NAME \
+        --payment-amount=$AMOUNT \
+        --payment-subject=$SUBJECT \
+        $LOCAL_ACCOUNT_NAME
+@end example
+
+Note: the @code{$AMOUNT} value needs the format @code{X.Y:CURRENCY}; for example
+@code{EUR:10}, or @code{EUR:1.01}.
+
+The previous command should return a value (@code{$UUID}) that uniquely
+identifies the prepared payment in the Nexus system.  That is needed
+in the next step, to `send the payment instructions to the bank':
+
+@example
+[root@@exchange-online]# libeufin-cli accounts submit-payments \
+      --payment-uuid $UUID \
+      $LOCAL_ACCOUNT_NAME
+@end example
+
+@node Automatic scheduling,Creating a Taler facade,Testing Making payments,Connecting Nexus with an EBICS account
+@anchor{taler-exchange-manual automatic-scheduling}@anchor{28}
+@subsection Automatic scheduling
+
+
+With an EBICS bank connection, the LibEuFin Nexus needs to regularly query for
+new transactions and (re-)submit prepared payments.
+
+It is possible to schedule these tasks via an external task scheduler such as
+cron(8).  However, the nexus also has an internal task scheduling mechanism for
+accounts.
+
+The following three commands create a schedule for submitting payments hourly,
+fetching transactions (intra-day reports) every 5 minutes, and (inter-day statements)
+once at 11pm every day:
+
+@example
+[root@@exchange-online]# libeufin-cli accounts task-schedule $LOCAL_ACCOUNT_NAME \
+    --task-type="submit" \
+    --task-name='submit-payments-hourly' \
+    --task-cronspec='0 0 *'
+
+[root@@exchange-online]# libeufin-cli accounts task-schedule $LOCAL_ACCOUNT_NAME \
+    --task-type="fetch" \
+    --task-name='fetch-5min' \
+    --task-cronspec='0 */5 *' \
+    --task-param-level=report \
+    --task-param-range-type=latest
+
+[root@@exchange-online]# libeufin-cli accounts task-schedule $LOCAL_ACCOUNT_NAME \
+    --task-type="fetch" \
+    --task-name='fetch-daily' \
+    --task-cronspec='0 0 23' \
+    --task-param-level=statement \
+    --task-param-range-type=latest
+@end example
+
+The cronspec has the following format, which is slightly non-standard due to
+the @code{SECONDS} field
+
+@example
+SECONDS MINUTES HOURS DAY-OF-MONTH[optional] MONTH[optional] DAY-OF-WEEK[optional]
+@end example
+
+@node Creating a Taler facade,Managing Permissions and Users,Automatic scheduling,Connecting Nexus with an EBICS account
+@anchor{taler-exchange-manual creating-a-taler-facade}@anchor{29}
+@subsection Creating a Taler facade
+
+
+Facades are additional abstraction layers that can serve
+specific purposes.  For example, one application might need
+a filtered version of the transaction history, or it might
+want to refuse payments that do not conform to certain rules.
+
+At this moment, only the `Taler facade type' is implemented
+in the Nexus, and the command below instantiates one under a
+existing bank account / connection pair.  You can freely
+assign an identifier for the @code{$FACADE_NAME} below:
+
+@example
+[root@@exchange-online]# libeufin-cli facades new-taler-wire-gateway-facade \
+    --currency EUR \
+    --facade-name $FACADE_NAME \
+    $CONNECTION_NAME \
+    $LOCAL_ACCOUNT_NAME
+@end example
+
+At this point, the additional taler-wire-gateway API
+becomes offered by the Nexus.  The purpose is to let a Taler exchange rely on
+Nexus to manage its bank account.
+
+The base URL of the facade that can be used by the Taler exchange
+as the Taler Wire Gateway base URL can be seen by listing the facades:
+
+@example
+[root@@exchange-online]# libeufin-cli facades list
+@end example
+
+@node Managing Permissions and Users,,Creating a Taler facade,Connecting Nexus with an EBICS account
+@anchor{taler-exchange-manual managing-permissions-and-users}@anchor{2a}
+@subsection Managing Permissions and Users
+
+
+This guide has so far assumed that a superuser is accessing the LibEuFin Nexus.
+However, it is advisable that the Nexus is accessed with users that only have a
+minimal set of permissions.
+
+The Nexus currently only has support for giving non-superusers access to Taler
+wire gateway facades.
+
+To create a new user, use the @code{users} subcommand of the CLI:
+
+@example
+[root@@exchange-online]# libeufin-cli users list
+# [ ... shows available users ... ]
+
+[root@@exchange-online]# libeufin-cli users create $USERNAME
+# [ ... will prompt for password ... ]
+@end example
+
+Permissions are managed with the @code{permissions} subcommand.
+The following commands grant permissions to view the transaction history
+and create payment initiations with a Taler wire gateway facade:
+
+@example
+[root@@exchange-online]# libeufin-cli permissions grant \
+   user $USERNAME \
+   facade $FACADENAME \
+   facade.talerwiregateway.history
+
+[root@@exchange-online]# libeufin-cli permissions grant \
+   user $USERNAME \
+   facade $FACADENAME \
+   facade.talerwiregateway.transfer
+@end example
+
+@c FIXME: The two commands above output an empty JSON object
+@c when successful.  Possibly, we should suppress that (just like
+@c the other commands do).
+
+The list of all granted permissions can be reviewed:
+
+@example
+[root@@exchange-online]# libeufin-cli permissions list
+@end example
+
+@node Exchange Bank Account Configuration,,Connecting Nexus with an EBICS account,Wire Gateway Setup
+@anchor{taler-exchange-manual bank-account}@anchor{2b}@anchor{taler-exchange-manual exchange-bank-account-configuration}@anchor{2c}
+@section Exchange Bank Account Configuration
+
+
+An exchange must be configured with the right settings to access its bank
+account via a Taler Wire Gateway.  An exchange can be configured to use
+multiple bank accounts by using multiple Wire Gateways.  Typically only one
+Wire Gateway is used.
 
 To configure a bank account in Taler, we need to furnish two pieces of
 information:
@@ -1241,18 +2083,37 @@ authentication information is currently a username and password
 for HTTP basic authentication.
 @end itemize
 
+A Taler Wire Gateway is configured in a configuration section that follows the
+pattern @code{exchange-account-$id}, where @code{$id} is an internal identifier for
+the bank account accessed by the exchange.  The basic information for an
+account should be put in @code{/etc/taler/conf.d/exchange-business.conf}.  The
+secret credentials to access the Taler Wire Gateway API should be put into a
+corresponding @code{exchange-accountcredentials-$id} section in
+@code{/etc/taler/secrets/exchange-accountcredentials.conf}.  The latter file
+should already be only readable for the @code{taler-exchange-wire} user.  Other
+exchange processes should not have access to this information.
+
 You can configure multiple accounts for an exchange by creating sections
 starting with “exchange-account-” for the section name. You can ENABLE for
 each account whether it should be used, and for what (incoming or outgoing
 wire transfers):
 
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-business.conf}
+
 @example
 [exchange-account-1]
-# With x-taler-bank (say for PyBank)
-PAYTO_URI = "payto://x-taler-bank/bank.demo.taler.net/Exchange"
-
+# Account identifier in the form of an RFC-8905 payto:// URI.
+# For SEPA, looks like payto://iban/$IBAN?receiver-name=$NAME
+# Make sure to URL-encode spaces in $NAME!
+#
+# With x-taler-bank (for Fakebank)
+# PAYTO_URI = "payto://x-taler-bank/bank.demo.taler.net/Exchange?receiver-name=exop"
+#
 # Example using IBAN (for use with LibEuFin)
-# PAYTO_URI = "payto://iban/CH9300762011623852957"
+PAYTO_URI = "payto://iban/CH9300762011623852957?receiver=name=exop"
 
 # URL for talking to the bank wire the wire API.
 WIRE_GATEWAY_URL = https://bank.demo.taler.net/taler-wire-gateway/Exchange
@@ -1262,107 +2123,745 @@ ENABLE_DEBIT = YES
 # Use for exchange-wirewatch (and listed in /wire)
 ENABLE_CREDIT = YES
 
-# Authentication options for exchange bank account go here.
-# (Next sections have examples of authentication mechanisms)
+@@inline-secret@@ exchange-accountcredentials-1 ../secrets/exchange-accountcredentials.secret.conf
+@end example
+
+@end float
+
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/secrets/exchange-accountcredentials.secret.conf}
+
+@example
+[exchange-accountcredentials-1]
+
+# LibEuFin expects basic auth.
 WIRE_GATEWAY_AUTH_METHOD = basic
-USERNAME = exchange
-PASSWORD = super-secure
+
+# Username and password set in LibEuFin.
+USERNAME = ...
+PASSWORD = ...
+
+# Base URL of the wire gateway set up with LibEuFin.
+WIRE_GATEWAY_URL = ...
 @end example
 
-The command line tool @code{taler-exchange-offline} must be used to
-sign the @code{payto://} URI in a way suitable to convince wallets that
-this is the correct address to wire funds to.
-For example, the utility may be invoked as
-follows to enable a wire account:
+@end float
+
+
+Such a Wire Gateway configuration can be tested with the following commands:
 
 @example
-$ taler-exchange-offline enable-account payto://iban/CH9300762011623852957
+[root@@exchange-online]# taler-exchange-wire-gateway-client \
+  --section exchange-accountcredentials-1 --debit-history
+[root@@exchange-online]# taler-exchange-wire-gateway-client \
+  --section exchange-accountcredentials-1 --credit-history
 @end example
 
-The resulting JSON output must be uploaded to the exchange using
-@code{taler-exchange-offline upload}.
-For details, see manpages/taler-exchange-offline.1.
+@node Legal Setup,Deployment,Wire Gateway Setup,Top
+@anchor{taler-exchange-manual legal-setup}@anchor{2d}@anchor{taler-exchange-manual legalsetup}@anchor{2e}
+@chapter Legal Setup
+
+
+This chapter describes how to setup certain legal aspects of a GNU Taler
+exchange. Users that just want to set up an exchange as an experiment without
+legal requirements can safely skip these steps.
 
 @menu
-* Wire fee structure:: 
+* Legal conditions for using the service:: 
+* Terms of Service:: 
+* Privacy Policy:: 
+* Legal policies directory layout:: 
+* Generating the Legal Terms:: 
+* Adding translations:: 
+* Updating legal documents:: 
+* KYC Configuration:: 
+* KYC AID specifics:: 
 
 @end menu
 
-@node Wire fee structure,,,Bank account
-@anchor{taler-exchange-manual id9}@anchor{26}@anchor{taler-exchange-manual wire-fee-structure}@anchor{27}
-@subsection Wire fee structure
+@node Legal conditions for using the service,Terms of Service,,Legal Setup
+@anchor{taler-exchange-manual legal-conditions-for-using-the-service}@anchor{2f}
+@section Legal conditions for using the service
 
 
-@geindex wire fee
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
 
-@geindex fee
+The service has well-known API endpoints to return its legal conditions to the
+user in various languages and various formats.  This section describes how to
+setup and configure the legal conditions.
 
-For each wire method (“iban” or “x-taler-bank”) the
-exchange must know about applicable wire fees. This is also done
-using the @code{taler-exchange-offline} tool:
+@node Terms of Service,Privacy Policy,Legal conditions for using the service,Legal Setup
+@anchor{taler-exchange-manual terms-of-service}@anchor{30}
+@section Terms of Service
+
+
+The service has an endpoint “/terms” to return the terms of service (in legal
+language) of the service operator.  Client software show these terms of
+service to the user when the user is first interacting with the service.
+Terms of service are optional for experimental deployments, if none are
+configured, the service will return a simple statement saying that there are
+no terms of service available.
+
+To configure the terms of service response, there are two options
+in the configuration file for the service:
+
+
+@itemize -
+
+@item 
+@code{TERMS_ETAG}: The current “Etag” to return for the terms of service.
+This value must be changed whenever the terms of service are
+updated. A common value to use would be a version number.
+Note that if you change the @code{TERMS_ETAG}, you MUST also provide
+the respective files in @code{TERMS_DIR} (see below).
+
+@item 
+@code{TERMS_DIR}: The directory that contains the terms of service.
+The files in the directory must be readable to the service
+process.
+@end itemize
+
+@node Privacy Policy,Legal policies directory layout,Terms of Service,Legal Setup
+@anchor{taler-exchange-manual privacy-policy}@anchor{31}
+@section Privacy Policy
+
+
+The service has an endpoint “/pp” to return the terms privacy policy (in legal
+language) of the service operator.  Clients should show the privacy policy to
+the user when the user explicitly asks for it, but it should not be shown by
+default.  Privacy policies are optional for experimental deployments, if none
+are configured, the service will return a simple statement saying that there
+is no privacy policy available.
+
+To configure the privacy policy response, there are two options
+in the configuration file for the service:
+
+
+@itemize -
+
+@item 
+@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
+This value must be changed whenever the privacy policy is
+updated. A common value to use would be a version number.
+Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
+the respective files in @code{PRIVACY_DIR} (see below).
+
+@item 
+@code{PRIVACY_DIR}: The directory that contains the privacy policy.
+The files in the directory must be readable to the service
+process.
+@end itemize
+
+@node Legal policies directory layout,Generating the Legal Terms,Privacy Policy,Legal Setup
+@anchor{taler-exchange-manual legal-policies-directory-layout}@anchor{32}
+@section Legal policies directory layout
+
+
+The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
+particular layout.  You may use the same directory for both the terms of
+service and the privacy policy, as long as you use different ETAGs.  Inside of
+the directory, there should be sub-directories using two-letter language codes
+like “en”, “de”, or “jp”.  Each of these directories would then hold
+translations of the current terms of service into the respective language.
+Empty directories are permitted in case translations are not available.
+
+Then, inside each language directory, files with the name of the value set as
+the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
+of the files should be typical for the respective mime type.  The set of
+supported mime types is currently hard-coded in the service, and includes
+“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
+the service may show a warning on startup.
+
+@menu
+* Example:: 
+
+@end menu
+
+@node Example,,,Legal policies directory layout
+@anchor{taler-exchange-manual example}@anchor{33}
+@subsection Example
+
+
+A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
+
+
+@itemize -
+
+@item 
+TERMS_DIR/en/tos-v0.txt
+
+@item 
+TERMS_DIR/en/tos-v0.html
+
+@item 
+TERMS_DIR/en/tos-v0.pdf
+
+@item 
+TERMS_DIR/en/tos-v0.epub
+
+@item 
+TERMS_DIR/en/tos-v0.md
+
+@item 
+TERMS_DIR/de/tos-v0.txt
+
+@item 
+TERMS_DIR/de/tos-v0.html
+
+@item 
+TERMS_DIR/de/tos-v0.pdf
+
+@item 
+TERMS_DIR/de/tos-v0.epub
+
+@item 
+TERMS_DIR/de/tos-v0.md
+@end itemize
+
+If the user requests an HTML format with language preferences “fr” followed by
+“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+French.
+
+@node Generating the Legal Terms,Adding translations,Legal policies directory layout,Legal Setup
+@anchor{taler-exchange-manual generating-the-legal-terms}@anchor{34}
+@section Generating the Legal Terms
+
+
+The @code{taler-terms-generator} script can be used to generate directories with
+terms of service and privacy policies in multiple languages and all required
+data formats from a single source file in @code{.rst} format and GNU gettext
+translations in @code{.po} format.
+
+To use the tool, you need to first write your legal conditions in English in
+reStructuredText (rst).  You should find a templates in
+@code{$PREFIX/share/terms/*.rst} where @code{$PREFIX} is the location where you
+installed the service to. Whenever you make substantive changes to the legal
+terms, you must use a fresh filename and change the respective @code{ETAG}.  The
+resulting file must be called @code{$ETAG.rst} and the first line of the file should be the title of the document.
+
+Once you have written the @code{$ETAG.rst} file in English, you can
+generate the first set of outputs:
 
 @example
-$ taler-exchange-offline wire-fee iban 2040 EUR:0.05 EUR:0.10 EUR:0.15
+$ taler-terms-generator -i $ETAG
 @end example
 
-The above sets the wire fees for wire transfers involving @code{iban} accounts
-(in Euros) in the year 2040 to 5 cents (wire fee) and 10 cents (closing fee).
-The tool only supports setting fees that applies for the entire calendar year.
+Afterwards, you should find the terms in various formats for all configured
+languages (initially only English) in @code{$PREFIX/share/terms/}.  The generator
+has a few options which are documented in its man page.
 
-We recommend provisioning an exchange with wire fees at least for the next two
-years.  Note that once the fees have been set for a year, they cannot be
-changed (basically, by signing the fees the exchange makes a legally binding
-offer to the customers).
+@node Adding translations,Updating legal documents,Generating the Legal Terms,Legal Setup
+@anchor{taler-exchange-manual adding-translations}@anchor{35}
+@section Adding translations
 
-@geindex maintenance
+
+Translations must be available in subdirectories
+@code{locale/$LANGUAGE/LC_MESSAGES/$ETAG.po}.
+To start translating, you first need to add a new
+language:
+
+@example
+$ taler-terms-generator -i $ETAG -l $LANGUAGE
+@end example
+
+Here, @code{$LANGUAGE} should be a two-letter language
+code like @code{de} or @code{fr}.  The command will generate
+a file @code{locale/$LANGUAGE/LC_MESSAGES/$ETAG.po}
+which contains each English sentence or paragraph
+in the original document and an initially empty
+translation.  Translators should update the @code{.po}
+file. Afterwards, simply re-run
+
+@example
+$ taler-terms-generator -i $ETAG
+@end example
+
+to make the current translation(s) available to the
+service.
 
 @cartouche
 @quotation Note 
-Provisioning future wire fees, like provisioning future denomination
-and signing keys, are key regular maintenance procedures for every
-exchange operator.  We recommend setting automated reminders for
-this maintenance activity!
+You must restart the service whenever adding or updating legal documents or their translations.
 @end quotation
 @end cartouche
 
-@node Auditor configuration,,Bank account,Configuration<2>
-@anchor{taler-exchange-manual auditor-configuration}@anchor{28}@anchor{taler-exchange-manual id10}@anchor{29}
-@section Auditor configuration
+@node Updating legal documents,KYC Configuration,Adding translations,Legal Setup
+@anchor{taler-exchange-manual updating-legal-documents}@anchor{36}
+@section Updating legal documents
+
+
+When making minor changes without legal implications, edit the @code{.rst} file,
+then re-run the step to add a new language for each existing translation to
+produce an updated @code{.po} file. Translate the sentences that have changed and
+finally run the generator (without @code{-l}) on the ETAG (@code{-i $ETAG}) to
+create the final files.
+
+When making major changes with legal implications, you should first rename (or
+copy) the existing @code{.rst} file and the associated translation files to a new
+unique name.  Afterwards, make the major changes, update the @code{.po} files,
+complete the translations and re-create the final files.  Finally, do not
+forget to update the @code{ETAG} configuration option to the new name and to
+restart the service.
+
+@node KYC Configuration,KYC AID specifics,Updating legal documents,Legal Setup
+@anchor{taler-exchange-manual kyc-configuration}@anchor{37}
+@section KYC Configuration
+
+
+To legally operate, Taler exchange operators may have to comply with KYC
+regulation that requires financial institutions to identify parties involved
+in transactions at certain points.
 
+Taler permits an exchange to require KYC data under the following circumstances:
 
-The exchange must be informed about any auditor that is expected to provision
-it with auditor signatures.  This is also done using the
-@code{taler-exchange-offline} tool on the offline system.  First, the auditor
-must be configured and provide the exchange operator with its public key and
-the URL of it's REST API.  The exchange operator also needs a human-readable
-name that may be shown to users to identify the auditor.  Given this
-information, the exchange operator can enable the auditor:
+@quotation
+
+
+@itemize *
+
+@item 
+Customer withdraws money over a threshold
+
+@item 
+Wallet receives (via refunds) money resulting in a balance over a threshold
+
+@item 
+Wallet receives money via P2P payments over a threshold
+
+@item 
+Merchant receives money over a threshold
+
+@item 
+Reserve is “opened” for invoicing or rewards (`planned feature')
+@end itemize
+@end quotation
+
+@menu
+* Taler KYC Terminology:: 
+* KYC Configuration Options:: 
+* OAuth 2.0 specifics: OAuth 2 0 specifics. 
+* Persona specifics:: 
+
+@end menu
+
+@node Taler KYC Terminology,KYC Configuration Options,,KYC Configuration
+@anchor{taler-exchange-manual taler-kyc-terminology}@anchor{38}
+@subsection Taler KYC Terminology
+
+
+
+@itemize *
+
+@item 
+`Check': A check establishes a particular attribute of a user, such as
+their name based on an ID document and lifeness, mailing address, phone
+number, taxpayer identity, etc.
+
+@item 
+`Type of operation': The operation type determines which Taler-specific
+operation has triggered the KYC requirement. We support four types of
+operation: withdraw (by customer), deposit (by merchant), P2P receive (by
+wallet) and (high) wallet balance.
+
+@item 
+`Condition': A condition specifies when KYC is required. Conditions
+include the `type of operation', a threshold amount (e.g. above EUR:1000)
+and possibly a time period (e.g. over the last month).
+
+@item 
+`Cost': Metric for the business expense for a KYC check at a certain
+`provider'. Not in any currency, costs are simply relative and non-negative
+values. Costs are considered when multiple choices are allowed by the
+`configuration'.
+
+@item 
+`Expiration': KYC legitimizations may be outdated. Expiration rules
+determine when `checks' have to be performed again.
+
+@item 
+`Legitimization rules': The legitimization rules determine under which
+`conditions' which `checks' must be performend and the `expiration' time
+period for the `checks'.
+
+@item 
+`Logic': Logic refers to a specific bit of code (realized as an exchange
+plugin) that enables the interaction with a specific `provider'.  Logic
+typically requires configuration for access control (such as an
+authorization token) and possibly the endpoint of the specific `provider'
+implementing the respective API.
+
+@item 
+`Provider': A provider performs a specific set of `checks' at a certain
+`cost'. Interaction with a provider is performed by provider-specific
+`logic'.
+@end itemize
+
+@node KYC Configuration Options,OAuth 2 0 specifics,Taler KYC Terminology,KYC Configuration
+@anchor{taler-exchange-manual kyc-configuration-options}@anchor{39}
+@subsection KYC Configuration Options
+
+
+The KYC configuration determines the `legitimization rules', and specifies
+which providers offer which `checks' at what `cost'.
+
+The configuration specifies a set of providers, one per configuration section. The names of the configuration
+sections must being with @code{kyc-proider-} followed by
+an arbitrary @code{$PROVIDER_ID}:
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-kyc-providers.conf}
 
 @example
-$ taler-exchange-offline enable-auditor $PUB_KEY $REST_URL "$AUDITOR_NAME" > auditor.json
+[kyc-provider-$PROVIDER_ID]
+# How expensive is it to use this provider?
+# Used to pick the cheapest provider possible.
+COST = 42
+# Which plugin is responsible for this provider?
+# Choices include "oauth2", "kycaid" and "persona".
+LOGIC = oauth2
+# Which type of user does this provider handle?
+# Either INDIVIDUAL or BUSINESS.
+USER_TYPE = INDIVIDUAL
+# Which checks does this provider provide?
+# List of strings, no specific semantics.
+PROVIDED_CHECKS = SMS GOVID PHOTO
+# Plus additional logic-specific options, e.g.:
+AUTHORIZATION_TOKEN = superdupersecret
+FORM_ID = business_legi_form
+# How long is the check considered valid?
+EXPIRATION = 3650d
 @end example
 
-As before, the @emph{auditor.json} file must then be copied from the offline system
-to a system connected to the exchange and there @code{uploaded} to the exchange.
+@end float
+
+
+The configuration also must specify a set of legitimization requirements, again one
+per configuration section:
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-kyc-rules.conf}
+
+@example
+[kyc-legitimization-$RULE_NAME]
+# Operation that triggers this legitimization.
+# Must be one of WITHDRAW, DEPOSIT, P2P-RECEIVE
+# or WALLET-BALANCE.
+OPERATION_TYPE = WITHDRAW
+# Required checks to be performed.
+# List of strings, must individually match the
+# strings in one or more provider's PROVIDED_CHECKS.
+REQUIRED_CHECKS = SMS GOVID
+# Threshold amount above which the legitimization is
+# triggered.  The total must be exceeded in the given
+# timeframe.
+THRESHOLD = KUDOS:100
+# Timeframe over which the amount to be compared to
+# the  THRESHOLD is calculated.  Can be 'forever'.
+# Ignored for WALLET-BALANCE.
+TIMEFRAME = 30d
+@end example
+
+@end float
+
+
+@node OAuth 2 0 specifics,Persona specifics,KYC Configuration Options,KYC Configuration
+@anchor{taler-exchange-manual oauth-2-0-specifics}@anchor{3a}
+@subsection OAuth 2.0 specifics
+
+
+In terms of configuration, the OAuth 2.0 logic requires the respective client
+credentials to be configured apriori to enable access to the legitimization
+service.  The OAuth 2.0 configuration options are:
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-oauth2.conf}
+
+@example
+[kyc-provider-example-oauth2]
+LOGIC = oauth2
+# (generic options omitted)
+# How long is the KYC check valid?
+KYC_OAUTH2_VALIDITY = forever
+
+# URL to which we redirect the user for the login process
+KYC_OAUTH2_AUTHORIZE_URL = "http://kyc.example.com/authorize"
+# URL where we POST the user's authentication information
+KYC_OAUTH2_TOKEN_URL = "http://kyc.example.com/token"
+# URL of the user info access point.
+KYC_OAUTH2_INFO_URL = "http://kyc.example.com/info"
+
+# Where does the client get redirected upon completion?
+KYC_OAUTH2_POST_URL = "http://example.com/thank-you"
+
+# For authentication to the OAuth2.0 service
+KYC_OAUTH2_CLIENT_ID = testcase
+KYC_OAUTH2_CLIENT_SECRET = password
+
+# Mustach template that converts OAuth2.0 data about the user
+# into GNU Taler standardized attribute data.
+#
+KYC_OAUTH2_ATTRIBUTE_TEMPLATE = "@{"fullname":"@{@{last_name@}@}, @{@{first_name@}@}","phone":"@{@{phone@}@}"@}"
+@end example
+
+@end float
+
+
+The @code{KYC_OAUTH2_ATTRIBUTE_TEMPLATE} provides a generic way to convert data
+returned by an OAuth-provider into the internal format used by the exchange.
 
-@node Deployment,Testing a deployment,Configuration<2>,Top
-@anchor{taler-exchange-manual deployment}@anchor{2a}@anchor{taler-exchange-manual id11}@anchor{2b}
+The Challenger service for address validation supports OAuth2.0, but does not
+have a static AUTHORIZE_URL. Instead, the AUTHORIZE_URL must be enabled by the client
+using a special authenticated request to the Challenger’s @code{/setup} endpoint.
+The exchange supports this by appending @code{#setup} to the AUTHORIZE_URL (note
+that fragments are illegal in OAuth2.0 URLs).  Be careful to quote the URL,
+as @code{#} is otherwise interpreted as the beginning of a comment by the
+configuration file syntax.
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-challenger-oauth2.conf}
+
+@example
+[kyc-provider-challenger-oauth2]
+LOGIC = oauth2
+KYC_OAUTH2_AUTHORIZE_URL = "http://challenger.example.com/authorize/#setup"
+KYC_OAUTH2_TOKEN_URL = "http://challenger.example.com/token"
+KYC_OAUTH2_INFO_URL = "http://challenger.example.com/info"
+@end example
+
+@end float
+
+
+When using OAuth 2.0, the `CLIENT REDIRECT URI' must be set to the
+@code{/kyc-proof/$PROVIDER_SECTION} endpoint. For example, given the
+configuration above and an exchange running on the host
+@code{exchange.example.com}, the redirect URI would be
+@code{https://exchange.example.com/kyc-proof/kyc-provider-challenger-oauth2/}.
+
+@node Persona specifics,,OAuth 2 0 specifics,KYC Configuration
+@anchor{taler-exchange-manual persona-specifics}@anchor{3b}
+@subsection Persona specifics
+
+
+We use the hosted flow. The Persona endpoints return a @code{request-id}, which
+we log for diagnosis.
+
+Persona should be configured to use the @code{/kyc-webhook/} endpoint of the
+exchange to notify the exchange about the completion of KYC processes.
+The webhook is authenticated using a shared secret, which should
+be in the configuration.
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-persona.conf}
+
+@example
+[kyclogic-persona]
+# Webhook authorization token. Global for all uses
+# of the persona provider!
+WEBHOOK_AUTH_TOKEN = wbhsec_698b5a19-c790-47f6-b396-deb572ec82f9
+
+[kyc-provider-example-persona]
+LOGIC = persona
+# (generic options omitted)
+
+# How long is the KYC check valid?
+KYC_PERSONA_VALIDITY = 365d
+
+# Which subdomain is used for our API?
+KYC_PERSONA_SUBDOMAIN = taler
+
+# Helper to convert JSON with KYC data returned by Persona into GNU Taler
+# internal format. Should probably always be set to
+# "taler-exchange-kyc-persona-converter.sh".
+KYC_PERSONA_CONVERTER_HELPER = "taler-exchange-kyc-persona-converter.sh"
+
+# Authentication token to use.
+KYC_PERSONA_AUTH_TOKEN = persona_sandbox_42
+
+# Form to use.
+KYC_PERSONA_TEMPLATE_ID = itempl_Uj6Xxxxx
+
+# Where do we redirect to after KYC finished successfully.
+KYC_PERSONA_POST_URL = "https://taler.net/"
+
+# Salt to give to requests for idempotency.
+# Optional.
+# KYC_PERSONA_SALT = salt
+@end example
+
+@end float
+
+
+To use the Persona webhook, you must set the webhook URL in the
+Persona service to @code{$EXCHANGE_BASE_URL/kyc-webhook/$SECTION_NAME/}
+where @code{$SECTION_NAME} is the name of the configuration section.
+You should also extract the authentication token for the webhook
+and put it into the configuration as shown above.
+
+@node KYC AID specifics,,KYC Configuration,Legal Setup
+@anchor{taler-exchange-manual kyc-aid-specifics}@anchor{3c}
+@section KYC AID specifics
+
+
+We use the hosted flow.
+
+KYCAID should be configured to use the @code{/kyc-webhook/} endpoint of the
+exchange to notify the exchange about the completion of KYC processes.
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-kycaid.conf}
+
+@example
+[kyc-provider-example-kycaid]
+LOGIC = kycaid
+# (generic options omitted)
+
+# How long is the KYC check valid?
+KYC_KYCAID_VALIDITY = 365d
+
+# Authentication token to use.
+KYC_KYCAID_AUTH_TOKEN = XXX
+
+# Form to use.
+KYC_KYCAID_FORM_ID = XXX
+
+# URL to go to after the process is complete.
+KYC_KYCAID_POST_URL = "https://taler.net/"
+@end example
+
+@end float
+
+
+@node Deployment,Offline Signing Setup Key Maintenance and Tear-Down,Legal Setup,Top
+@anchor{taler-exchange-manual deployment}@anchor{3d}@anchor{taler-exchange-manual id3}@anchor{3e}
 @chapter Deployment
 
 
-This chapter describes how to deploy the exchange once it has been
-configured.
+This chapter describes how to deploy the exchange once the basic installation
+and configuration are completed.
 
 @menu
+* Serving:: 
+* Reverse Proxy Setup:: 
 * Launching an exchange:: 
-* Keys generation:: 
-* Private key storage:: 
-* Database upgrades:: 
 
 @end menu
 
-@node Launching an exchange,Keys generation,,Deployment
-@anchor{taler-exchange-manual launch}@anchor{2c}@anchor{taler-exchange-manual launching-an-exchange}@anchor{2d}
+@node Serving,Reverse Proxy Setup,,Deployment
+@anchor{taler-exchange-manual id4}@anchor{3f}@anchor{taler-exchange-manual serving}@anchor{40}
+@section Serving
+
+
+The exchange can serve HTTP over both TCP and UNIX domain socket.
+
+The following options are to be configured in the section @code{[exchange]}:
+
+
+@itemize -
+
+@item 
+@code{SERVE}: Must be set to @code{tcp} to serve HTTP over TCP, or @code{unix} to serve
+HTTP over a UNIX domain socket.
+
+@item 
+@code{PORT}: Set to the TCP port to listen on if @code{SERVE} is @code{tcp}.
+
+@item 
+@code{UNIXPATH}: Set to the UNIX domain socket path to listen on if @code{SERVE} is
+@code{unix}.
+
+@item 
+
+@table @asis
+
+@item @code{UNIXPATH_MODE}: Number giving the mode with the access permission mask
+
+for the @code{UNIXPATH} (i.e. 660 = @code{rw-rw---}). Make sure to set it in such
+a way that your reverse proxy has permissions to access the UNIX domain
+socket.  The default (660) assumes that the reverse proxy is a member of
+the group under which the exchange HTTP server is running.
+@end table
+@end itemize
+
+@node Reverse Proxy Setup,Launching an exchange,Serving,Deployment
+@anchor{taler-exchange-manual reverse-proxy-setup}@anchor{41}@anchor{taler-exchange-manual reverseproxy}@anchor{42}
+@section Reverse Proxy Setup
+
+
+By default, the @code{taler-exchange-httpd} service listens for HTTP connections
+on a UNIX domain socket.  To make the service publicly available, a reverse
+proxy such as nginx should be used.  We strongly recommend to configure nginx
+to use TLS.
+
+The public URL that the exchange will be served under should
+be put in @code{/etc/taler/conf.d/exchange-business.conf} configuration file.
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-business.conf}
+
+@example
+ [exchange]
+ BASE_URL = https://example.com/
+
+ # ... rest of file ...
+@end example
+
+@end float
+
+
+The @code{taler-exchange} package ships with a sample configuration that can be
+enabled in nginx:
+
+@example
+[root@@exchange-online]# vim /etc/nginx/sites-available/taler-exchange
+< ... customize configuration ... >
+[root@@exchange-online]# ln -s /etc/nginx/sites-available/taler-exchange \
+                              /etc/nginx/sites-enabled/taler-exchange
+[root@@exchange-online]# systemctl reload nginx
+@end example
+
+Note that the reverse proxy must set a HTTP @code{X-Forwarded-Host} header to
+refer to the hostname used by nginx and a HTTP @code{X-Forwarded-Proto} header to
+inform the exchange whether the external protocol was @code{http} or @code{https}.
+Thus, depending on your setup, you will likely have to edit those parts of the
+provided @code{taler-exchange} configuration file.
+
+With this last step, we are finally ready to launch the
+main exchange process.
+
+@node Launching an exchange,,Reverse Proxy Setup,Deployment
+@anchor{taler-exchange-manual launch}@anchor{43}@anchor{taler-exchange-manual launching-an-exchange}@anchor{44}
 @section Launching an exchange
 
 
@@ -1375,6 +2874,9 @@ A running exchange requires starting the following processes:
 @code{taler-exchange-secmod-rsa} (as special user, sharing group with the HTTPD)
 
 @item 
+@code{taler-exchange-secmod-cs} (as special user, sharing group with the HTTPD)
+
+@item 
 @code{taler-exchange-secmod-eddsa} (as special user, sharing group with the HTTPD)
 
 @item 
@@ -1393,7 +2895,7 @@ A running exchange requires starting the following processes:
 @code{taler-exchange-transfer} (needs credentials to initiate outgoing wire transfers and database access)
 @end itemize
 
-The crypto helpers must be started before the @code{taler-exchange-httpd} and
+The crypto helpers (@code{secmod}) must be started before the @code{taler-exchange-httpd} and
 they should use the same configuration file.
 
 For the most secure deployment, we recommend using separate users for each of
@@ -1404,13 +2906,13 @@ thus also should not have it).
 The processes that require access to the bank account need to have a
 configuration file with the respective credentials in it. We recommend using a
 separate configuration at least for @code{taler-exchange-transfer} which is the
-@emph{only} process that needs to know the credentials to execute outgoing wire
+`only' process that needs to know the credentials to execute outgoing wire
 transfers.
 
 All of these processes should also be started via a hypervisor like
 @code{systemd} or @code{gnunet-arm} that automatically re-starts them should they
 have terminated unexpectedly.  If the bank is down (say for maintenance), it is
-@emph{possible} to halt the @code{taler-exchange-wirewatch} and/or
+`possible' to halt the @code{taler-exchange-wirewatch} and/or
 @code{taler-exchange-transfer} processes (to avoid them making requests to the
 bank API that can only fail) without impacting other operations of the
 exchange. Naturally, incoming wire transfers will only be observed once
@@ -1433,24 +2935,107 @@ attack surface.)
 @end quotation
 @end cartouche
 
-@node Keys generation,Private key storage,Launching an exchange,Deployment
-@anchor{taler-exchange-manual id12}@anchor{2e}@anchor{taler-exchange-manual keys-generation}@anchor{2f}
-@section Keys generation
+Given proper packaging, all of the above are realized via a simple systemd
+target. This enables the various processes of an exchange service to be
+started using a simple command:
+
+@example
+[root@@exchange-online]# systemctl start taler-exchange.target
+@end example
+
+@cartouche
+@quotation Note 
+At this point, the exchange service is not yet fully operational.
+@end quotation
+@end cartouche
+
+To check whether the exchange is running correctly under the advertized
+base URL, run:
+
+@example
+[root@@exchange-online]# export BASE_URL=$(taler-config -s exchange -o base_url)
+[root@@exchange-online]# wget $@{BASE_URL@}management/keys
+@end example
+
+The request might take some time to complete on slow machines, because
+a lot of key material will be generated.
+
+@node Offline Signing Setup Key Maintenance and Tear-Down,Setup Linting,Deployment,Top
+@anchor{taler-exchange-manual offline-signing-setup-key-maintenance-and-tear-down}@anchor{45}
+@chapter Offline Signing Setup, Key Maintenance and Tear-Down
+
+
+The exchange HTTP service must be running before you can complete the
+following offline signing procedure. Note that when an exchange is running
+without offline keys its not fully operational.  To make the exchange HTTP
+service fully operational, the following steps involving the offline signing
+machine must be completed:
+
+@quotation
+
+
+@enumerate 
+
+@item 
+The public keys of various online keys used by the exchange service are exported
+via a management HTTP API.
+
+@item 
+The offline signing system validates this request and signs it.
+Additionally, the offline signing system signs policy messages
+to configure the exchange’s bank accounts and associated fees.
+
+@item 
+The messages generated by the offline signing system are uploaded
+via the management API of the exchange HTTP service.
+@end enumerate
+@end quotation
+
+A typical minimal setup would look something like this:
+
+@example
+[anybody@@exchange-online]# taler-exchange-offline \
+  download > sig-request.json
+
+[root@@exchange-offline]# taler-exchange-offline \
+  sign < sig-request.json > sig-response.json
+[root@@exchange-offline]# taler-exchange-offline \
+  enable-account payto://iban/$IBAN?receiver-name=$NAME > acct-response.json
+[root@@exchange-offline]# taler-exchange-offline \
+  wire-fee now iban EUR:0 EUR:0 > fee-response.json
+[root@@exchange-offline]# taler-exchange-offline \
+  global-fee now EUR:0 EUR:0 EUR:0 4w 6y 4 > global-response.json
+
+[anybody@@exchange-online]# taler-exchange-offline upload < sig-response.json
+[anybody@@exchange-online]# taler-exchange-offline upload < acct-response.json
+[anybody@@exchange-online]# taler-exchange-offline upload < fee-response.json
+[anybody@@exchange-online]# taler-exchange-offline upload < global-response.json
+@end example
+
+The following sections will discuss these steps in more depth.
+
+@menu
+* Signing the online signing keys:: 
+* Account signing:: 
+* Wire fee structure:: 
+* Auditor configuration:: 
+* Revocations:: 
+* AML Configuration:: 
+
+@end menu
 
+@node Signing the online signing keys,Account signing,,Offline Signing Setup Key Maintenance and Tear-Down
+@anchor{taler-exchange-manual keys-generation}@anchor{46}@anchor{taler-exchange-manual signing-the-online-signing-keys}@anchor{47}
+@section Signing the online signing keys
 
-Once the configuration is properly set up, all the keys can be signed using
-the offline key on the offline system by the tool @code{taler-exchange-offline}.
-To do this, one must first start the crypto helpers and the @code{taler-exchange-httpd}
-process (the tools for wire transfers may also be started, but do not have to
-run yet).
 
-Next, the @emph{future} key material should be downloaded using:
+To sign the online signing keys, first the `future' key material should be downloaded using:
 
 @example
 $ taler-exchange-offline download > future-keys.json
 @end example
 
-Afterwards, @emph{future-keys.json} contains data about denomination and
+Afterwards, `future-keys.json' contains data about denomination and
 online signing keys that the exchange operator needs to sign with
 the offline tool.  The file should be copied to the offline system.
 There, the operator should run:
@@ -1461,74 +3046,120 @@ $ taler-exchange-offline show < future-keys.json
 
 and verify that the output contains the fee structure and key lifetimes
 they expect to see. They should also note the public keys being shown
-and communicate those to the @emph{auditors} over a secure channel.  Once
+and communicate those to the `auditors' over a secure channel.  Once
 they are convinced the file is acceptable, they should run:
 
 @example
 $ taler-exchange-offline sign < future-keys.json > offline-sigs.json
 @end example
 
-The @emph{offline-sigs.json} file must then be copied to an online system
+The `offline-sigs.json' file must then be copied to an online system
 that is able to again communicate with the exchange. On that system, run:
 
 @example
 $ taler-exchange-offline upload < offline-sigs.json
 @end example
 
-to provision the signatures to the exchange.  At this point, the
-exchange will be able to use those keys, but wallets and merchants
-may not yet trust them!  Thus, the next step is for the auditor
-to affirm that they are auditing this exchange.  Details about
-this are described in taler-auditor-manual.
+to provision the signatures to the exchange.
 
-The simplistic (without using offline keys for the auditor) way
-to do this would be:
+The @code{download sign upload} sequence in the commands above has to be done
+periodically, as it signs the various online signing keys of the exchange
+which periodically expire.
 
-@example
-$ taler-auditor-offline download sign upload
-@end example
+@node Account signing,Wire fee structure,Signing the online signing keys,Offline Signing Setup Key Maintenance and Tear-Down
+@anchor{taler-exchange-manual account-signing}@anchor{48}
+@section Account signing
 
-For more information, see manpages/taler-auditor-offline.1.
 
-@node Private key storage,Database upgrades,Keys generation,Deployment
-@anchor{taler-exchange-manual private-key-storage}@anchor{30}
-@section Private key storage
+The @code{enable-account} step is important to must be used to sign the
+@code{payto://} URI in a way suitable to convince wallets that this is the
+correct address to wire funds to.  Note that for each bank account, additional
+options `must' be set in the configuration file to tell the exchange how to
+access the bank account. The offline tool `only' configures the externally
+visible portions of the setup.  The chapter on Bank account@footnote{_Bank-account} configuration has further details.
 
+taler-exchange-offline accepts additional options to configure the use of the
+account. For example, additional options can be used to add currency
+conversion or to restrict interactions to bank accounts from certain
+countries:
 
-Keeping the private keys the helpers create secret is paramount. If the
-private keys are lost, it is easy to provision fresh keys (with the help of
-the auditor).  Thus, we recommend that the private keys of the crypto helpers
-are @emph{not} backed up: in the rare event of a disk failure, they can be
-regenerated.  However, we do recommend using RAID (1+1 or 1+1+1) for all
-disks of the system.
+@example
+$ taler-exchange-offline \
+    enable-account payto://iban/CH9300762011623852957
+      conversion-url https://conversion.example.com/
+@end example
 
-@node Database upgrades,,Private key storage,Deployment
-@anchor{taler-exchange-manual database-upgrades}@anchor{31}@anchor{taler-exchange-manual id13}@anchor{32}
-@section Database upgrades
+For details on optional @code{enable-account} arguments,
+see manpages/taler-exchange-offline.1.
 
+@node Wire fee structure,Auditor configuration,Account signing,Offline Signing Setup Key Maintenance and Tear-Down
+@anchor{taler-exchange-manual id6}@anchor{49}@anchor{taler-exchange-manual wire-fee-structure}@anchor{4a}
+@section Wire fee structure
 
-Currently, there is no way to upgrade the database between Taler
-versions.
 
-The exchange database can be re-initialized using:
+@geindex wire fee
+
+@geindex fee
+
+For each wire method (“iban” or “x-taler-bank”) the
+exchange must know about applicable wire fees. This is also done
+using the @code{taler-exchange-offline} tool:
 
 @example
-$ taler-exchange-dbinit -r
+$ taler-exchange-offline wire-fee 2040 iban EUR:0.05 EUR:0.10
 @end example
 
-However, running this command will result in all data in the database
-being lost, which may result in significant financial liabilities as the
-exchange can then not detect double-spending. Hence this operation must
-not be performed in a production system.
+The above sets the wire fees for wire transfers involving @code{iban} accounts
+(in Euros) in the year 2040 to 5 cents (wire fee) and 10 cents (closing fee).
+The tool only supports setting fees that applies for the entire calendar year.
 
-@menu
-* Revocations:: 
+We recommend provisioning an exchange with wire fees at least for the next two
+years.  Note that once the fees have been set for a year, they cannot be
+changed (basically, by signing the fees the exchange makes a legally binding
+offer to the customers).
 
-@end menu
+@geindex maintenance
 
-@node Revocations,,,Database upgrades
-@anchor{taler-exchange-manual id14}@anchor{33}@anchor{taler-exchange-manual revocations}@anchor{34}
-@subsection Revocations
+@cartouche
+@quotation Note 
+Provisioning future wire fees, like provisioning future denomination
+and signing keys, are key regular maintenance procedures for every
+exchange operator.  We recommend setting automated reminders for
+this maintenance activity!
+@end quotation
+@end cartouche
+
+@node Auditor configuration,Revocations,Wire fee structure,Offline Signing Setup Key Maintenance and Tear-Down
+@anchor{taler-exchange-manual auditor-configuration}@anchor{4b}@anchor{taler-exchange-manual id7}@anchor{4c}
+@section Auditor configuration
+
+
+At this point, the exchange will be able to use those keys, but wallets and
+merchants may not yet trust them!  Thus, the next step is for an auditor to
+affirm that they are auditing this exchange.  Before an auditor can do this,
+the exchange service must be informed about any auditor that is expected to
+provision it with auditor signatures.
+
+This is also done using the @code{taler-exchange-offline} tool on the offline
+system.  First, the auditor must be configured and provide the exchange
+operator with its public key (using @code{taler-auditor-offline setup}) and the
+URL of it’s REST API.  The exchange operator also needs a human-readable name
+that may be shown to users to identify the auditor.  For more information on
+how to setup and operate an auditor, see
+manpages/taler-auditor-offline.1 and taler-auditor-manual.
+
+Given this information, the exchange operator can enable the auditor:
+
+@example
+$ taler-exchange-offline enable-auditor $PUB_KEY $REST_URL "$AUDITOR_NAME" > auditor.json
+@end example
+
+As before, the `auditor.json' file must then be copied from the offline system
+to a system connected to the exchange and there @code{uploaded} to the exchange using @code{taler-exchange-offline upload}.
+
+@node Revocations,AML Configuration,Auditor configuration,Offline Signing Setup Key Maintenance and Tear-Down
+@anchor{taler-exchange-manual id8}@anchor{4d}@anchor{taler-exchange-manual revocations}@anchor{4e}
+@section Revocations
 
 
 When an exchange goes out of business or detects that the private key of
@@ -1547,7 +3178,7 @@ value, the key revocation can be approved on the offline system:
 $ taler-exchange-offline revoke-denominatin $HDP > revocation.json
 @end example
 
-The resulting @emph{revocation.json} must be copied to a system connected to the
+The resulting `revocation.json' must be copied to a system connected to the
 exchange and uploaded to the exchange using the @code{upload} subcommand
 of @code{taler-exchange-offline}.
 
@@ -1559,39 +3190,254 @@ operation.
 @end quotation
 @end cartouche
 
-@node Testing a deployment,Diagnostics,Deployment,Top
-@anchor{taler-exchange-manual testing-a-deployment}@anchor{35}
-@chapter Testing a deployment
+@node AML Configuration,,Revocations,Offline Signing Setup Key Maintenance and Tear-Down
+@anchor{taler-exchange-manual aml-configuration}@anchor{4f}
+@section AML Configuration
+
+
+The AML configuration steps are used to add or remove keys of exchange
+operator staff that are responsible for anti-money laundering (AML)
+compliance.  These AML officers are shown suspicious transactions and are
+granted access to the KYC data of an exchange. They can then investigate the
+transaction and decide on freezing or permitting the transfer. They may also
+request additional KYC data from the consumer and can change the threshold
+amount above which a further AML review is triggered.
+
+@menu
+* AML Officer Setup:: 
+* AML Triggers:: 
+
+@end menu
+
+@node AML Officer Setup,AML Triggers,,AML Configuration
+@anchor{taler-exchange-manual aml-officer-setup}@anchor{50}
+@subsection AML Officer Setup
+
+
+To begin the AML setup, AML staff should launch the GNU Taler
+exchange AML SPA Web interface. (FIXME-Sebastian: how?). The
+SPA will generate a public-private key pair and store it in the
+local storage of the browser.  The public key will be displayed
+and must be securely transmitted to the offline system for
+approval.  Using the offline system, one can then configure
+which staff has access to the AML operations:
+
+@example
+[root@@exchange-offline]# taler-exchange-offline \
+   aml-enable $PUBLIC_KEY "Legal Name" rw > aml.json
+[root@@exchange-online]# taler-exchange-offline \
+   upload < aml.json
+@end example
+
+The above commands would add an AML officer with the given “Legal Name” with
+read-write (rw) access to the AML officer database.  Using “ro” instead of
+“rw” would grant read-only access to the data, leaving out the ability to
+actually make AML decisions.  Once AML access has been granted, the AML
+officer can use the SPA to review cases and (with “rw” access) take AML
+decisions.
+
+Access rights can be revoked at any time using:
+
+@example
+[root@@exchange-offline]# taler-exchange-offline \
+   aml-disable $PUBLIC_KEY "Legal Name" > aml-off.json
+[root@@exchange-online]# taler-exchange-offline \
+   upload < aml-off.json
+@end example
+
+@node AML Triggers,,AML Officer Setup,AML Configuration
+@anchor{taler-exchange-manual aml-triggers}@anchor{51}
+@subsection AML Triggers
+
+
+AML decision processes are automatically triggered under certain configurable
+conditions.  The primary condition that `must' be configured is the
+@code{AML_THRESHOLD}:
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-business.conf}
+
+@example
+[exchange]
+# Accounts or wallets with monthly transaction volumes above this threshold
+# are considered suspicious and are automatically flagged for AML review
+# and put on hold until an AML officer has reached a decision.
+AML_THRESHOLD = "EUR:1000000"
+@end example
+
+@end float
+
+
+Additionally, certain KYC attributes (such as the user being a
+politically exposed person) may lead to an account being
+flagged for AML review.  The specific logic is configured by
+providing the exchange with an external helper program that
+makes the decision given the KYC attributes:
+
+
+@float LiteralBlock
+
+@caption{/etc/taler/conf.d/exchange-business.conf}
+
+@example
+[exchange]
+# Specifies a program to run on KYC attribute data to decide
+# whether we should immediately flag an account for AML review.
+KYC_AML_TRIGGER = taler-exchange-kyc-aml-pep-trigger.sh
+@end example
+
+@end float
+
+
+The given program will be given the KYC attributes in JSON format on standard
+input, and must return 0 to continue without AML and non-zero to flag the
+account for manual review.  To disable this triger, simply leave the option to
+its default value of ‘[/usr/bin/]true’. To flag all new users for manual
+review, simply set the program to ‘[/usr/bin/]false’.
+
+@node Setup Linting,Testing and Troubleshooting,Offline Signing Setup Key Maintenance and Tear-Down,Top
+@anchor{taler-exchange-manual setup-linting}@anchor{52}
+@chapter Setup Linting
+
+
+The @code{taler-wallet-cli} package comes with an experimental tool that runs various
+checks on the current GNU Taler exchange deployment:
+
+@example
+[root@@exchange-online]# apt install taler-wallet-cli
+[root@@exchange-online]# taler-wallet-cli deployment lint-exchange
+@end example
+
+You can optionally pass the @code{--debug} option to get more verbose output, and
+@code{--continue} to continue with further checks even though a previous one has
+failed.
+
+@node Testing and Troubleshooting,Benchmarking,Setup Linting,Top
+@anchor{taler-exchange-manual testing-and-troubleshooting}@anchor{53}
+@chapter Testing and Troubleshooting
 
 
 We recommend testing whether an exchange deployment is functional by using the
 Taler wallet command line interface.  The tool can be used to withdraw and
 deposit electronic cash via the exchange without having to deploy and operate a
-separate merchant backend and storefront.  For more information, see
-taler-wallet-cli-manual.
+separate merchant backend and storefront.
 
-@node Diagnostics,Benchmarking,Testing a deployment,Top
-@anchor{taler-exchange-manual diagnostics}@anchor{36}@anchor{taler-exchange-manual id15}@anchor{37}
-@chapter Diagnostics
+The following shell session illustrates how the wallet can be used to withdraw
+electronic cash from the exchange and subsequently spend it.  For these steps,
+a merchant backend is not required, as the wallet acts as a merchant.
 
+@example
+# This will now output a payto URI that money needs to be sent to in order to allow withdrawal
+# of taler coins.
+$ taler-wallet-cli advanced withdraw-manually --exchange $EXCHANGE_URL --amount EUR:10.50
+@end example
 
-This chapter includes various sections on specific topics that might be
-helpful to understand how the exchange operates. The information may also be
-helpful for diagnostics.
+Show the status of the manual withdrawal operation.
+
+@example
+$ taler-wallet-cli transactions
+@end example
+
+At this point, a bank transfer to the exchange’s bank account
+needs to be made with the correct subject / remittance information
+as instructed by the wallet after the first step.  With the
+above configuration, it should take about 5 minutes after the
+wire transfer for the incoming transfer to be observed by the
+Nexus.
+
+Run the following command to check whether the exchange received
+an incoming bank transfer:
+
+@example
+[root@@exchange-online]# taler-exchange-wire-gateway-client \
+   --section exchange-accountcredentials-1 --credit-history
+@end example
+
+Once the transfer has been made, try completing the withdrawal
+using:
+
+@example
+$ taler-wallet-cli run-pending
+@end example
+
+Afterwards, check the status of transactions and show the
+current wallet balance:
+
+@example
+$ taler-wallet-cli transactions
+$ taler-wallet-cli balance
+@end example
+
+Now, we can directly deposit coins via the exchange into a target
+account.  (Usually, a payment is made via a merchant.  The wallet
+provides this functionality for testing.)
+
+@example
+$ taler-wallet-cli deposit create EUR:5 \
+  payto://iban/$IBAN?receiver-name=Name
+$ taler-wallet-cli run-pending
+@end example
+
+Check if this transaction was successful (from the perspective
+of the wallet):
+
+@example
+$ taler-wallet-cli transactions
+@end example
+
+If the transaction failed, fix any open issue(s) with the exchange and
+run the “run-pending” command.
+
+The wallet can also track if the exchange wired the money to the merchant
+account.  The “deposit group id” can be found in the output of the
+transactions list.
+
+@example
+$ taler-wallet-cli deposit track $DEPOSIT_GROUP_ID
+@end example
+
+You can also check using the exchange-tools whether the exchange sent
+the an outgoing transfer:
+
+@example
+[root@@exchange-online]# taler-exchange-wire-gateway-client \
+  --section exchange-accountcredentials-1 --debit-history
+@end example
+
+After enough time has passed, the money should arrive at the specified IBAN.
+
+For more information on the taler-wallet-cli tool, see
+taler-wallet.
 
 @menu
+* Private key storage:: 
 * Internal audits:: 
 * Database Scheme:: 
+* Database upgrades:: 
 
 @end menu
 
-@node Internal audits,Database Scheme,,Diagnostics
-@anchor{taler-exchange-manual internal-audit}@anchor{38}@anchor{taler-exchange-manual internal-audits}@anchor{39}
+@node Private key storage,Internal audits,,Testing and Troubleshooting
+@anchor{taler-exchange-manual private-key-storage}@anchor{54}
+@section Private key storage
+
+
+Keeping the private keys the helpers create secret is paramount. If the
+private keys are lost, it is easy to provision fresh keys (with the help of
+the auditor).  Thus, we recommend that the private keys of the crypto helpers
+are `not' backed up: in the rare event of a disk failure, they can be
+regenerated.  However, we do recommend using RAID (1+1 or 1+1+1) for all
+disks of the system.
+
+@node Internal audits,Database Scheme,Private key storage,Testing and Troubleshooting
+@anchor{taler-exchange-manual internal-audit}@anchor{55}@anchor{taler-exchange-manual internal-audits}@anchor{56}
 @section Internal audits
 
 
 While an exchange should use an external auditor to attest to regulators that
-it is operating correctly, an exchange operator can also use the auditor's
+it is operating correctly, an exchange operator can also use the auditor’s
 logic to perform internal checks.  For this, an exchange operator can generally
 follow the auditor guide.  However, instead of using @code{taler-auditor-sync},
 an internal audit can and likely should be performed either directly against
@@ -1603,7 +3449,7 @@ the database invariants.
 Running the auditor against a the original the production database (without
 using @code{taler-auditor-sync}) enables the auditing logic to perform a few
 additional checks that can detect inconsistencies.  These checks are enabled
-by passing the @strong{-i} option to the @code{taler-auditor} command.  As always,
+by passing the `-i' option to the @code{taler-auditor} command.  As always,
 the resulting report should be read carefully to see if there are any problems
 with the setup.
 
@@ -1613,8 +3459,8 @@ While it is possible to reset the auditor database and to restart the audit
 from the very beginning, this is generally not recommended as this may be too
 expensive.
 
-@node Database Scheme,,Internal audits,Diagnostics
-@anchor{taler-exchange-manual database-scheme}@anchor{3a}@anchor{taler-exchange-manual id16}@anchor{3b}
+@node Database Scheme,Database upgrades,Internal audits,Testing and Troubleshooting
+@anchor{taler-exchange-manual database-scheme}@anchor{57}@anchor{taler-exchange-manual id9}@anchor{58}
 @section Database Scheme
 
 
@@ -1629,75 +3475,229 @@ The database scheme used by the exchange looks as follows:
 
 @image{taler-exchange-figures/exchange-db,,,,png}
 
-@node Benchmarking,Index,Diagnostics,Top
-@anchor{taler-exchange-manual benchmarking}@anchor{3c}@anchor{taler-exchange-manual exchangebenchmarking}@anchor{3d}
-@chapter Benchmarking
-
-
-This chapter describes how to run the Taler exchange benchmark.  The benchmark
-can be used to measure the performance of the exchange by running a (possibly
-large) number of simulated clients against one Taler deployment with a bank,
-exchange and auditor.  For the bank, both a "fakebank" (@code{-f}) and a
-"Pythonbank" deployment are currently supported.  The
-@code{taler-exchange-benchmark} program can launch all required services and
-clients, or only launch the parallel clients (@code{-m}), for example for
-distributed testing over a network.
+@node Database upgrades,,Database Scheme,Testing and Troubleshooting
+@anchor{taler-exchange-manual database-upgrades}@anchor{59}@anchor{taler-exchange-manual id10}@anchor{5a}
+@section Database upgrades
 
-For each @emph{parallel} (@code{-p}) client, a number of @emph{reserves} (@code{-r}) is first established by
-@strong{transferring} money from a "user" account (42) to the Exchange's account
-with the respective reserve public key as wire subject.  Next, the
-client will @strong{withdraw} a @emph{number of coins} (@code{-n}) from the reserve and
-@strong{deposit} them. Additionally, a @emph{fraction} (@code{-R}) of the dirty coins will then be
-subject to @strong{refreshing}.  For some deposits, the auditor will receive
-@strong{deposit confirmations}.
 
-Operations that are not covered today include closing reserves, refunds and
-recoups.
+Before installing a new exchange version, you should probably make a backup of
+the existing database and study the release notes on migration.  In general,
+the way to migrate is to stop all existing Taler exchange processes and run:
 
-The existing @code{benchmark.conf} file in @code{src/benchmark/} can be used as a
-starting point for a configuration to run the benchmark. The existing
-configuration file only requires that the @code{talercheck} database already
-exists and will launch all required services locally as needed.
+@example
+$ taler-exchange-dbinit
+@end example
 
-You can run a first simple benchmark using:
+This will migrate the existing schema to the new schema. You also may need
+to grant Taler exchange processes the rights to the new tables (see last
+step of database setup).
 
 @cartouche
 @quotation Note 
-FIXME-TTN/CG: these instructions are incomplete and untested for the
-current iteration of the code...
+The `taler-exchange-dbconfig' tool can be used to automate the database
+migration. In general, simply invoking it again should trigger the
+migration including `taler-exchange-dbinit' and setting the permissions.
 @end quotation
 @end cartouche
 
+If you do not want to keep any data from the previous installation, the
+exchange database can be fully re-initialized using:
+
 @example
-$ createdb talercheck # if it does not yet exist
-$ taler-exchange-dbinit -c benchmark.conf
-$ taler-exchange-httpd -c benchmark.conf &
-$ HTTPD_PID=$!
-$ taler-exchange-offline -c benchmark.conf \
-  download sign \
-  enable-account payto://iban/CH9300762011623852957 \
-  wire-fee iban EUR:0 EUR:0 EUR:0 \
-  global-fee EUR:0 EUR:0 EUR:0 EUR:0 4w 4w 6y 4 \
-  upload
-$ kill -TERM $HTTPD_PID
-$ taler-exchange-benchmark -c benchmark.conf -p 4 -r 1 -n 10
+$ taler-exchange-dbinit --reset
 @end example
 
-This will run 4 parallel clients withdrawing 10 coins from 1 reserve and then
-depositing those coins. The default refresh probability is 10 percent.  Note
-that the tiny run should only take a few seconds, most of it will be spent in
-the setup of the original key material. For meaningful runs, all three values
-should likely be increased.
+However, running this command will result in all data in the database
+being lost, which may result in significant financial liabilities as the
+exchange can then not detect double-spending. Hence this operation must
+not be performed in a production system. You still also need to then
+grant the permissions to the other exchange processes again.
+
+@node Benchmarking,FIXMEs,Testing and Troubleshooting,Top
+@anchor{taler-exchange-manual benchmarking}@anchor{5b}@anchor{taler-exchange-manual exchangebenchmarking}@anchor{5c}
+@chapter Benchmarking
+
+
+This chapter describes how to run various benchmarks against a Taler exchange.
+These benchmark can be used to measure the performance of the exchange by
+running a (possibly large) number of simulated clients against one Taler
+deployment with a bank, exchange and (optionally) auditor.
+
+Real benchmarks that are intended to demonstrate the scalability of GNU Taler
+should not use the tools presented in this section: they may be suitable for
+microbenchmarking and tuning, but the setup is inherently not optimzied for
+performance or realism, both for the load generation and the server side.
+Thus, we do not recommend using these performance numbers to assess the
+scalability of GNU Taler.  That said, the tools can be useful to help identify
+performance issues.
+
+The @code{taler-unified-setup.sh} script can be used to launch all required
+services and clients. However, the resulting deployment is simplistic
+(everything on the local machine, one single-threaded process per service
+type) and not optimized for performance at all. However, this can still be
+useful to assess the performance impact of changes
+to the code or configuration.
+
+The various configuration files used in the code snippets in this section can
+be found in the @code{src/benchmark/} directory of the exchange. These are
+generally intended as starting points.  Note that the configuration files
+ending in @code{.edited} are created by @code{taler-unified-setup.sh} and contain
+some options that are determined at runtime by the setup logic provided by
+@code{taler-unified-setup.sh}.
+
+@menu
+* Choosing a bank:: 
+* taler-bank-benchmark:: 
+* taler-exchange-benchmark:: 
+* taler-aggregator-benchmark:: 
+
+@end menu
+
+@node Choosing a bank,taler-bank-benchmark,,Benchmarking
+@anchor{taler-exchange-manual benchmark-choose-bank}@anchor{5d}@anchor{taler-exchange-manual choosing-a-bank}@anchor{5e}
+@section Choosing a bank
+
+
+For the bank, both a fakebank (@code{-f}) and libeufin-based (@code{-ns})
+bank deployment are currently supported by all benchmark tools and
+configuration templates.
+
+Fakebank is an ultra-fast in-memory implementation of the Taler bank API. It
+is suitable when the goal is to benchmark the core GNU Taler payment system
+and to ignore the real-time gross settlement (RTGS) system typically provided
+by an existing bank.  When using the fakebank, @code{taler-unified-setup.sh} must
+be started with the @code{-f} option and be told to use the right exchange bank
+account from the configuration files via @code{-u exchange-account-1}.
+
+@example
+$ dropdb talercheck; createdb talercheck
+$ taler-unified-setup.sh -emwt -c $CONF -f -u exchange-account-1
+@end example
+
+libeufin is GNU Taler’s adapter to the core banking system using the EBICS
+banking protocol standard.  It uses a Postgres database to persist data and is
+thus much slower than fakebank.  If your GNU Taler deployment uses libeufin in
+production, it likely makes sense to benchmark with libeufin.  When using the
+fakebank, @code{taler-unified-setup.sh} must be started with the @code{-ns} options
+(starting libeufin-nexus and libeufin-sandbox) and be told to use the right
+exchange bank account from the configuration files via @code{-u
+exchange-account-2}.  Note that @code{taler-unified-setup.sh} currently cannot
+reset a libeufin database, and also will not run if the database is already
+initialized. Thus, you must re-create the database every time before
+running the command:
+
+@example
+$ dropdb talercheck; createdb talercheck
+$ taler-unified-setup.sh -emwt -c $CONF -ns -u exchange-account-2
+@end example
+
+@node taler-bank-benchmark,taler-exchange-benchmark,Choosing a bank,Benchmarking
+@anchor{taler-exchange-manual taler-bank-benchmark}@anchor{5f}
+@section taler-bank-benchmark
+
+
+This is the simplest benchmarking tool, simulating only the bank
+interaction.
+
+@example
+$ CONF="benchmark-cs.conf"
+$ # or with libeufin
+$ dropdb talercheck; createdb talercheck
+$ taler-unified-setup.sh -emwt -c "$CONF" -f -u exchange-account-1
+$ # Once <<READY>>, in another shell (remember to set $CONF):
+$ time taler-bank-benchmark -c "$CONF" -r 40 -p 4 -P4 -u exchange-account-1 -f
+$ # or with libeufin
+$ dropdb talercheck; createdb talercheck
+$ taler-unified-setup.sh -emwt -c "$CONF" -ns -u exchange-account-2
+$ # Once <<READY>>, in another shell (remember to set $CONF):
+$ time taler-bank-benchmark -c "$CONF" -r 40 -p 1 -P1 -u exchange-account-2
+@end example
+
+For each `parallel' (@code{-p}) client, a number of `reserves' (@code{-r}) is first
+established by `transferring' money from a “user” account (42) to the
+Exchange’s account with the respective reserve public key as wire subject.
+Processing is then handled by `parallel' (@code{-P}) service workers.
+
+@node taler-exchange-benchmark,taler-aggregator-benchmark,taler-bank-benchmark,Benchmarking
+@anchor{taler-exchange-manual taler-exchange-benchmark}@anchor{60}
+@section taler-exchange-benchmark
+
+
+This is the benchmarking tool simulates a number of clients withdrawing,
+depositing and refreshing coins.  Operations that are not covered by the
+@code{taler-exchange-benchmark} tool today include closing reserves, refunds,
+recoups and P2P payments.
+
+@example
+$ CONF="benchmark-cs.conf" # -rsa also makes sense
+$ # With fakebank
+$ dropdb talercheck; createdb talercheck
+$ taler-unified-setup.sh -aemwt -c "$CONF" -f -u exchange-account-1
+$ # Once <<READY>>, in another shell (remember to set $CONF):
+$ taler-exchange-benchmark -c "$CONF".edited -u exchange-account-1 -n 1 -p1 -r 5 -f
+$ #
+$ # With libeufin
+$ dropdb talercheck; createdb talercheck
+$ taler-unified-setup.sh -aemwt -c "$CONF" -ns -u exchange-account-2
+$ # Once <<READY>>, in another shell (remember to set $CONF):
+$ taler-exchange-benchmark -c "$CONF".edited -u exchange-account-2 -L WARNING -n 1 -p1 -r 5
+@end example
+
+For each `parallel' (@code{-p}) client, a number of `reserves' (@code{-r}) is first
+established by `transferring' money from a “user” account (42) to the
+Exchange’s account with the respective reserve public key as wire subject.
+Next, the client will `withdraw' a `number of coins' (@code{-n}) from the
+reserve and `deposit' them. Additionally, a `fraction' (@code{-R}) of the dirty
+coins will then be subject to `refreshing'.  For some deposits, the auditor
+will receive `deposit confirmations'.
 
 The output of @code{taler-exchange-benchmark} will include for each parallel
 client the total time spent in each of the major operations, possible
 repetitions (i.e. if the operation failed the first time), total execution
 time (operating system and user space) and other details.
 
-Naturally, additional instrumentation (including using features of the
-PostgreSQL database itself) may help discover performance issues.
+@node taler-aggregator-benchmark,,taler-exchange-benchmark,Benchmarking
+@anchor{taler-exchange-manual taler-aggregator-benchmark}@anchor{61}
+@section taler-aggregator-benchmark
+
+
+This is another simple benchmark tool that merely prepares an exchange
+database to run a stand-alone benchmark of the @code{taler-exchange-aggregator}
+tool.  After preparing a database and running the tool, you can then
+run one or more @code{taler-exchange-aggregator} processes and measure how
+quickly they perform the aggregation work.
+
+@example
+$ CONF=benchmark-rsa.conf
+$ taler-exchange-dbinit -c "$CONF" --reset
+$ ./taler-aggregator-benchmark -c "$CONF" -m 500 -r 10 -d 100
+$ time taler-exchange-aggregator -c "$CONF" --test
+@end example
+
+This above commands will first create 100 deposits with 10 refunds into each
+of 500 merchant accounts using randomized time stamps.  Afterwards, it will
+time a single aggregator process in @code{--test} mode (asking it to terminate
+as soon as there is no more pending work).
+
+@node FIXMEs,Index,Benchmarking,Top
+@anchor{taler-exchange-manual fixmes}@anchor{62}
+@chapter FIXMEs
+
+
+
+@itemize *
+
+@item 
+We should have some summary with the inventory of services that should be
+running.  Systemd by default doesn’t show this nicely.  Maybe suggest running
+“systemd list-dependencies taler-exchange.target”?
+
+@item 
+What happens when the TWG doesn’t like one particular outgoing transaction?
+How to recover from that as a sysadmin when it happens in practice?
+@end itemize
 
-@node Index,,Benchmarking,Top
+@node Index,,FIXMEs,Top
 @unnumbered Index
 
 
diff --git a/texinfo/taler-merchant-api-tutorial-figures/arch-api.png b/texinfo/taler-merchant-api-tutorial-figures/arch-api.png
index 8004f790..9e593ab4 100644
--- a/texinfo/taler-merchant-api-tutorial-figures/arch-api.png
+++ b/texinfo/taler-merchant-api-tutorial-figures/arch-api.png
diff --git a/texinfo/taler-merchant-api-tutorial-figures/exchange-db.png b/texinfo/taler-merchant-api-tutorial-figures/exchange-db.png
index f99e2664..7a4050c6 100644
--- a/texinfo/taler-merchant-api-tutorial-figures/exchange-db.png
+++ b/texinfo/taler-merchant-api-tutorial-figures/exchange-db.png
diff --git a/texinfo/taler-merchant-api-tutorial.texi b/texinfo/taler-merchant-api-tutorial.texi
index 558313fe..a06c4e93 100644
--- a/texinfo/taler-merchant-api-tutorial.texi
+++ b/texinfo/taler-merchant-api-tutorial.texi
@@ -3,7 +3,7 @@
 @setfilename taler-merchant-api-tutorial.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 3.4.3.@*
+@*Generated by Sphinx 5.3.0.@*
 @end ifinfo
 @settitle Taler Merchant API Tutorial
 @defindex ge
@@ -15,13 +15,11 @@
 * MENU ENTRY: (taler-merchant-api-tutorial.info). DESCRIPTION
 @end direntry
 
-@definfoenclose strong,`,'
-@definfoenclose emph,`,'
 @c %**end of header
 
 @copying
 @quotation
-GNU Taler 0.9.0, Nov 03, 2022
+GNU Taler 0.9.0, Sep 24, 2023
 
 GNU Taler team
 
@@ -49,7 +47,7 @@ Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 @c %**start of body
 @anchor{taler-merchant-api-tutorial doc}@anchor{0}
 @c This file is part of GNU TALER.
-@c Copyright (C) 2014-2020 Taler Systems SA
+@c Copyright (C) 2014-2023 Taler Systems SA
 @c 
 @c TALER is free software; you can redistribute it and/or modify it under the
 @c terms of the GNU Affero General Public License as published by the Free Software
@@ -71,7 +69,7 @@ Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 * Merchant Payment Processing:: 
 * Giving Refunds:: 
 * Repurchase detection and fulfillment URLs:: 
-* Giving Customers Tips:: 
+* Giving Customers Rewards:: 
 * Advanced topics:: 
 * Index:: 
 
@@ -134,7 +132,7 @@ regulation (such as GDPR).
 
 
 This tutorial addresses how to process payments using the GNU Taler merchant
-Backend.  The audience for this tutorial are @emph{developers} of merchants (such
+Backend.  The audience for this tutorial are `developers' of merchants (such
 as Web shops) that are working on integrating GNU Taler with the
 customer-facing Frontend and the staff-facing Backoffice.
 
@@ -237,12 +235,12 @@ configuration. See taler-merchant-manual.
 
 The public sandbox backend @indicateurl{https://backend.demo.taler.net/} uses an API
 key in the @code{Authorization} header. The value of this header must be
-@code{ApiKey sandbox} for the public sandbox backend.
+@code{Bearer secret-token:sandbox} for the public sandbox backend.
 
 @example
 >>> import requests
->>> requests.get("https://backend.demo.taler.net",
-...              headers=@{"Authorization": "secret-token:secret"@})
+>>> requests.get("https://backend.demo.taler.net/private/orders",
+...              headers=@{"Authorization": "Bearer secret-token:sandbox"@})
 <Response [200]>
 @end example
 
@@ -261,10 +259,10 @@ imaginary currency. Coins denominated in @code{KUDOS} can be withdrawn from
 @section Merchant Instances
 
 
-The same Taler merchant backend server can be used by multiple separate
+A single Taler merchant backend server can be used by multiple
 merchants that are separate business entities. Each of these separate
-business entities is called a @emph{merchant instance}, and is identified by
-an alphanumeric @emph{instance id}. If the instance is omitted, the instance
+business entities is assigned a `merchant instance' which is identified by
+an alphanumeric `instance id'. If the instance is omitted, the instance
 id @code{default} is assumed.
 
 The following merchant instances are configured on
@@ -314,7 +312,7 @@ to be used is simply included in the base URL of the merchant backend.
 @section Creating an Order for a Payment
 
 
-Payments in Taler revolve around an @emph{order}, which is a machine-readable
+Payments in Taler revolve around an `order', which is a machine-readable
 description of the business transaction for which the payment is to be
 made. Before accepting a Taler payment as a merchant you must create
 such an order.
@@ -362,10 +360,10 @@ A minimal Python snippet for creating an order would look like this:
 >>> body = dict(order=dict(amount="KUDOS:10",
 ...                        summary="Donation",
 ...                        fulfillment_url="https://example.com/thanks.html"),
-...             create_token=false)
+...             create_token=False)
 >>> response = requests.post("https://backend.demo.taler.net/private/orders",
 ...               json=body,
-...               headers=@{"Authorization": "secret-token:secret"@})
+...               headers=@{"Authorization": "Bearer secret-token:sandbox"@})
 <Response [200]>
 @end example
 
@@ -373,7 +371,7 @@ A minimal Python snippet for creating an order would look like this:
 
 The backend will fill in some details missing in the order, such as the
 address of the merchant instance. The full details are called the
-@emph{contract terms}.
+`contract terms'.
 
 @geindex contract terms
 
@@ -386,19 +384,23 @@ given below to include the claim token.
 @end quotation
 @end cartouche
 
-After successfully @code{POST}ing to @code{/private/orders}, an @code{order_id} will be
-returned. Together with the merchant @code{instance}, the order id uniquely
-identifies the order within a merchant backend.  Using the order ID, you
-can trivially construct the respective @code{taler://pay/} URI that must
-be provided to the wallet.  Let @code{example.com} be the domain name where
-the public endpoints of the instance are reachable. The Taler pay URI is
-then simply @code{taler://pay/example.com/$ORDER_ID/} where @code{$ORDER_ID}
-must be replaced with the ID of the order that was returned.
+After successfully @code{POST}ing to @code{/private/orders}, a JSON with just an
+@code{order_id} field with a string representing the order ID will be returned.
+If you also get a claim token, please double-check that you used the request
+as described above.
+
+Together with the merchant @code{instance}, the order id uniquely identifies the
+order within a merchant backend.  Using the order ID, you can trivially
+construct the respective @code{taler://pay/} URI that must be provided to the
+wallet.  Let @code{example.com} be the domain name where the public endpoints of
+the instance are reachable. The Taler pay URI is then simply
+@code{taler://pay/example.com/$ORDER_ID/} where @code{$ORDER_ID} must be replaced
+with the ID of the order that was returned.
 
 You can put the @code{taler://} URI as the target of a link to open the Taler
 wallet via the @code{taler://} schema, or put it into a QR code.  However, for a
 Web shop, the easiest way is to simply redirect the browser to
-@code{https://example.com/orders/$ORDER_ID/}.  That page will then trigger the
+@code{https://example.com/orders/$ORDER_ID}.  That page will then trigger the
 Taler wallet. Here the backend generates the right logic to trigger the
 wallet, supporting the various types of Taler wallets in existence.  Instead
 of constructing the above URL by hand, it is best to obtain it by checking for
@@ -410,11 +412,11 @@ the payment status as described in the next section.
 
 
 Given the order ID, the status of a payment can be checked with the
-@code{/private/orders/$ORDER_ID/} endpoint. If the payment is yet to be completed
+@code{/private/orders/$ORDER_ID} endpoint. If the payment is yet to be completed
 by the customer, @code{/private/orders/$ORDER_ID} will give the frontend a URL
 (under the name @code{payment_redirect_url}) that will trigger the customer’s
 wallet to execute the payment. This is basically the
-@code{https://example.com/orders/$ORDER_ID/} URL we discussed above.
+@code{https://example.com/orders/$ORDER_ID} URL we discussed above.
 
 Note that the best way to obtain the @code{payment_redirect_url} is to check the
 status of the payment, even if you know that the user did not pay yet.  There
@@ -424,7 +426,7 @@ backend to do it is the safest method.
 @example
 >>> import requests
 >>> r = requests.get("https://backend.demo.taler.net/private/orders/" + order_id,
-...                  headers=@{"Authorization": "secret-token:secret"@})
+...                  headers=@{"Authorization": "Bearer secret-token:sandbox"@})
 >>> print(r.json())
 @end example
 
@@ -453,7 +455,7 @@ the merchant’s obligations under the contract.
 @cartouche
 @quotation Note 
 You do not need to keep querying to notice changes
-to the order's transaction status.  The endpoints
+to the order’s transaction status.  The endpoints
 support long polling, simply specify a @code{timeout_ms}
 query parameter with how long you want to wait at most
 for the order status to change to @code{paid}.
@@ -488,7 +490,7 @@ The refund request JSON object has only two fields:
 @code{refund}: Amount to be refunded. If a previous refund was authorized
 for the same order, the new amount must be higher, otherwise the
 operation has no effect. The value indicates the total amount to be
-refunded, @emph{not} an increase in the refund.
+refunded, `not' an increase in the refund.
 
 @item 
 @code{reason}: Human-readable justification for the refund. The reason is
@@ -508,14 +510,14 @@ This code snipped illustrates giving a refund:
 ...                   reason="Customer did not like the product")
 >>> requests.post("https://backend.demo.taler.net/private/orders/"
 ...               + order_id + "/refund", json=refund_req,
-...               headers=@{"Authorization": "secret-token:secret"@})
+...               headers=@{"Authorization": "Bearer secret-token:sandbox"@})
 <Response [200]>
 @end example
 
 @cartouche
 @quotation Note 
 After granting a refund, the public
-@code{https://example.com/orders/$ORDER_ID/} endpoint will
+@code{https://example.com/orders/$ORDER_ID} endpoint will
 change its wallet interaction from requesting payment to
 offering a refund.  Thus, frontends may again redirect
 browsers to this endpoint.  However, to do so, a
@@ -529,7 +531,7 @@ under the @code{h_contract} field.
 
 @geindex repurchase
 
-@node Repurchase detection and fulfillment URLs,Giving Customers Tips,Giving Refunds,Top
+@node Repurchase detection and fulfillment URLs,Giving Customers Rewards,Giving Refunds,Top
 @anchor{taler-merchant-api-tutorial repurchase}@anchor{10}@anchor{taler-merchant-api-tutorial repurchase-detection-and-fulfillment-urls}@anchor{11}
 @chapter Repurchase detection and fulfillment URLs
 
@@ -544,15 +546,15 @@ for the article again. If the customer then opens the @code{taler://} link in th
 wallet that did previously pay for the article (for example by scanning the QR
 code on the desktop with the Android App), the wallet will claim the contract,
 detect that the fulfillment URL is identical to one that it already has made a
-payment for in the past, and initiate @strong{repurchase redirection}: Here, the
+payment for in the past, and initiate `repurchase redirection': Here, the
 wallet will contact the merchant and replay the previous payment, except this
 time using the (current) session ID of the browser (it learns the session ID
 from the QR code).
 
 The merchant backend then updates the session ID of the existing order to
 the current session ID of the browser.  When the payment status for the
-"new" unpaid order is checked (or already in long-polling), the backend
-detects that for the browser's @emph{session ID} and @emph{fulfillment URL} there is an
+“new” unpaid order is checked (or already in long-polling), the backend
+detects that for the browser’s `session ID' and `fulfillment URL' there is an
 existing paid contract. It then tells the browser to immediately redirect to
 the fulfillment URL where the already paid article is available.
 
@@ -565,81 +567,79 @@ the same digital product where repurchase detection is desired.
 Note that changing the session ID to a different device requires the
 involvement of the wallet that made the payment, thus reasonably limiting the
 possibility of broadly sharing the digital purchases.  Repurchase detection is
-also @emph{only} done for HTTP(S) fulfillment URLs. In particular, this means
+also `only' done for HTTP(S) fulfillment URLs. In particular, this means
 fulfillment URIs like @code{taler://fulfillment-success/$MESSAGE} are not
 considered to identify a resource you can pay for and thus do not have to be
 unique.
-@anchor{taler-merchant-api-tutorial giving-customers-tips}@anchor{12}
-@geindex tips
+@anchor{taler-merchant-api-tutorial giving-customers-rewards}@anchor{12}
+@geindex rewards
 
-@node Giving Customers Tips,Advanced topics,Repurchase detection and fulfillment URLs,Top
-@anchor{taler-merchant-api-tutorial id4}@anchor{13}
-@chapter Giving Customers Tips
+@node Giving Customers Rewards,Advanced topics,Repurchase detection and fulfillment URLs,Top
+@anchor{taler-merchant-api-tutorial id3}@anchor{13}
+@chapter Giving Customers Rewards
 
 
-GNU Taler allows Web sites to grant small amounts directly to the
-visitor. The idea is that some sites may want incentivize actions such
-as filling out a survey or trying a new feature. It is important to note
-that tips are not enforceable for the visitor, as there is no contract.
-It is simply a voluntary gesture of appreciation of the site to its
-visitor. However, once a tip has been granted, the visitor obtains full
-control over the funds provided by the site.
+GNU Taler allows Web sites to grant digital cash directly to a visitor. The
+idea is that some sites may want incentivize actions such as filling out a
+survey or trying a new feature. It is important to note that receiving rewards is
+not enforceable for the visitor, as there is no contract.  It is simply a
+voluntary gesture of appreciation of the site to its visitor. However, once a
+reward has been granted, the visitor obtains full control over the funds provided
+by the site.
 
-The “merchant” backend of the site must be properly configured for
-tipping, and sufficient funds must be made available for tipping See
-Taler Merchant Operating Manual.
+The merchant backend of the site must be properly configured for rewards, and
+sufficient funds must be made available for rewards. See the Taler User
+Guide for details.
 
-To check if tipping is configured properly and if there are sufficient
-funds available for tipping, query the @code{/tip-query} endpoint:
+To check if rewards are configured properly and if there are sufficient
+funds available for granting rewards, query the @code{/private/reserves} endpoint:
 
 @example
 >>> import requests
->>> requests.get("https://backend.demo.taler.net/tip-query?instance=default",
-...              headers=@{"Authorization": "secret-token:secret"@})
+>>> requests.get("https://backend.demo.taler.net/private/reserves",
+...              headers=@{"Authorization": "Bearer secret-token:sandbox"@})
 <Response [200]>
 @end example
-@anchor{taler-merchant-api-tutorial authorize-tip}@anchor{14}
-To authorize a tip, @code{POST} to @code{/tip-authorize}. The following fields
+
+Check that a reserve exists where the @code{merchant_initial_amount} is below the
+@code{committed_amount} and that the reserve is @code{active}.
+@anchor{taler-merchant-api-tutorial authorize-reward}@anchor{14}
+To authorize a reward, @code{POST} to @code{/private/rewards}. The following fields
 are recognized in the JSON request object:
 
 
 @itemize -
 
 @item 
-@code{amount}: Amount that should be given to the visitor as a tip.
-
-@item 
-@code{instance}: Merchant instance that grants the tip (each instance may
-have its own independent tipping funds configured).
+@code{amount}: Amount that should be given to the visitor as a reward.
 
 @item 
-@code{justification}: Description of why the tip was granted. Human-readable
+@code{justification}: Description of why the reward was granted. Human-readable
 text not exposed to the customer, but used by the Back Office.
 
 @item 
 @code{next_url}: The URL that the user’s browser should be redirected to by
-the wallet, once the tip has been processed.
+the wallet, once the reward has been processed.
 @end itemize
 
-The response from the backend contains a @code{tip_redirect_url}. The
+The response from the backend contains a @code{taler_reward_url}. The
 customer’s browser must be redirected to this URL for the wallet to pick
-up the tip.
-@anchor{taler-merchant-api-tutorial pick-up-tip}@anchor{15}
-This code snipped illustrates giving a tip:
+up the reward.
+@anchor{taler-merchant-api-tutorial pick-up-reward}@anchor{15}
+This code snipped illustrates giving a reward:
 
 @example
 >>> import requests
->>> tip_req = dict(amount="KUDOS:0.5",
-...                instance="default",
+>>> reward_req = dict(amount="KUDOS:0.5",
 ...                justification="User filled out survey",
 ...                next_url="https://merchant.com/thanks.html")
->>> requests.post("https://backend.demo.taler.net/tip-authorize", json=tip_req,
-...              headers=@{"Authorization": "secret-token:secret"@})
+>>> requests.post("https://backend.demo.taler.net/private/rewards", json=reward_req,
+...              headers=@{"Authorization": "Bearer secret-token:sandbox"@})
 <Response [200]>
 @end example
 
-@node Advanced topics,Index,Giving Customers Tips,Top
-@anchor{taler-merchant-api-tutorial advanced-topics}@anchor{16}@anchor{taler-merchant-api-tutorial id6}@anchor{17}
+@node Advanced topics,Index,Giving Customers Rewards,Top
+@anchor{taler-merchant-api-tutorial advanced-topics}@anchor{16}@anchor{taler-merchant-api-tutorial id4}@anchor{17}
 @chapter Advanced topics
 
 
@@ -688,7 +688,7 @@ receipt is in the user’s wallet is also available as @code{last_session_id}
 in the response to @code{/check-payment}.
 
 @node Product Identification,The Taler Order Format,Session-Bound Payments,Advanced topics
-@anchor{taler-merchant-api-tutorial id8}@anchor{1a}@anchor{taler-merchant-api-tutorial product-identification}@anchor{1b}
+@anchor{taler-merchant-api-tutorial id5}@anchor{1a}@anchor{taler-merchant-api-tutorial product-identification}@anchor{1b}
 @section Product Identification
 
 
@@ -709,7 +709,7 @@ contract with the same @code{resource_url} before, and if so replay the
 previous payment.
 
 @node The Taler Order Format,,Product Identification,Advanced topics
-@anchor{taler-merchant-api-tutorial id9}@anchor{1c}@anchor{taler-merchant-api-tutorial the-taler-order-format}@anchor{1d}
+@anchor{taler-merchant-api-tutorial id6}@anchor{1c}@anchor{taler-merchant-api-tutorial the-taler-order-format}@anchor{1d}
 @section The Taler Order Format
 
 
diff --git a/texinfo/taler-merchant-figures/arch-api.png b/texinfo/taler-merchant-figures/arch-api.png
index 8004f790..9e593ab4 100644
--- a/texinfo/taler-merchant-figures/arch-api.png
+++ b/texinfo/taler-merchant-figures/arch-api.png
diff --git a/texinfo/taler-merchant-figures/exchange-db.png b/texinfo/taler-merchant-figures/exchange-db.png
index f99e2664..7a4050c6 100644
--- a/texinfo/taler-merchant-figures/exchange-db.png
+++ b/texinfo/taler-merchant-figures/exchange-db.png
diff --git a/texinfo/taler-merchant.texi b/texinfo/taler-merchant.texi
index a8396143..997f2073 100644
--- a/texinfo/taler-merchant.texi
+++ b/texinfo/taler-merchant.texi
@@ -3,7 +3,7 @@
 @setfilename taler-merchant.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 3.4.3.@*
+@*Generated by Sphinx 5.3.0.@*
 @end ifinfo
 @settitle Taler Merchant Manual
 @defindex ge
@@ -15,13 +15,11 @@
 * MENU ENTRY: (taler-merchant.info). DESCRIPTION
 @end direntry
 
-@definfoenclose strong,`,'
-@definfoenclose emph,`,'
 @c %**end of header
 
 @copying
 @quotation
-GNU Taler 0.9.0, Nov 03, 2022
+GNU Taler 0.9.0, Sep 24, 2023
 
 GNU Taler team
 
@@ -48,6 +46,23 @@ Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 
 @c %**start of body
 @anchor{taler-merchant-manual doc}@anchor{0}
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
+
 @menu
 * Introduction:: 
 * Terminology:: 
@@ -57,9 +72,7 @@ Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 * Secure setup:: 
 * Customization:: 
 * Upgrade procedure:: 
-* Tipping visitors:: 
 * Advanced topics:: 
-* Advanced experimental features:: 
 * Temporarily Abandoned Features:: 
 * Index:: 
 
@@ -75,27 +88,19 @@ Introduction
 Terminology
 
 * Instances:: 
-* Accounts:: 
+* Instance Bank Accounts:: 
 * Inventory:: 
 * Orders and Contracts:: 
 * Transfers:: 
-* Tipping:: 
+* Rewards:: 
 * Reserves:: 
 
 Installation
 
-* Generic instructions for installation from source:: 
+* Installing from source:: 
 * Installing the GNU Taler binary packages on Debian:: 
 * Installing the GNU Taler binary packages on Trisquel:: 
 * Installing the GNU Taler binary packages on Ubuntu:: 
-* Installing Taler on Debian GNU/Linux from source:: 
-
-Generic instructions for installation from source
-
-* Installation of dependencies:: 
-* Installing GNUnet:: 
-* Installing the GNU Taler exchange:: 
-* Installing the GNU Taler merchant backend:: 
 
 How to configure the merchant’s backend
 
@@ -111,13 +116,10 @@ Backend options
 * Currency:: 
 * Database:: 
 * Exchange:: 
-* Auditor:: 
 
 Instance setup
 
-* KUDOS Accounts:: 
-* IBAN Accounts:: 
-* Setup:: 
+* Setup without the Web interface:: 
 
 Secure setup
 
@@ -131,43 +133,37 @@ Reverse proxy configuration
 * Nginx:: 
 * Apache:: 
 
-Access control
+Status code remapping
 
 * Nginx: Nginx<2>. 
 * Apache: Apache<2>. 
 
-Status code remapping
-
-* Nginx: Nginx<3>. 
-* Apache: Apache<3>. 
-
 Customization
 
-* Templates:: 
+* Legal conditions for using the service:: 
+* Terms of Service:: 
+* Privacy Policy:: 
+* Legal policies directory layout:: 
+* Generating the Legal Terms:: 
+* Adding translations:: 
+* Updating legal documents:: 
+* Mustach HTML Templates:: 
 * Static files:: 
 * Internationalization:: 
 * Limitations:: 
 
-Tipping visitors
+Legal policies directory layout
 
-* Fund the reserve:: 
-* Authorize a tip:: 
-* Picking up of the tip:: 
+* Example:: 
 
 Advanced topics
 
 * Database Scheme:: 
-* Configuration format: Configuration format<2>. 
-
-Configuration format
-
-* Using taler-config: Using taler-config<2>. 
+* Benchmarking:: 
 
-Advanced experimental features
+Benchmarking
 
-* Benchmarking:: 
-* Benchmark setup:: 
-* Running the benchmark command:: 
+* Running taler-merchant-benchmark:: 
 
 Temporarily Abandoned Features
 
@@ -177,7 +173,7 @@ Temporarily Abandoned Features
 @end menu
 
 @node Introduction,Terminology,Top,Top
-@anchor{taler-merchant-manual ffoobar}@anchor{1}@anchor{taler-merchant-manual gnu-taler-merchant-backend-operator-manual}@anchor{2}@anchor{taler-merchant-manual introduction}@anchor{3}
+@anchor{taler-merchant-manual gnu-taler-merchant-backend-operator-manual}@anchor{1}@anchor{taler-merchant-manual introduction}@anchor{2}@anchor{taler-merchant-manual taler-merchant-backend-operator-manual}@anchor{3}
 @chapter Introduction
 
 
@@ -193,6 +189,21 @@ Temporarily Abandoned Features
 @section About GNU Taler
 
 
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+
 GNU Taler is an open protocol for an electronic payment system with a
 free software reference implementation. GNU Taler offers secure, fast
 and easy payment processing using well understood cryptographic
@@ -202,19 +213,13 @@ GNU Taler is compatible with anti-money-laundering (AML) and
 know-your-customer (KYC) regulation, as well as data protection
 regulation (such as GDPR).
 
-GNU Taler is not yet production-ready: after following this manual you
-will have a backend that can process payments in “KUDOS”, but not
-regular currencies. This is not so much because of limitations in the
-backend, but because we are not aware of a Taler exchange operator
-offering regular currencies today.
-
 @node About this manual,Architecture overview,About GNU Taler,Introduction
 @anchor{taler-merchant-manual about-this-manual}@anchor{5}@anchor{taler-merchant-manual id1}@anchor{6}
 @section About this manual
 
 
 This manual targets system administrators who want to install a GNU
-Taler merchant @emph{backend}.
+Taler merchant `backend'.
 
 We expect some moderate familiarity with the compilation and
 installation of Free Software packages. An understanding of cryptography
@@ -241,11 +246,11 @@ operating a basic backend.
 @geindex KUDOS
 
 Taler is a pure payment system, not a new crypto-currency. As such, it
-operates in a traditional banking context. In particular, this means
-that in order to receive funds via Taler, the merchant must have a
-regular bank account, and payments can be executed in ordinary
-currencies such as USD or EUR. For testing purposes, Taler uses a
-special currency “KUDOS” and includes its own special bank.
+operates in a traditional banking context. In particular, this means that in
+order to receive funds via Taler, the merchant must have a regular bank
+account, and payments can be executed in ordinary currencies such as USD or
+EUR.  Taler can also be used as a regional currency; for such scenarios, the
+Taler system also includes its own stand-alone bank.
 
 @geindex frontend
 
@@ -257,14 +262,13 @@ special currency “KUDOS” and includes its own special bank.
 
 @geindex PostgreSQL
 
-The Taler software stack for a merchant consists of four main
-components:
+The Taler software stack for a merchant consists of four main components:
 
 
 @itemize -
 
 @item 
-A @emph{frontend} which interacts with the customer’s browser. The frontend
+A `frontend' which interacts with the customer’s browser. The frontend
 enables the customer to build a shopping cart and place an order.
 Upon payment, it triggers the respective business logic to satisfy
 the order. This component is not included with Taler, but rather
@@ -273,7 +277,7 @@ The Merchant API Tutorial gives an
 introduction for how to integrate Taler with Web shop frontends.
 
 @item 
-A @emph{back-office} application that enables the shop operators to view
+A `back-office' application that enables the shop operators to view
 customer orders, match them to financial transfers, and possibly
 approve refunds if an order cannot be satisfied. This component is
 not included with Taler, but rather assumed to exist at the
@@ -282,12 +286,12 @@ the API specification that should be reviewed to integrate such a
 back-office with the Taler backend.
 
 @item 
-A Taler-specific payment @emph{backend} which makes it easy for the frontend
+A Taler-specific payment `backend' which makes it easy for the frontend
 to process financial transactions with Taler. This manual primarily
 describes how to install and configure this backend.
 
 @item 
-A @emph{DBMS} which stores the transaction history for the Taler backend.
+A `DBMS' which stores the transaction history for the Taler backend.
 For now, the GNU Taler reference implementation only supports
 PostgreSQL, but the code could be easily extended to support another
 DBMS.  Please review the PostgreSQL documentation for details on
@@ -307,12 +311,12 @@ Taler exchange over the Internet. The frontend accesses the backend via a
 RESTful API. As a result, the frontend never has to directly communicate with
 the exchange, and also does not deal with sensitive data. In particular, the
 merchant’s signing keys and bank account information are encapsulated within
-the Taler backend.
+the Taler merchant backend.
 
 A typical deployment will additionally include a full-blown Web server (like
 Apache or Nginx). Such a Web server would be responsible for TLS termination and
 access control to the @code{/private/} and @code{/management/} API endpoints of the
-merchant backend. Please carefully review the section on @ref{9,,Secure setup} before deploying a Taler merchant backend to production.
+merchant backend. Please carefully review the section on @ref{9,,secure setup} before deploying a Taler merchant backend into production.
 
 @node Terminology,Installation,Introduction,Top
 @anchor{taler-merchant-manual terminology}@anchor{a}
@@ -323,41 +327,67 @@ This chapter describes some of the key concepts used throughout the manual.
 
 @menu
 * Instances:: 
-* Accounts:: 
+* Instance Bank Accounts:: 
 * Inventory:: 
 * Orders and Contracts:: 
 * Transfers:: 
-* Tipping:: 
+* Rewards:: 
 * Reserves:: 
 
 @end menu
 
-@node Instances,Accounts,,Terminology
+@node Instances,Instance Bank Accounts,,Terminology
 @anchor{taler-merchant-manual instances}@anchor{b}
 @section Instances
 
 
 @geindex instance
 
-The backend allows the user to run multiple @emph{instances} of shops with distinct
-business entities sharing a single backend. Each instance uses its own bank
-accounts and key for signing contracts. All major accounting functionality is
-separate per instance.  What is shared is the database, HTTP(S) address and
-the main Taler configuration (accepted currency, exchanges and auditors).
+The backend allows a single HTTP server to support multiple independent shops
+with distinct business entities sharing a single backend.  An `instance' is
+the name or identifier that allows the single HTTP server to determine which
+shop a request is intended for.  Each instance has its own base URL in the
+REST API of the merchant backend (@code{/instances/$INSTANCE/}).  Each instance
+can use its own bank accounts and keys for signing contracts. All major
+accounting functionality is separate per instance.  Access to each instance is
+controlled via a bearer token (to be set in the HTTP “Authorization” header).
+All instances share the same `database', top-level HTTP(S) address and the
+main Taler configuration (especially the accepted `currency' and `exchanges').
 
-@node Accounts,Inventory,Instances,Terminology
-@anchor{taler-merchant-manual accounts}@anchor{c}
-@section Accounts
+@quotation
+
+@cartouche
+@quotation Note 
+This documentation does not use the term “user” or “username” in
+conjunction with instances as that might create confusion between
+instances with paying customers using the system.  We also do not use the
+term “account” in conjunction with instances, as that might cause
+confusion with bank accounts.  That said, conceptually it is of course
+acceptable to consider instances to be the “users” or “accounts” of a
+merchant backend and the bearer token is equivalent to a passphrase.
+@end quotation
+@end cartouche
+@end quotation
+
+@node Instance Bank Accounts,Inventory,Instances,Terminology
+@anchor{taler-merchant-manual instance-bank-accounts}@anchor{c}
+@section Instance Bank Accounts
 
 
-@geindex account
+@geindex instance-bank-account
 
 To receive payments, an instance must have configured one or more bank
-@emph{accounts}.  The backend does not have accounts for users, and instances are
-also not really 'accounts'. So whenever we use the term @emph{account}, it is about
-a bank account of a merchant.
+`accounts'.  When configuring the bank account of an instance, one should
+ideally also provide the address and credentials of an HTTP service
+implementing the Taler Bank Merchant HTTP API@footnote{taler-bank-merchant-http-api}.  Given such a service, the GNU Taler
+merchant backend can automatically reconcile wire transfers from the
+exchange to the merchant’s bank account with the orders that are being
+settled.
 
-@node Inventory,Orders and Contracts,Accounts,Terminology
+This documentation exclusively uses the term `account' for the bank
+accounts of a merchant or shop that may be associated with an instance.
+
+@node Inventory,Orders and Contracts,Instance Bank Accounts,Terminology
 @anchor{taler-merchant-manual inventory}@anchor{d}
 @section Inventory
 
@@ -373,17 +403,20 @@ a bank account of a merchant.
 @geindex order
 
 The Taler backend offers inventory management as an optional function.
-Inventory is tracked per instance and consists of @emph{products} sold in
-@emph{units}. Inventory can be finite or infinite (for digital products).
-Products may include previews (images) to be shown to the user and other
-meta-data. Inventory management allows the frontend to @emph{lock} products,
-reserving them for a particular (unpaid) @emph{order}. The backend can keep
-track of how many units of a product remain in stock and ensure that
-the number of units sold does not exceed the number of units in stock.
+Inventory is tracked per instance and consists of `products' sold in
+`units'. Inventory can be finite (physical stock) or infinite (for digital
+products).  Products may include previews (images) to be shown to the user as
+well as other meta-data. Inventory management allows the frontend to `lock'
+products, reserving a number of units from stock for a particular (unpaid)
+`order'. The backend can keep track of how many units of a product remain in
+stock and ensure that the number of units sold does not exceed the number of
+units in stock.
 
 Inventory management is optional, and it is possible for the frontend to
-include products in orders that are not in the inventory, or to override
-prices of products in the inventory.
+include products in orders that are not in the inventory. The frontend
+can also override prices of products in the inventory or set a total price
+for an order that is different from the price of the sum of the products
+in the order.
 
 @node Orders and Contracts,Transfers,Inventory,Terminology
 @anchor{taler-merchant-manual orders-and-contracts}@anchor{e}
@@ -392,6 +425,8 @@ prices of products in the inventory.
 
 @geindex order
 
+@geindex terms
+
 @geindex contract
 
 @geindex claim
@@ -406,10 +441,14 @@ prices of products in the inventory.
 
 @geindex legal expiration
 
-In Taler, users pay merchants for orders. An order is first created by the
-merchant, where the merchant specifies the specific terms of the order.
+In Taler, users pay merchants for `orders'. An order is first created by the
+merchant. To create an order, the merchant must specify the specific `terms'
+of the order.  Order `terms' include details such as the total amount to be
+paid, payment fees the merchant is willing to cover, the set of products to
+deliver, a delivery location and many other details.  The merchant API specification@footnote{contract-terms} specifies the full set of possible order
+terms.
 
-After an order is created, it is @emph{claimed} by a wallet. Once an order is
+After an order is created, it is `claimed' by a wallet. Once an order is
 claimed by a specific wallet, only that wallet will be able to pay for this
 order, to the exclusion of other wallets even if they see the same order URL.
 Sharing order URLs is explicitly allowed: if a user shares an order URL
@@ -417,39 +456,42 @@ with another user, that other user should be given the opportunity to
 purchase the same product.
 
 To prevent unauthorized wallets from claiming an order, merchants can specify
-that claims require authorization in the form of a @emph{claim token}. This is
+that claims require authorization in the form of a `claim token'. This is
 useful in case the order ID is predictable (say because an existing order ID
-scheme from the merchant frontend is used) and at the same time malicious
-actors claiming orders is problematic (say because of limited stocks). The use
-of claim tokens is optional, but if a claim token is used, it must be provided
-to the wallet as part of the order URI.
-
-Additionally, when stocks are limited, you can configure Taler to
-set a @emph{product lock} on items (say, while composing the shopping cart).
-These locks, as well as the @emph{order lock} (when the order is complete),
-can be configured to auto-unlock at certain times.
-
-@c FIXME: Is "can be configured" correct?  (Are there controls surfaced?)
-
-A wallet may @emph{pay} for a claimed order, at which point the order turns into
-a (paid) contract.  Orders have an expiration date after which the commercial
-offer expires and any stock of products @emph{locked} by the order is released,
-allowing the stock to be sold in other orders.
+scheme with predictable order IDs from the merchant frontend is used) and at
+the same time malicious actors claiming orders is problematic (say because of
+limited stocks). The use of claim tokens is optional, but if a claim token is
+used, it must be provided to the wallet as part of the order URI.
+
+Additionally, when stocks are limited, you can configure Taler to set a
+`product lock' on items (say, while composing the shopping cart).  These
+locks will ensure that the limited stock is respected when making offers
+to consumers.
+
+A wallet may `pay' for a claimed order, at which point the order turns into a
+(paid) `contract'.  Orders have a configurable expiration date (the
+@code{pay_deadline}) after which the commercial offer expires and any stock of
+products `locked' by the order will be automatically released, allowing the
+stock to be sold in other orders.  When an unpaid order expires, the customer
+must request a fresh order if they still want to make a purchase.
 
 Once a contract has been paid, the merchant should fulfill the contract.  It
-is possible for the merchant to @emph{refund} a contract order, for example if the
+is possible for the merchant to `refund' a contract order, for example if the
 contract cannot be fulfilled after all. Refunds are only possible after the
-customer paid and before the exchange has @emph{wired} the payment to the
+customer paid and before the exchange has `wired' the payment to the
 merchant. Once the funds have been wired, refunds are no longer allowed by the
-Taler exchange.  The @emph{wire deadline} specifies the latest time by which an
-exchange must wire the funds, while the (earlier) @emph{refund deadline} specifies
-the earliest time when an exchange may wire the funds.
-
-Contract information is kept for legal reasons, typically to provide tax
-records in case of a tax audit.  After the @emph{legal expiration} (by default a
-decade), contract information is deleted.
-
-@node Transfers,Tipping,Orders and Contracts,Terminology
+Taler exchange.  The `wire deadline' specifies the latest point in time by
+which an exchange must wire the funds, while the (earlier) `refund deadline'
+specifies the earliest point in time when an exchange may wire the funds.
+Thus, refunds are always possible between the time of purchase and the
+refund deadline, but may remain possible until the wire deadline.
+
+Contract information is kept for legal reasons in the merchant database.  The
+main legal reason is typically to provide tax records in case of a tax audit.
+After the `legal expiration' (by default: a decade), contract information is
+deleted when running the garbage collector using @code{taler-merchant-dbinit}.
+
+@node Transfers,Rewards,Orders and Contracts,Terminology
 @anchor{taler-merchant-manual transfers}@anchor{f}
 @section Transfers
 
@@ -459,33 +501,43 @@ decade), contract information is deleted.
 @geindex wire transfer
 
 The Taler backend can be used to verify that the exchange correctly wired all
-of the funds to the merchant. However, the backend does not have access to the
-incoming wire transfers of the merchant's bank account. Thus, merchants must
-manually provide the backend with wire @emph{transfer} data that specifies the wire
-transfer subject and the amount that was received. Given this information, the
-backend can detect and report any irregularities that might arise.
+of the funds to the merchant. However, if no Taler Bank Merchant HTTP API@footnote{taler-bank-merchant-http-api} was provided for the respective bank account,
+the backend does not have access to the incoming wire transfers of the
+merchant’s bank account. In this case, merchants must manually provide the
+backend with wire `transfer' data that specifies the `wire transfer subject'
+and the amount that was received. Given this information, the backend can
+detect and report any irregularities that might arise.
 
-@node Tipping,Reserves,Transfers,Terminology
-@anchor{taler-merchant-manual tipping}@anchor{10}
-@section Tipping
+@node Rewards,Reserves,Transfers,Terminology
+@anchor{taler-merchant-manual rewards}@anchor{10}
+@section Rewards
 
 
-@geindex tip
-
-@geindex grant
+@geindex reward
 
 @geindex pick up
 
 Taler does not only allow a Website to be paid, but also to make voluntary,
-non-contractual payments to visitors, called @emph{tips}.  Such tips could be
+non-contractual payments to visitors, called `rewards'.  Such rewards could be
 granted as a reward for filling in surveys or watching advertizements. For
-tips, there is no contract, tips are always voluntary actions by the Web
+rewards, there is no contract, rewards are always voluntary actions by the Web
 site that do not arise from a contractual obligation.  Before a Web site
-can create tips, it must establish a reserve.  Once a reserve has been
-established, the merchant can @emph{grant} tips, allowing wallets to @emph{pick up}
-the tip.
+can create rewards, it must establish a reserve.  Once a reserve has been
+established, the merchant can `grant' rewards, allowing wallets to `pick up'
+the reward.
+
+@quotation
+
+..note:
+
+@example
+Rewards are an optional feature, and exchanges may disable rewards (usually
+if they see compliance issues). In this case, the reward feature will
+not be available.
+@end example
+@end quotation
 
-@node Reserves,,Tipping,Terminology
+@node Reserves,,Rewards,Terminology
 @anchor{taler-merchant-manual reserves}@anchor{11}
 @section Reserves
 
@@ -494,14 +546,17 @@ the tip.
 
 @geindex close
 
-A @emph{reserve} is a pool of electronic cash at an exchange under the control of
+A `reserve' is a pool of electronic cash at an exchange under the control of
 a private key.  Merchants withdraw coins from a reserve when granting
-tips.  A reserve is established by first generating the required key material
+rewards.  A reserve is established by first generating the required key material
 in the merchant backend, and then wiring the desired amount of funds to the
 exchange.
 
-An exchange will automatically @emph{close} a reserve after a fixed period of time
+An exchange will automatically `close' a reserve after a fixed period of time
 (typically about a month), wiring any remaining funds back to the merchant.
+While exchange APIs exists to (1) explicitly `open' a reserve to prevent it
+from being automatically closed and to (2) explicitly `close' a reserve at any
+time, the current merchant backend does not make use of these APIs.
 
 @node Installation,How to configure the merchant’s backend,Terminology,Top
 @anchor{taler-merchant-manual installation}@anchor{12}
@@ -511,48 +566,57 @@ An exchange will automatically @emph{close} a reserve after a fixed period of ti
 This chapter describes how to install the GNU Taler merchant backend.
 
 @menu
-* Generic instructions for installation from source:: 
+* Installing from source:: 
 * Installing the GNU Taler binary packages on Debian:: 
 * Installing the GNU Taler binary packages on Trisquel:: 
 * Installing the GNU Taler binary packages on Ubuntu:: 
-* Installing Taler on Debian GNU/Linux from source:: 
-
-@end menu
-
-@node Generic instructions for installation from source,Installing the GNU Taler binary packages on Debian,,Installation
-@anchor{taler-merchant-manual generic-instructions}@anchor{13}@anchor{taler-merchant-manual generic-instructions-for-installation-from-source}@anchor{14}
-@section Generic instructions for installation from source
-
-
-This section provides generic instructions for the merchant backend
-installation independent of any particular operating system. Operating
-system specific instructions are provided in the following sections. You
-should follow the operating system specific instructions if those are
-available, and only consult the generic instructions if no
-system-specific instructions are provided for your specific operating
-system.
-
-@menu
-* Installation of dependencies:: 
-* Installing GNUnet:: 
-* Installing the GNU Taler exchange:: 
-* Installing the GNU Taler merchant backend:: 
 
 @end menu
 
-@node Installation of dependencies,Installing GNUnet,,Generic instructions for installation from source
-@anchor{taler-merchant-manual id3}@anchor{15}@anchor{taler-merchant-manual installation-of-dependencies}@anchor{16}
-@subsection Installation of dependencies
+@node Installing from source,Installing the GNU Taler binary packages on Debian,,Installation
+@anchor{taler-merchant-manual generic-instructions}@anchor{13}@anchor{taler-merchant-manual installing-from-source}@anchor{14}
+@section Installing from source
+
+
+The following instructions will show how to install a GNU Taler
+merchant backend from source.
+
+The package sources can be find in our
+download directory@footnote{http://ftpmirror.gnu.org/taler/}.
+
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
 
+GNU Taler components version numbers follow the @code{MAJOR.MINOR.MICRO} format.
+The general rule for compatibility is that @code{MAJOR} and @code{MINOR} must match.
+Exceptions to this general rule are documented in the release notes.
+For example, Taler merchant 1.3.0 should be compatible with Taler exchange 1.4.x
+as the MAJOR version matches.  A MAJOR version of 0 indicates experimental
+development, and you are expected to always run all of the `latest' releases
+together (no compatibility guarantees).
 
-The following packages need to be installed before we can compile the
+First, the following packages need to be installed before we can compile the
 backend:
 
 
 @itemize -
 
 @item 
-"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
+“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
 on Debian-based systems (for GNUnet documentation support, can be
 omitted if GNUnet is configured with @code{--disable-documentation})
 
@@ -566,10 +630,10 @@ GNU libunistring >= 0.9.3
 libcurl >= 7.26 (or libgnurl >= 7.26)
 
 @item 
-libqrencode >= 4.0.0
+libqrencode >= 4.0.0 (Taler merchant only)
 
 @item 
-GNU libgcrypt >= 1.6
+GNU libgcrypt >= 1.6 (1.10 or later highly recommended)
 
 @item 
 libsodium >= 1.0
@@ -587,35 +651,31 @@ PostgreSQL >= 13, including libpq
 GNU libmicrohttpd >= 0.9.71
 
 @item 
-GNUnet >= 0.16 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
+GNUnet >= 0.19 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
 
 @item 
-GNU Taler exchange (see release announcement@footnote{https://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=taler&idxname=info-gnu&max=20&result=normal&sort=date:late})
+Python3 with @code{jinja2}
 @end itemize
 
-Except for the last two, these are available in most GNU/Linux distributions
-and should just be installed using the respective package manager. Be careful
-with GNU libmicrohttpd; here, some distributions only include an older version
-that will not work.
-
-While you are in the GNU Taler exchange
-download directory@footnote{http://ftpmirror.gnu.org/taler/},
-you might as well also download the tarball for GNU Taler merchant.
-
-GNU Taler components version numbers follow the @code{MAJOR.MINOR.MICRO} format.
-The general rule for compatibility is that @code{MAJOR} and @code{MINOR} must match.
-Exceptions to this general rule are documented in the release notes.
-For example, Taler merchant 0.8.0 is compatible with Taler exchange 0.8.1.
+If you are on Debian stable or later, the following command may help you
+install these dependencies:
 
-The following sections will provide detailed instructions for installing
-the @code{libgnunetutil} and GNU Taler exchange dependencies.
-
-@node Installing GNUnet,Installing the GNU Taler exchange,Installation of dependencies,Generic instructions for installation from source
-@anchor{taler-merchant-manual installing-gnunet}@anchor{17}@anchor{taler-merchant-manual installing-libgnunetutil}@anchor{18}
-@subsection Installing GNUnet
-
-
-@geindex GNUnet
+@example
+# apt-get install \
+  libqrencode-dev \
+  libsqlite3-dev \
+  libltdl-dev \
+  libunistring-dev \
+  libsodium-dev \
+  libargon2-dev \
+  libcurl4-gnutls-dev \
+  libgcrypt20-dev \
+  libjansson-dev \
+  libpq-dev \
+  libmicrohttpd-dev \
+  python3-jinja2 \
+  postgresql-13
+@end example
 
 Before you install GNUnet, you must download and install the dependencies
 mentioned in the previous section, otherwise the build may succeed, but could
@@ -639,16 +699,16 @@ The @code{ldconfig} command (also run as @code{root}) makes the
 shared object libraries (@code{.so} files)
 visible to the various installed programs.
 
-There is no need to actually run a GNUnet peer to use the Taler merchant
-backend -- all the merchant needs from GNUnet is a number of headers and
-libraries!
-
-@node Installing the GNU Taler exchange,Installing the GNU Taler merchant backend,Installing GNUnet,Generic instructions for installation from source
-@anchor{taler-merchant-manual id4}@anchor{19}@anchor{taler-merchant-manual installing-the-gnu-taler-exchange}@anchor{1a}
-@subsection Installing the GNU Taler exchange
+Please note that unlike most packages, if you want to run the @code{make check}
+command, you should run it only `after' having done @code{make install}.  The
+latter ensures that necessary binaries are copied to the right place.
 
+In any case, if @code{make check} fails, please consider filing a
+bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
 
-@geindex exchange
+There is no need to actually run a GNUnet peer to use the Taler merchant
+backend – all the merchant needs from GNUnet is a number of headers and
+libraries!
 
 After installing GNUnet, unpack the GNU Taler exchange tarball,
 change into the resulting directory, and proceed as follows:
@@ -668,24 +728,15 @@ which requires you to run the last step as @code{root}.  You have to specify
 previous step.
 
 There is no need to actually run a Taler exchange to use the Taler merchant
-backend -- all the merchant needs from the Taler exchange is a few headers and
+backend – all the merchant needs from the Taler exchange is a few headers and
 libraries!
 
-@node Installing the GNU Taler merchant backend,,Installing the GNU Taler exchange,Generic instructions for installation from source
-@anchor{taler-merchant-manual id5}@anchor{1b}@anchor{taler-merchant-manual installing-the-gnu-taler-merchant-backend}@anchor{1c}
-@subsection Installing the GNU Taler merchant backend
-
-
-@geindex backend
-
-GNU Taler merchant has these additional dependencies:
-
-
-@itemize -
+Please note that unlike most packages, if you want to run the @code{make check}
+command, you should run it only `after' having done @code{make install}.  The
+latter ensures that necessary binaries are copied to the right place.
 
-@item 
-libqrencode >= 4.0.0
-@end itemize
+In any case, if @code{make check} fails, please consider filing a
+bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
 
 The following steps assume all dependencies are installed.
 
@@ -719,44 +770,41 @@ find the installed libraries and launching the Taler merchant backend would
 then fail.
 
 Please note that unlike most packages, if you want to run the @code{make check}
-command, you should run it only @emph{after} having done @code{make install}.  The
+command, you should run it only `after' having done @code{make install}.  The
 latter ensures that necessary binaries are copied to the right place.
 
-Gratuitous editorial note by TTN: I think this is a quirk that we should
-fix in the long-term as such weirdness might hide other build issues.
-However, this is probably a minority viewpoint.
-
 In any case, if @code{make check} fails, please consider filing a
 bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
 
-@node Installing the GNU Taler binary packages on Debian,Installing the GNU Taler binary packages on Trisquel,Generic instructions for installation from source,Installation
-@anchor{taler-merchant-manual installing-the-gnu-taler-binary-packages-on-debian}@anchor{1d}
+@node Installing the GNU Taler binary packages on Debian,Installing the GNU Taler binary packages on Trisquel,Installing from source,Installation
+@anchor{taler-merchant-manual installing-the-gnu-taler-binary-packages-on-debian}@anchor{15}
 @section Installing the GNU Taler binary packages on Debian
 
 
 To install the GNU Taler Debian packages, first ensure that you have
 the right Debian distribution. At this time, the packages are built for
-Bullseye.
+Debian bookworm.
 
 You need to add a file to import the GNU Taler packages. Typically,
 this is done by adding a file @code{/etc/apt/sources.list.d/taler.list} that
 looks like this:
 
 @example
-deb https://deb.taler.net/apt/debian bullseye main
+deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/debian stable main
 @end example
 
 Next, you must import the Taler Systems SA public package signing key
 into your keyring and update the package lists:
 
 @example
-# wget -O - https://taler.net/taler-systems.gpg.key | apt-key add -
+# wget -O /etc/apt/keyrings/taler-systems.gpg \
+    https://taler.net/taler-systems.gpg
 # apt update
 @end example
 
 @cartouche
 @quotation Note 
-You may want to verify the correctness of the Taler Systems key out-of-band.
+You may want to verify the correctness of the Taler Systems SA key out-of-band.
 @end quotation
 @end cartouche
 
@@ -773,33 +821,36 @@ Note that the package does not complete the integration of the backend with
 the HTTP reverse proxy (typically with TLS certificates).  A configuration
 fragment for Nginx or Apache will be placed in
 @code{/etc/@{apache,nginx@}/conf-available/taler-merchant.conf}.  You must
-furthermore still configure the instances, and may need to extend the fragment
-with access control restrictions for non-default instances.
+furthermore still configure the database and the instances, and may need to
+extend the fragment with access control restrictions for non-default
+instances.
 
 @node Installing the GNU Taler binary packages on Trisquel,Installing the GNU Taler binary packages on Ubuntu,Installing the GNU Taler binary packages on Debian,Installation
-@anchor{taler-merchant-manual installing-the-gnu-taler-binary-packages-on-trisquel}@anchor{1e}
+@anchor{taler-merchant-manual installing-the-gnu-taler-binary-packages-on-trisquel}@anchor{16}
 @section Installing the GNU Taler binary packages on Trisquel
 
 
 To install the GNU Taler Trisquel packages, first ensure that you have
 the right Trisquel distribution. Packages are currently available for
 Trisquel GNU/Linux 10.0.  Simply follow the same instructions provided
-for Ubuntu 20.04 LTS (Focal Fossa).
+for Ubuntu.
 
-@node Installing the GNU Taler binary packages on Ubuntu,Installing Taler on Debian GNU/Linux from source,Installing the GNU Taler binary packages on Trisquel,Installation
-@anchor{taler-merchant-manual installing-the-gnu-taler-binary-packages-on-ubuntu}@anchor{1f}
+@node Installing the GNU Taler binary packages on Ubuntu,,Installing the GNU Taler binary packages on Trisquel,Installation
+@anchor{taler-merchant-manual installing-the-gnu-taler-binary-packages-on-ubuntu}@anchor{17}
 @section Installing the GNU Taler binary packages on Ubuntu
 
 
 To install the GNU Taler Ubuntu packages, first ensure that you have
 the right Ubuntu distribution. At this time, the packages are built for
-Ubuntu 22.04 LTS (Jammy Jellyfish).
+Ubuntu Kinetic and Ubuntu Jammy. Make sure to have @code{universe} in your
+@code{/etc/apt/sources.list} (after @code{main}) as we depend on some packages
+from Ubuntu @code{universe}.
 
 A typical @code{/etc/apt/sources.list.d/taler.list} file for this setup
 would look like this:
 
 @example
-deb https://deb.taler.net/apt/ubuntu/ jammy main
+deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ stable main
 @end example
 
 The last line is crucial, as it adds the GNU Taler packages.
@@ -808,8 +859,8 @@ Next, you must import the Taler Systems SA public package signing key
 into your keyring and update the package lists:
 
 @example
-# wget -O /etc/apt/trusted.gpg.d/taler-systems.asc \
-    https://taler.net/taler-systems.gpg.key
+# wget -O /etc/apt/keyrings/taler-systems.gpg \
+    https://taler.net/taler-systems.gpg
 # apt update
 @end example
 
@@ -832,91 +883,12 @@ Note that the package does not complete the integration of the backend with
 the HTTP reverse proxy (typically with TLS certificates).  A configuration
 fragment for Nginx or Apache will be placed in
 @code{/etc/@{apache,nginx@}/conf-available/taler-merchant.conf}.  You must
-furthermore still configure the instances, and may need to extend the fragment
-with access control restrictions for non-default instances.
-
-@node Installing Taler on Debian GNU/Linux from source,,Installing the GNU Taler binary packages on Ubuntu,Installation
-@anchor{taler-merchant-manual installing-taler-on-debian-gnu-002flinux}@anchor{20}@anchor{taler-merchant-manual installing-taler-on-debian-gnu-linux-from-source}@anchor{21}
-@section Installing Taler on Debian GNU/Linux from source
-
-
-@geindex Wheezy
-
-@geindex Jessie
-
-@geindex Stretch
-
-@geindex Buster
-
-@geindex Bullseye
-
-@geindex Debian
-
-Debian Wheezy is too old and lacks most of the packages required.
-Debian Jessie, Stretch, and Buster are better, but still lack PostgreSQL 12.
-
-@cartouche
-@quotation Note 
-When compiling PostgreSQL 12, make sure to
-do @code{make world} to build the @code{contrib/} modules, and
-@code{cd contrib && make install} to install them, as well.
-@end quotation
-@end cartouche
-
-On Debian Stretch and Buster, only GNU libmicrohttpd needs to be compiled from
-source. To install dependencies on Debian Stretch, run the following
-commands:
-
-@example
-# apt-get install \
-  libqrencode-dev \
-  libsqlite3-dev \
-  libltdl-dev \
-  libunistring-dev \
-  libsodium-dev \
-  libargon2-0-dev \
-  libcurl4-gnutls-dev \
-  libgcrypt20-dev \
-  libjansson-dev \
-  libpq-dev \
-  postgresql-9.6
-# wget https://ftpmirror.gnu.org/libmicrohttpd/libmicrohttpd-latest.tar.gz
-# wget https://ftpmirror.gnu.org/libmicrohttpd/libmicrohttpd-latest.tar.gz.sig
-# gpg -v libmicrohttpd-latest.tar.gz # Should show signed by 939E6BE1E29FC3CC
-# tar xf libmicrohttpd-latest.tar.gz
-# cd libmicrohttpd-0*
-# ./configure
-# make install
-@end example
-
-For more recent versions of Debian, you should instead run:
-
-@example
-# apt-get install \
-  libqrencode-dev \
-  libsqlite3-dev \
-  libltdl-dev \
-  libunistring-dev \
-  libsodium-dev \
-  libargon2-dev \
-  libcurl4-gnutls-dev \
-  libgcrypt20-dev \
-  libjansson-dev \
-  libpq-dev \
-  postgresql-9.6 \
-  libmicrohttpd-dev
-@end example
-
-Note that Stretch requires @code{libargon2-0-dev},
-while later versions of Debian require @code{libargon2-dev}.
-
-For the rest of the installation, follow the generic installation
-instructions starting with the installation of libgnunetutil. Note that
-if you used the Debian Stretch instructions above, you need to pass
-@code{--with-microhttpd=/usr/local/} to all @code{configure} invocations.
+furthermore still configure the database and the instances, and may need to
+extend the fragment with access control restrictions for non-default
+instances.
 
 @node How to configure the merchant’s backend,Instance setup,Installation,Top
-@anchor{taler-merchant-manual how-to-configure-the-merchants-backend}@anchor{22}
+@anchor{taler-merchant-manual how-to-configure-the-merchants-backend}@anchor{18}
 @chapter How to configure the merchant’s backend
 
 
@@ -926,12 +898,11 @@ if you used the Debian Stretch instructions above, you need to pass
 
 The installation already provides reasonable defaults for most of the
 configuration options. However, some must be provided, in particular the
-database account and bank account that the backend should use. By
-default, the file @code{$HOME/.config/taler.conf} is where the Web shop
-administrator specifies configuration values that augment or override
-the defaults. The format of the configuration file is the well-known INI
-file format. You can edit the file by hand, or use the @code{taler-config}
-commands given as examples.
+database that the backend should use. By default, the file
+@code{$HOME/.config/taler.conf} is where the Web shop administrator specifies
+configuration values that augment or override the defaults.
+Note that when using our binary packages, the systemd service files
+force the use of @code{/etc/taler.conf} as the main configuration file.
 
 @menu
 * Configuration format:: 
@@ -943,20 +914,26 @@ commands given as examples.
 @end menu
 
 @node Configuration format,Using taler-config,,How to configure the merchant’s backend
-@anchor{taler-merchant-manual configuration-format}@anchor{23}
+@anchor{taler-merchant-manual configuration-format}@anchor{19}
 @section Configuration format
 
 
-In Taler realm, any component obeys to the same pattern to get
-configuration values. According to this pattern, once the component has
-been installed, the installation deploys default values in
-$@{prefix@}/share/taler/config.d/, in .conf files. In order to override
-these defaults, the user can write a custom .conf file and either pass
-it to the component at execution time, or name it taler.conf and place
-it under $HOME/.config/.
+All GNU Taler components are designed to possibly share the same
+configuration files.  When installing a GNU Taler component, the
+installation deploys default values in configuration files located
+at $@{prefix@}/share/taler/config.d/ where $@{prefix@} is the installation
+prefix. Different components must be installed to the same prefix.
+
+In order to override these defaults, the user can write a custom configuration
+file and either pass it to the component at execution time using the `-c'
+option, or name it taler.conf and place it under $HOME/.config/ which is where
+components will look by default. Note that the systemd service files pass @code{-c
+/etc/taler.conf}, thus making @code{/etc/taler.conf} the primary location for
+the configuration.
 
 A config file is a text file containing sections, and each section
-contains its values. The right format follows:
+contains maps options to their values.  Configuration files follow
+basically the INI syntax:
 
 @example
 [section1]
@@ -968,14 +945,23 @@ value21 = string
 value22 = /path22
 @end example
 
-Throughout any configuration file, it is possible to use @code{$}-prefixed
-variables, like @code{$VAR}, especially when they represent filesystem
-paths. It is also possible to provide defaults values for those
+Comments start with a hash (@code{#}).  Throughout the configuration, it is
+possible to use @code{$}-substitution for options relating to names of files or
+directories. It is also possible to provide defaults values for those
 variables that are unset, by using the following syntax:
-@code{$@{VAR:-default@}}. However, there are two ways a user can set
-@code{$}-prefixable variables:
+@code{$@{VAR:-default@}}. There are two ways a user can set the value
+of @code{$}-prefixable variables:
 
-by defining them under a @code{[paths]} section, see example below,
+@quotation
+
+
+@enumerate 
+
+@item 
+by defining them under a @code{[paths]} section:
+@end enumerate
+
+@quotation
 
 @example
 [paths]
@@ -984,47 +970,43 @@ TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
 [section-x]
 path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
 @end example
+@end quotation
 
+
+@enumerate 2
+
+@item 
 or by setting them in the environment:
+@end enumerate
+
+@quotation
 
 @example
 $ export VAR=/x
 @end example
+@end quotation
+@end quotation
 
 The configuration loader will give precedence to variables set under
-@code{[path]}, though.
+@code{[path]} over environment variables.
 
-The utility @code{taler-config}, which gets installed along with the
-exchange, serves to get and set configuration values without directly
-editing the .conf. The option @code{-f} is particularly useful to resolve
+The utility @code{taler-config}, which gets installed along with the exchange,
+can be used get and set configuration values without directly editing the
+configuration file. The option @code{-f} is particularly useful to resolve
 pathnames, when they use several levels of @code{$}-expanded variables. See
 @code{taler-config --help}.
 
-Note that, in this stage of development, the file
-@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
-component. For example, both an exchange and a bank can read values from
-it.
-
-The repository @code{git://taler.net/deployment} contains examples of
-configuration file used in our demos. See under @code{deployment/config}.
-
-@quotation
-
-@strong{Note}
-
-Expectably, some components will not work just by using default
-values, as their work is often interdependent. For example, a
-merchant needs to know an exchange URL, or a database name.
-@end quotation
+The repository @code{git://git.taler.net/deployment} contains example code
+for generating configuration files under @code{deployment/netzbon/}.
 
 @node Using taler-config,Backend options,Configuration format,How to configure the merchant’s backend
-@anchor{taler-merchant-manual using-taler-config}@anchor{24}
+@anchor{taler-merchant-manual using-taler-config}@anchor{1a}
 @section Using taler-config
 
 
-The tool @code{taler-config} can be used to extract or manipulate
-configuration values; however, the configuration use the well-known INI
-file format and can also be edited by hand.
+The tool @code{taler-config} can be used to extract or manipulate configuration
+values; however, the configuration use the well-known INI file format and is
+generally better edited by hand to preserve comments and structure.
 
 Run
 
@@ -1037,20 +1019,20 @@ to list all of the configuration values in section @code{$SECTION}.
 Run
 
 @example
-$ taler-config -s $section -o $option
+$ taler-config -s $SECTION -o $OPTION
 @end example
 
-to extract the respective configuration value for option @code{$option} in
-section @code{$section}.
+to extract the respective configuration value for option @code{$OPTION} in
+section @code{$SECTION}.
 
 Finally, to change a setting, run
 
 @example
-$ taler-config -s $section -o $option -V $value
+$ taler-config -s $SECTION -o $OPTION -V $VALUE
 @end example
 
-to set the respective configuration value to @code{$value}. Note that you
-have to manually restart the Taler backend after you change the
+to set the respective configuration value to @code{$VALUE}. Note that you
+have to manually restart affected Taler components after you change the
 configuration to make the new configuration go into effect.
 
 Some default options will use $-variables, such as @code{$DATADIR} within
@@ -1059,19 +1041,16 @@ configuration, pass the @code{-f} option to @code{taler-config}. For example,
 compare:
 
 @example
-$ taler-config -s ACCOUNT-bank \
-               -o WIRE_RESPONSE
-$ taler-config -f -s ACCOUNT-bank \
-               -o WIRE_RESPONSE
+$ taler-config --section exchange-offline --option MASTER_PRIV_FILE
+$ taler-config -f --section exchange-offline --option MASTER_PRIV_FILE
 @end example
 
 While the configuration file is typically located at
-@code{$HOME/.config/taler.conf}, an alternative location can be specified
-to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
-option.
+@code{$HOME/.config/taler.conf}, an alternative location can be specified to any
+GNU Taler component using the @code{-c} option.
 
 @node Backend options,Sample backend configuration,Using taler-config,How to configure the merchant’s backend
-@anchor{taler-merchant-manual backend-options}@anchor{25}@anchor{taler-merchant-manual id6}@anchor{26}
+@anchor{taler-merchant-manual backend-options}@anchor{1b}@anchor{taler-merchant-manual id4}@anchor{1c}
 @section Backend options
 
 
@@ -1096,20 +1075,19 @@ option.
 @geindex wire format
 
 The following table describes the options that commonly need to be
-modified. Here, the notation @code{[$section]/$option} denotes the option
-@code{$option} under the section @code{[$section]} in the configuration file.
+modified. Here, the notation @code{[$SECTION]/$OPTION} denotes the option
+@code{$OPTION} under the section @code{[$SECTION]} in the configuration file.
 
 @menu
 * Service address:: 
 * Currency:: 
 * Database:: 
 * Exchange:: 
-* Auditor:: 
 
 @end menu
 
 @node Service address,Currency,,Backend options
-@anchor{taler-merchant-manual service-address}@anchor{27}
+@anchor{taler-merchant-manual service-address}@anchor{1d}
 @subsection Service address
 
 
@@ -1117,19 +1095,19 @@ The following option sets the transport layer address used by the
 merchant backend:
 
 @example
-[MERCHANT]/SERVE = TCP | UNIX
+[MERCHANT]/SERVE = tcp | unix
 @end example
 
-If given,
+If this option is set to
 
 
 @itemize -
 
 @item 
-@code{TCP}, then we need to set the TCP port in @code{[MERCHANT]/PORT}
+@code{tcp} then we need to set the TCP port in @code{[MERCHANT]/PORT};
 
 @item 
-@code{UNIX}, then we need to set the unix domain socket path and mode
+@code{unix} then we need to set the unix domain socket path and mode
 in @code{[MERCHANT]/UNIXPATH} and @code{[MERCHANT]/UNIXPATH_MODE}. The
 latter takes the usual permission mask given as a number, e.g. 660
 for user/group read-write access.
@@ -1143,7 +1121,7 @@ the backend to the network.
 To run the Taler backend on TCP port 8888, use:
 
 @example
-$ taler-config -s MERCHANT -o SERVE -V TCP
+$ taler-config -s MERCHANT -o SERVE -V tcp
 $ taler-config -s MERCHANT -o PORT -V 8888
 @end example
 
@@ -1152,18 +1130,17 @@ $ taler-config -s MERCHANT -o PORT -V 8888
 When using the Debian/Ubuntu packages, these options are already
 configured in the @code{/etc/taler/conf.d/merchant.conf} configuration file.
 
-If you need to change them, you should edit @code{/etc/taler/merchant-overrides.conf},
-for example by passing @code{-c /etc/taler/merchant-overrides.conf} to the
-@code{taler-config} commands above.  By default, the Taler merchant
-package when installed on Debian/Ubuntu will use a UNIX domain socket
-at @code{/run/taler/merchant-httpd/merchant-http.sock}. For the best possible
-security, it is recommended to leave this in place and configure a reverse
-proxy (nginx or Apache) as described below.
+If you need to change them, you should edit
+@code{/etc/taler/merchant-overrides.conf}.  By default, the Taler merchant
+package will use a UNIX domain socket at
+@code{/run/taler/merchant-httpd/merchant-http.sock}. For the best possible
+security it is recommended to leave this in place and configure a reverse
+proxy (Nginx or Apache) as described below.
 @end quotation
 @end cartouche
 
 @node Currency,Database,Service address,Backend options
-@anchor{taler-merchant-manual currency}@anchor{28}
+@anchor{taler-merchant-manual currency}@anchor{1e}
 @subsection Currency
 
 
@@ -1174,9 +1151,9 @@ specified using the option
 [TALER]/CURRENCY
 @end example
 
-For testing purposes, the currency MUST match “KUDOS” so that tests
-will work with the Taler demonstration exchange at
-@indicateurl{https://exchange.demo.taler.net/}:
+When testing with the Taler demonstration exchange at
+@indicateurl{https://exchange.demo.taler.net/} you must set this
+value to @code{KUDOS}:
 
 @example
 $ taler-config -s TALER -o CURRENCY -V KUDOS
@@ -1187,14 +1164,14 @@ $ taler-config -s TALER -o CURRENCY -V KUDOS
 When using the Debian/Ubuntu packages, these options should be
 configured in the @code{/etc/taler/taler.conf} configuration file
 (alternatively, you can also edit @code{/etc/taler/merchant-overrides.conf}).
-However, you must edit the @code{taler.conf} file manually and @strong{must not}
+However, you must edit the @code{taler.conf} file manually and `must not'
 use @code{taler-config} to do this, as that would inline the include
 directives and destroy the carefully setup path structure.
 @end quotation
 @end cartouche
 
 @node Database,Exchange,Currency,Backend options
-@anchor{taler-merchant-manual database}@anchor{29}
+@anchor{taler-merchant-manual database}@anchor{1f}
 @subsection Database
 
 
@@ -1213,25 +1190,25 @@ DBMS-specific options to access the database.
 
 @cartouche
 @quotation Note 
-When using the Debian/Ubuntu packages, the database should already
-be configured in the @code{/etc/taler/secrets/merchant-db.secret.conf}
-configuration file.  The @code{talermerchant} database is also already
-configured (unless you answered @code{no} when asked the question during
-installation), so you can skip everything in this section.
+The `taler-merchant-dbconfig' tool can be used to automate the database
+setup. When using the Debian/Ubuntu packages, the user should already have
+been created, so you can just run the tool without any arguments and should
+have a working database configuration.
 @end quotation
 @end cartouche
 
-For the @code{postgres} backend, you need to provide:
+For the @code{postgres} backend, you need to specify:
 
 @example
-[MERCHANTDB-postgres]/CONFIG
+[MERCHANTDB-postgres]
+CONFIG = "postgres://..."
 @end example
 
-This option specifies a postgres access path using the format
-@code{postgres:///$DBNAME}, where @code{$DBNAME} is the name of the
-PostgreSQL database you want to use. Suppose @code{$USER} is the name of
-the user who will run the backend process. Then, you need to first
-run:
+This option specifies a PostgreSQL access path, typicallly using the format
+@code{postgres:///$DBNAME}, where @code{$DBNAME} is the name of the PostgreSQL
+database you want to use. Suppose @code{$USER} is the name of the user who will
+run the backend process (usually @code{taler-merchant-httpd}). Then, you need to
+first run:
 
 @example
 $ sudo -u postgres createuser -d $USER
@@ -1248,42 +1225,31 @@ $ createdb $DBNAME
 to create the backend’s database. Here, @code{$DBNAME} must match the
 database name given in the configuration file.
 
-To configure the Taler backend to use this database, run:
-
-@example
-$ taler-config -s MERCHANTDB-postgres -o CONFIG \
-    -V postgres:///$DBNAME
-@end example
-
-Now you should create the tables and indices. To do this, run as @code{$USER}:
+Now you should be able to create the tables and indices. To do this, run as
+@code{$USER} (usually @code{taler-merchant-httpd}):
 
 @example
 $ taler-merchant-dbinit
 @end example
 
-You can improve your security posture if you now REVOKE the rights to CREATE,
+You may improve your security posture if you now REVOKE the rights to CREATE,
 DROP or ALTER tables from @code{$USER}. However, if you do so, please be aware
 that you may have to temporarily GRANT those rights again when you update the
 merchant backend.  For details on how to REVOKE or GRANT these rights, consult
 the PostgreSQL documentation.
 
-Commands, like @code{taler-merchant-dbinit}, that support the @code{-l LOGFILE}
-command-line option, send logging output to standard error by default.
-See manpages/taler-merchant-dbinit.1 for more information.
-
 @cartouche
 @quotation Note 
-The Taler merchant backend stores private keys and other sensitive
-business and customer data in the database.  The backend operator
-SHOULD ensure that backup operations are encrypted and secured from
-unauthorized access.
+Taler may store sensitive business and customer data in the database.  Any
+operator SHOULD thus ensure that backup operations are encrypted and
+secured from unauthorized access.
 @end quotation
 @end cartouche
 
 @c index: MASTER_KEY
 
-@node Exchange,Auditor,Database,Backend options
-@anchor{taler-merchant-manual exchange}@anchor{2a}
+@node Exchange,,Database,Backend options
+@anchor{taler-merchant-manual exchange}@anchor{20}
 @subsection Exchange
 
 
@@ -1299,9 +1265,8 @@ The @code{EXCHANGE_BASE_URL} option specifies the exchange’s base URL.
 For example, to use the Taler demonstrator, specify:
 
 @example
-$ taler-config -s MERCHANT-EXCHANGE-demo \
-    -o EXCHANGE_BASE_URL \
-    -V https://exchange.demo.taler.net/
+[MERCHANT-EXCHANGE-demo]
+EXCHANGE_BASE_URL = "https://exchange.demo.taler.net/"
 @end example
 
 @item 
@@ -1309,9 +1274,8 @@ The @code{MASTER_KEY} option specifies the exchange’s master public key
 in base32 encoding. For the Taler demonstrator, use:
 
 @example
-$ taler-config -s MERCHANT-EXCHANGE-demo \
-    -o MASTER_KEY \
-    -V FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0
+[MERCHANT-EXCHANGE-demo]
+MASTER_KEY = "FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0"
 @end example
 
 @item 
@@ -1319,90 +1283,30 @@ The @code{CURRENCY} option specifies the exchange’s currency.
 For the Taler demonstrator, use:
 
 @example
-$ taler-config -s MERCHANT-EXCHANGE-demo \
-    -o CURRENCY \
-    -V KUDOS
+[MERCHANT-EXCHANGE-demo]
+CURRENCY = "KUDOS"
 @end example
 @end itemize
 
 Note that multiple exchanges can be added to the system by using different
-tokens in place of @code{demo} in the examples above. Note that all of the
-exchanges must use the same currency: If the currency does not match the main
-currency from the @code{TALER} section, the exchange is ignored. If you need to
-support multiple currencies, you need to configure a backend per currency.
+identifiers in place of @code{demo} in the example above. Note that all of the
+exchanges actually used will use the same currency: If the currency does not
+match the main @code{CURRENCY} option from the @code{TALER} section, the respective
+@code{MERCHANT-EXCHANGE-} section is automatically ignored. If you need support
+for multiple currencies, you need to deploy one backend per currency.
 
 @cartouche
 @quotation Note 
 Manually setting up exchanges is only recommended under special
-circumstances. In general, GNU Taler will include trustworthy
-auditors (for each currency) in the default configuration, and
-there is rarely a good reason for trusting an exchange without
-an accredited auditor.
-@end quotation
-@end cartouche
-
-@node Auditor,,Exchange,Backend options
-@anchor{taler-merchant-manual auditor}@anchor{2b}
-@subsection Auditor
-
-
-To add an auditor to the list of trusted auditors (which implies
-that all exchanges audited by this auditor will be trusted!)
-you create a section with a name that starts with “MERCHANT-AUDITOR-”. In
-4that section, the following options need to be configured:
-
-
-@itemize -
-
-@item 
-The @code{AUDITOR_BASE_URL} option specifies the auditor’s base URL.
-For example, to use the Taler demonstrator's auditor, specify:
-
-@example
-$ taler-config -s MERCHANT-AUDITOR-demo \
-    -o AUDITOR_BASE_URL \
-    -V https://exchange.demo.taler.net/
-@end example
-
-@item 
-The @code{AUDITOR_KEY} option specifies the auditor's public key
-in base32 encoding. For the Taler demonstrator, use:
-
-@example
-$ taler-config -s MERCHANT-AUDITOR-demo \
-    -o AUDITOR_KEY \
-    -V DSDASDXAMDAARMNAD53ZA4AFAHA2QADAMAHHASWDAWXN84SDAA11
-@end example
-
-@item 
-The @code{CURRENCY} option specifies the auditor’s currency.
-For the Taler demonstrator, use:
-
-@example
-$ taler-config -s MERCHANT-AUDITOR-demo \
-    -o CURRENCY \
-    -V KUDOS
-@end example
-@end itemize
-
-Note that multiple auditors can be added to the system by using different
-tokens in place of @code{demo} in the examples above. Note that all of the
-auditors must use the same currency: If the currency does not match the main
-currency from the @code{TALER} section, the auditor is ignored.  If you need to
-support multiple currencies, you need to configure a backend per currency.
-
-@cartouche
-@quotation Note 
-Manually adding auditors is only recommended under special
-circumstances. In general, GNU Taler will include trustworthy
-auditors (for each currency) in the default configuration, and
-there is rarely a good reason for adding an auditor that is
-not coordinating its activities with the Taler developers.
+circumstances. In general, GNU Taler distributions will include trustworthy
+exchanges (for each currency) in the default configuration, and there is
+rarely a good reason for trusting an exchange that has no relationship
+with the GNU Taler development team.
 @end quotation
 @end cartouche
 
 @node Sample backend configuration,Launching the backend,Backend options,How to configure the merchant’s backend
-@anchor{taler-merchant-manual id7}@anchor{2c}@anchor{taler-merchant-manual sample-backend-configuration}@anchor{2d}
+@anchor{taler-merchant-manual id5}@anchor{21}@anchor{taler-merchant-manual sample-backend-configuration}@anchor{22}
 @section Sample backend configuration
 
 
@@ -1428,28 +1332,17 @@ MASTER_KEY = FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0
 # If currency does not match [TALER] section, the exchange
 # will be ignored!
 CURRENCY = KUDOS
-
-[merchant-auditor-NAME]
-AUDITOR_BASE_URL = https://auditor.demo.taler.net/
-AUDITOR_KEY = DSDASDXAMDAARMNAD53ZA4AFAHA2QADAMAHHASWDAWXN84SDAA11
-# If currency does not match [TALER] section, the auditor
-# will be ignored!
-CURRENCY = KUDOS
 @end example
 
-Given the above configuration, the backend will use a database named
-@code{donations} within PostgreSQL.
+Given the above configuration, the backend will use a PostgreSQL database
+named @code{donations} running on the same host.
 
 The backend will deposit the coins it receives to the exchange at
 @indicateurl{https://exchange.demo.taler.net/}, which has the master key
 @code{FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0}.
 
-Please note that @code{doc/config.sh} will walk you through all
-configuration steps, showing how to invoke @code{taler-config} for each of
-them.
-
 @node Launching the backend,,Sample backend configuration,How to configure the merchant’s backend
-@anchor{taler-merchant-manual id8}@anchor{2e}@anchor{taler-merchant-manual launching-the-backend}@anchor{2f}
+@anchor{taler-merchant-manual id6}@anchor{23}@anchor{taler-merchant-manual launching-the-backend}@anchor{24}
 @section Launching the backend
 
 
@@ -1461,13 +1354,22 @@ Assuming you have configured everything correctly, you can launch the
 merchant backend as @code{$USER} using
 
 @example
-$ taler-merchant-httpd
+$ taler-merchant-httpd &
+$ taler-merchant-webhook &
+$ taler-merchant-wirewatch &
 @end example
 
-To ensure the process runs always in the background and also after rebooting,
-you should use systemd, cron or some other init system of your operating
-system to launch the process. Consult the documentation of your operating
-system for how to start and stop daemons.
+You only need to run @code{taler-merchant-webhook} if one of the instances is
+configured to trigger web hooks.  Similarly, @code{taler-merchant-wirewatch} is
+only required if instances have accounts configured with automatic import of
+wire transfers via a bank wire gateway.
+
+To ensure these processes runs always in the background and also after
+rebooting, you should use systemd, cron or some other init system of your
+operating system to launch the process.  You should also periodically re-start
+these services to prevent them from exhausing the memory utilization of the
+PostgreSQL database.  Consult the documentation of your operating system for
+how to start and stop daemons.
 
 @cartouche
 @quotation Note 
@@ -1492,7 +1394,8 @@ $ wget -O - http://localhost:8888/config
 
 should return some basic configuration status data about the service.
 
-Please note that your backend is right now likely globally reachable.  You can either:
+Please note that your backend might then be globally reachable without
+any access control.  You can either:
 
 @quotation
 
@@ -1516,21 +1419,22 @@ and use TLS for improved network privacy, see @ref{9,,Secure setup}.
 @geindex instance
 
 @node Instance setup,Secure setup,How to configure the merchant’s backend,Top
-@anchor{taler-merchant-manual id9}@anchor{30}@anchor{taler-merchant-manual instance-setup}@anchor{31}
+@anchor{taler-merchant-manual id7}@anchor{25}@anchor{taler-merchant-manual instance-setup}@anchor{26}
 @chapter Instance setup
 
 
 First of all, we recommend the use of the single-page administration
-application that is served by default at the base URL of the merchant backend.
-You can use it to perform all steps described in this section (and more!),
-using a simple Web interface instead of the @code{wget} commands given below.
-
-The first step for using the backend involves the creation of a @code{default}
-instance. The @code{default} instance can also create / delete / configure other
-instances, similar to the @code{root} account on UNIX.  When no instance exists
-and @code{taler-merchant-httpd} was started without the @code{--auth} option, then
-the backend is reachable without any access control (unless you configured
-some in the reverse proxy).
+application (SPA) that is served by default at the base URL of the merchant
+backend.  You can use it to perform all steps described in this section (and
+more!), using a simple Web interface instead of the @code{wget} commands given
+below.
+
+Regardless of which tool you use, the first step for using the backend
+involves the creation of a @code{default} instance. The @code{default} instance can
+also create / delete / configure other instances, similar to the @code{root}
+account on UNIX.  When no instance exists and @code{taler-merchant-httpd} was
+started without the @code{--auth} option, then the backend is reachable without
+any access control (unless you configured some in the reverse proxy).
 
 The following documentation shows how to handle any instance. Thus, if you
 want to have multiple instances, you may need to perform the steps multiple
@@ -1538,90 +1442,57 @@ times, once for each instance.
 
 @cartouche
 @quotation Note 
-A security concern is that normal API usage leaks instance existence.
+A potential security concern is that normal API usage leaks instance existence.
 This means unauthorized users can distinguish between the case where the
 instance does not exist (HTTP 404) and the case where access is denied
 (HTTP 403).
-This is all moot behind a properly configured
-@ref{32,,reverse proxy}.
+This is concern can be addressed using a properly configured
+@ref{27,,reverse proxy}.
 @end quotation
 @end cartouche
 
 @menu
-* KUDOS Accounts:: 
-* IBAN Accounts:: 
-* Setup:: 
+* Setup without the Web interface:: 
 
 @end menu
 
-@node KUDOS Accounts,IBAN Accounts,,Instance setup
-@anchor{taler-merchant-manual kudos-accounts}@anchor{33}
-@section KUDOS Accounts
-
-
-The main configuration data that must be provided for each instance
-is the bank account information.
-
-In order to receive payments, the merchant backend needs to
-communicate bank account details to the exchange.
-
-The bank account information is provided in the form of a @code{payto://}-URI.
-See RFC 8905@footnote{https://tools.ietf.org/html/rfc8905}
-for the format of @code{payto://}-URIs.
+@node Setup without the Web interface,,,Instance setup
+@anchor{taler-merchant-manual setup-without-the-web-interface}@anchor{28}
+@section Setup without the Web interface
 
-For first tests, you should sign up for a KUDOS bank
-account at @indicateurl{https://bank.demo.taler.net/}.
-In this case, the @code{payto://}-URI will be of the form
-@code{payto://x-taler-bank/bank.demo.taler.net/$USERNAME} where @code{$USERNAME}
-must be replaced with the name of the account that was established
-at @indicateurl{https://bank.demo.taler.net/}.
 
-@node IBAN Accounts,Setup,KUDOS Accounts,Instance setup
-@anchor{taler-merchant-manual iban-accounts}@anchor{34}
-@section IBAN Accounts
-
-
-When deploying Taler with the real banking system, you primarily need to
-change the currency of the configuration from KUDOS to the actual currency
-(such as EUR, USD, CHF) and provide a @code{payto://}-URI of your real bank
-account. In Europe, this will involve knowing your IBAN number. If you have an
-IBAN, the corresponding @code{payto://}-URI is simply @code{payto://iban/$IBAN} where
-@code{$IBAN} must be replaced with the actual IBAN number.
-
-@node Setup,,IBAN Accounts,Instance setup
-@anchor{taler-merchant-manual setup}@anchor{35}
-@section Setup
-
-
-With the knowledge of the @code{payto://}-URI, instances can be configured by POSTing
-a request to @code{/management/instances}.  To create a first instance,
-create a file @code{instance.json} with an InstanceConfigurationMessage
+Instances can be created by POSTing a request to @code{/management/instances}
+without using the Web interface.  This could be useful if you want to create
+many instances programmatically.  To create an instance without the Web
+interface create a file @code{instance.json} with an
+InstanceConfigurationMessage:
 
 @example
 @{
-  "payto_uris" : [ "$PAYTO_URI" ],
+  "accounts" : [@{"payto_uri":"$PAYTO_URI"@}],
   "id" : "default",
   "name": "example.com",
   "address": @{ "country" : "zz" @},
   "auth": @{ "method" : "external"@} ,
   "jurisdiction": @{ "country" : "zz" @},
-  "default_max_wire_fee": "KUDOS:1",
-  "default_wire_fee_amortization": 100,
-  "default_max_deposit_fee": "KUDOS:1",
+  "use_stefan": true,
   "default_wire_transfer_delay": @{ "d_ms" : 1209600000 @},
   "default_pay_delay": @{ "d_ms" : 1209600000 @}
 @}
 @end example
 
 In the text above, you must replace @code{$PAYTO_URI} with your actual
-@code{payto://}-URI. Also, be sure to replace @code{KUDOS} with the fiat currency if the
-setup is for an actual bank. The @code{name} field will be shown as the name of
-your shop. The @code{address} field is expected to contain your shop's physical
-address. The various defaults specify defaults for transaction fees your shop
-is willing to cover, how long offers made to the customer are valid, and how
-long the exchange has before it must wire the funds to your bank
-account. Those defaults can be modified for individual orders.
-For details, see the contract terms specification.
+@code{payto://}-URI.  You may also leave the account array empty. The instance
+owner must then configure the accounts before the instance becomes usable.
+
+Be sure to replace @code{KUDOS} with the fiat currency if the setup is for an
+actual bank. The @code{name} field will be shown as the name of your shop. The
+@code{address} field is expected to contain your shop’s physical address. The
+various defaults specify defaults for transaction fees your shop is willing to
+cover, how long offers made to the customer are valid, and how long the
+exchange has before it must wire the funds to your bank account. Those
+defaults can be modified for individual orders.  For details, see the
+contract terms specification.
 
 You can then create the instance using:
 
@@ -1638,7 +1509,7 @@ or purge (deleting all associated data) instances exist as well and are document
 in the Merchant Backend API documentation.
 
 @node Secure setup,Customization,Instance setup,Top
-@anchor{taler-merchant-manual id11}@anchor{36}@anchor{taler-merchant-manual secure-setup}@anchor{9}
+@anchor{taler-merchant-manual id8}@anchor{29}@anchor{taler-merchant-manual secure-setup}@anchor{9}
 @chapter Secure setup
 
 
@@ -1646,11 +1517,11 @@ in the Merchant Backend API documentation.
 
 @geindex TLS
 
-The Taler backend does not include even the most basic forms of
-access control or transport layer security.  Thus, production
-setups @strong{must} deploy the Taler backend behind an HTTP(S) server
-that acts as a @emph{reverse proxy}, performs TLS termination and
-authentication and then forwards requests to the backend.
+The Taler backend does not include even the most basic forms of access control
+or transport layer security.  Thus, production setups `must' deploy the
+Taler backend behind an HTTP(S) server that acts as a `reverse proxy',
+performs TLS termination and authentication and then forwards requests to the
+backend.
 
 @menu
 * Using UNIX domain sockets:: 
@@ -1661,29 +1532,30 @@ authentication and then forwards requests to the backend.
 @end menu
 
 @node Using UNIX domain sockets,Reverse proxy configuration,,Secure setup
-@anchor{taler-merchant-manual using-unix-domain-sockets}@anchor{37}
+@anchor{taler-merchant-manual using-unix-domain-sockets}@anchor{2a}
 @section Using UNIX domain sockets
 
 
 To ensure that the merchant backend is not exposed directly to the network,
-you @emph{should} bind the backend to a UNIX domain socket:
+you `should' bind the backend to a UNIX domain socket:
 
 @example
-$ taler-config -s MERCHANT -o SERVE -V UNIX
-$ taler-config -s MERCHANT -o UNIXPATH -V /some/path/here.sock
+$ taler-config -s MERCHANT -o SERVE -V unix
+$ taler-config -s MERCHANT -o UNIXPATH -V "/some/path/here.sock"
 @end example
 
-Do not use a UNIX domain socket path in "/tmp": systemd (or other init
-systems) may give Web servers a private "/tmp" thereby hiding UNIX domain
-sockets created by other users/processes in "/tmp".
+Do not use a UNIX domain socket path in “/tmp”: systemd (or other init
+systems) may give Web servers a private “/tmp” thereby hiding UNIX domain
+sockets created by other users/processes in “/tmp”.
 
-If UNIX domain sockets are for some reason not possible, you @emph{may} use a
+If UNIX domain sockets are for some reason not possible, you `may' use a
 host-based firewall to block access to the TCP port of the merchant backend,
-but this is @emph{not recommended}.  Relying on NAT or network firewalls for access
-control is gross negligence.
+but this is `not recommended'.  If you do need a TCP socket, you should
+instead strongly consider using the “BIND_TO” option to at least bind it only
+to “localhost”.
 
 @node Reverse proxy configuration,Access control,Using UNIX domain sockets,Secure setup
-@anchor{taler-merchant-manual id12}@anchor{38}@anchor{taler-merchant-manual reverse-proxy-configuration}@anchor{32}
+@anchor{taler-merchant-manual id9}@anchor{2b}@anchor{taler-merchant-manual reverse-proxy-configuration}@anchor{27}
 @section Reverse proxy configuration
 
 
@@ -1694,7 +1566,7 @@ control is gross negligence.
 @end menu
 
 @node Nginx,Apache,,Reverse proxy configuration
-@anchor{taler-merchant-manual nginx}@anchor{39}
+@anchor{taler-merchant-manual nginx}@anchor{2c}
 @subsection Nginx
 
 
@@ -1714,7 +1586,7 @@ not have HTTPS enabled.  Make sure to restart the @code{taler-merchant-httpd}
 process after changing the @code{SERVE} configuration.
 
 @node Apache,,Nginx,Reverse proxy configuration
-@anchor{taler-merchant-manual apache}@anchor{3a}
+@anchor{taler-merchant-manual apache}@anchor{2d}
 @subsection Apache
 
 
@@ -1741,223 +1613,324 @@ Note that the above again assumes your domain name is @code{example.com} and tha
 you have TLS configured.  Note that you must add the @code{https} header unless
 your site is not available via TLS.
 
-The above configurations are both incomplete. You must still additionally
-set up access control!
-
 @node Access control,Status code remapping,Reverse proxy configuration,Secure setup
-@anchor{taler-merchant-manual access-control}@anchor{3b}
+@anchor{taler-merchant-manual access-control}@anchor{2e}
 @section Access control
 
 
 All endpoints with @code{/private/} in the URL must be restricted to authorized
 users of the respective instance.  Specifically, the HTTP server must be
-configured to only allow access to @code{$BASE_URL/private/} and
-@code{$BASE_URL/management/} to the authorized users of the default instance, and
-to @code{$BASE_URL/instances/$ID/private/} to the authorized users of the instance
-@code{$ID}.
+configured to only allow access to @code{$BASE_URL/private/} to the authorized
+users of the default instance, and to @code{$BASE_URL/instances/$ID/private/} to
+the authorized users of the instance @code{$ID}.
 
-How access control is done (TLS client authentication, HTTP basic or digest
-authentication, etc.) is completely up to the merchant and does not matter to
-the Taler merchant backend.
+By default, the GNU Taler merchant backend simply requires the respective
+HTTP requests to include an “Authorization” header with a “Bearer” token
+set to the respective shared secret which must begin with “secret-token:”
+(following RFC 8959).
 
-Note that all of the other endpoints (without @code{/private/} or @code{/management/})
+Note that all of the other endpoints (without @code{/private/})
 are expected to be fully exposed to the Internet, and wallets may have to
 interact with those endpoints directly without client authentication.
 
+@node Status code remapping,,Access control,Secure setup
+@anchor{taler-merchant-manual status-code-remapping}@anchor{2f}
+@section Status code remapping
+
+
+Normal API usage leaks instance existence information.  Distinguishing between
+404 (Not found) and 403 (Forbidden) is useful for diagnostics.
+
+For higher security (by leaking less information), you can add the following
+fragment, which remaps all 404 response codes to 403.
+
 @menu
 * Nginx: Nginx<2>. 
 * Apache: Apache<2>. 
 
 @end menu
 
-@node Nginx<2>,Apache<2>,,Access control
-@anchor{taler-merchant-manual id13}@anchor{3c}
+@node Nginx<2>,Apache<2>,,Status code remapping
+@anchor{taler-merchant-manual id10}@anchor{30}
 @subsection Nginx
 
 
-For Nginx, you can implement token-based merchant backend authentication as
-follows:
-
 @example
-location ~ /private/ @{
-    if ($http_authorization !~ "(?i)ApiKey SECURITYTOKEN") @{
-       return 401;
-    @}
-    proxy_pass ...; # as above
-@}
-location /management/ @{
-    if ($http_authorization !~ "(?i)ApiKey SECURITYTOKEN") @{
-       return 401;
-    @}
-    proxy_pass ...; # as above
-@}
+error_page 404 =403 /empty.gif;
 @end example
 
-Here, @code{SECURITYTOKEN} should be replaced with the actual shared secret.  Note
-that the @code{~} ensures that the above matches all endpoints that include the
-string @code{/private/}.  If you only run a single instance, you could simply
-specify @code{/private/} without the @code{~} to only configure the access policy for
-the default instance.
+@node Apache<2>,,Nginx<2>,Status code remapping
+@anchor{taler-merchant-manual id11}@anchor{31}
+@subsection Apache
 
-If you are running different instances on the same backend, you
-likely will want to specify different access control tokens for
-each instance:
 
 @example
-location ~ ^/instances/foo/private/ @{
-    if ($http_authorization !~ "(?i)ApiKey FOOTOKEN") @{
-       return 401;
-    @}
-    proxy_pass ...; # as above
-@}
-location ~ ^/instances/bar/private/ @{
-    if ($http_authorization !~ "(?i)ApiKey BARTOKEN") @{
-       return 401;
-    @}
-    proxy_pass ...; # as above
-@}
-location /private/ @{
-    if ($http_authorization !~ "(?i)ApiKey MASTERTOKEN") @{
-       return 401;
-    @}
-    proxy_pass ...; # as above
-@}
-location /management/ @{
-    if ($http_authorization !~ "(?i)ApiKey MASTERTOKEN") @{
-       return 401;
-    @}
-    proxy_pass ...; # as above
-@}
-location ~ /private/ @{
-    return 401; # access to instances not explicitly configured is forbidden
-@}
+cond %@{STATUS@} =404
+set-status 403
 @end example
 
-@node Apache<2>,,Nginx<2>,Access control
-@anchor{taler-merchant-manual id14}@anchor{3d}
-@subsection Apache
+@node Customization,Upgrade procedure,Secure setup,Top
+@anchor{taler-merchant-manual customization}@anchor{32}
+@chapter Customization
 
 
-For Apache, you should first enable @code{mod_rewrite}:
+@menu
+* Legal conditions for using the service:: 
+* Terms of Service:: 
+* Privacy Policy:: 
+* Legal policies directory layout:: 
+* Generating the Legal Terms:: 
+* Adding translations:: 
+* Updating legal documents:: 
+* Mustach HTML Templates:: 
+* Static files:: 
+* Internationalization:: 
+* Limitations:: 
 
-@example
-$ a2enmod rewrite
-@end example
+@end menu
 
-Then, you can restrict to an access control token using:
+@node Legal conditions for using the service,Terms of Service,,Customization
+@anchor{taler-merchant-manual legal-conditions-for-using-the-service}@anchor{33}
+@section Legal conditions for using the service
 
-@example
-<Location "/">
-RewriteEngine On
-RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=SECURITYTOKEN"
-RewriteRule "(.+)/private/" "-" [F]
-RewriteRule "/management/" "-" [F]
 
-ProxyPass "unix:/some/path/here.sock|http://example.com/"
-</Location>
-@end example
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2023 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU Affero General Public License as published by the Free Software
+@c Foundation; either version 2.1, or (at your option) any later version.
+@c 
+@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Affero General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
 
-Here, @code{SECURITYTOKEN} should be replaced with the actual shared secret.  Note
-that the @code{(.+)} ensures that the above matches all endpoints that include the
-string @code{/private/}.  If you only run a single instance, you could simply
-specify @code{/private/} without the @code{(.+)} to only configure the access policy for
-the default instance.
+The service has well-known API endpoints to return its legal conditions to the
+user in various languages and various formats.  This section describes how to
+setup and configure the legal conditions.
 
-If you are running different instances on the same backend, you
-likely will want to specify different access control tokens for
-each instance:
+@node Terms of Service,Privacy Policy,Legal conditions for using the service,Customization
+@anchor{taler-merchant-manual terms-of-service}@anchor{34}
+@section Terms of Service
 
-@example
-<Location "/instances/foo/">
-RewriteEngine On
-RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=FOOTOKEN"
-RewriteRule "/instances/foo/private/" "-" [F]
 
-ProxyPass ... # as above
-</Location>
+The service has an endpoint “/terms” to return the terms of service (in legal
+language) of the service operator.  Client software show these terms of
+service to the user when the user is first interacting with the service.
+Terms of service are optional for experimental deployments, if none are
+configured, the service will return a simple statement saying that there are
+no terms of service available.
 
-<Location "/instances/bar/">
-RewriteEngine On
-RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=BARTOKEN"
-RewriteRule "/instances/bar/private/" "-" [F]
+To configure the terms of service response, there are two options
+in the configuration file for the service:
 
-ProxyPass ... # as above
-</Location>
 
-<Location "/">
-RewriteEngine On
-RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=MASTERTOKEN"
-RewriteRule "/private/" "-" [F]
-RewriteRule "/management/" "-" [F]
-RewriteRule "(.+)/private/" "-" [F] # reject all others
+@itemize -
 
-ProxyPass ... # as above
-</Location>
-@end example
+@item 
+@code{TERMS_ETAG}: The current “Etag” to return for the terms of service.
+This value must be changed whenever the terms of service are
+updated. A common value to use would be a version number.
+Note that if you change the @code{TERMS_ETAG}, you MUST also provide
+the respective files in @code{TERMS_DIR} (see below).
 
-Please note that these are simply examples of how one could use Nginx or
-Apache2 for access control. Both HTTP servers support many other forms of
-authentication, including TLS client certificates, HTTP basic and digest
-authentication and others, which can all be used (possibly in combination) to
-restrict access to the internal API to authorized clients.
+@item 
+@code{TERMS_DIR}: The directory that contains the terms of service.
+The files in the directory must be readable to the service
+process.
+@end itemize
 
-System administrators are strongly advised to test their access control
-setup before going into production!
+@node Privacy Policy,Legal policies directory layout,Terms of Service,Customization
+@anchor{taler-merchant-manual privacy-policy}@anchor{35}
+@section Privacy Policy
 
-@node Status code remapping,,Access control,Secure setup
-@anchor{taler-merchant-manual status-code-remapping}@anchor{3e}
-@section Status code remapping
 
+The service has an endpoint “/pp” to return the terms privacy policy (in legal
+language) of the service operator.  Clients should show the privacy policy to
+the user when the user explicitly asks for it, but it should not be shown by
+default.  Privacy policies are optional for experimental deployments, if none
+are configured, the service will return a simple statement saying that there
+is no privacy policy available.
 
-Normal API usage leaks instance existence information.
-Distinguishing between 404 (Not found) and 403 (Forbidden)
-is useful for diagnostics.
+To configure the privacy policy response, there are two options
+in the configuration file for the service:
 
-For higher security (by leaking less information),
-you can add the following fragment,
-which remaps all 404 response codes to 403.
+
+@itemize -
+
+@item 
+@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
+This value must be changed whenever the privacy policy is
+updated. A common value to use would be a version number.
+Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
+the respective files in @code{PRIVACY_DIR} (see below).
+
+@item 
+@code{PRIVACY_DIR}: The directory that contains the privacy policy.
+The files in the directory must be readable to the service
+process.
+@end itemize
+
+@node Legal policies directory layout,Generating the Legal Terms,Privacy Policy,Customization
+@anchor{taler-merchant-manual legal-policies-directory-layout}@anchor{36}
+@section Legal policies directory layout
+
+
+The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
+particular layout.  You may use the same directory for both the terms of
+service and the privacy policy, as long as you use different ETAGs.  Inside of
+the directory, there should be sub-directories using two-letter language codes
+like “en”, “de”, or “jp”.  Each of these directories would then hold
+translations of the current terms of service into the respective language.
+Empty directories are permitted in case translations are not available.
+
+Then, inside each language directory, files with the name of the value set as
+the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
+of the files should be typical for the respective mime type.  The set of
+supported mime types is currently hard-coded in the service, and includes
+“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
+the service may show a warning on startup.
 
 @menu
-* Nginx: Nginx<3>. 
-* Apache: Apache<3>. 
+* Example:: 
 
 @end menu
 
-@node Nginx<3>,Apache<3>,,Status code remapping
-@anchor{taler-merchant-manual id15}@anchor{3f}
-@subsection Nginx
+@node Example,,,Legal policies directory layout
+@anchor{taler-merchant-manual example}@anchor{37}
+@subsection Example
+
+
+A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
+
+
+@itemize -
+
+@item 
+TERMS_DIR/en/tos-v0.txt
+
+@item 
+TERMS_DIR/en/tos-v0.html
+
+@item 
+TERMS_DIR/en/tos-v0.pdf
+
+@item 
+TERMS_DIR/en/tos-v0.epub
+
+@item 
+TERMS_DIR/en/tos-v0.md
+
+@item 
+TERMS_DIR/de/tos-v0.txt
+
+@item 
+TERMS_DIR/de/tos-v0.html
+
+@item 
+TERMS_DIR/de/tos-v0.pdf
+
+@item 
+TERMS_DIR/de/tos-v0.epub
+
+@item 
+TERMS_DIR/de/tos-v0.md
+@end itemize
+
+If the user requests an HTML format with language preferences “fr” followed by
+“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+French.
+
+@node Generating the Legal Terms,Adding translations,Legal policies directory layout,Customization
+@anchor{taler-merchant-manual generating-the-legal-terms}@anchor{38}
+@section Generating the Legal Terms
 
 
+The @code{taler-terms-generator} script can be used to generate directories with
+terms of service and privacy policies in multiple languages and all required
+data formats from a single source file in @code{.rst} format and GNU gettext
+translations in @code{.po} format.
+
+To use the tool, you need to first write your legal conditions in English in
+reStructuredText (rst).  You should find a templates in
+@code{$PREFIX/share/terms/*.rst} where @code{$PREFIX} is the location where you
+installed the service to. Whenever you make substantive changes to the legal
+terms, you must use a fresh filename and change the respective @code{ETAG}.  The
+resulting file must be called @code{$ETAG.rst} and the first line of the file should be the title of the document.
+
+Once you have written the @code{$ETAG.rst} file in English, you can
+generate the first set of outputs:
+
 @example
-error_page 404 =403 /empty.gif;
+$ taler-terms-generator -i $ETAG
 @end example
 
-@node Apache<3>,,Nginx<3>,Status code remapping
-@anchor{taler-merchant-manual id16}@anchor{40}
-@subsection Apache
+Afterwards, you should find the terms in various formats for all configured
+languages (initially only English) in @code{$PREFIX/share/terms/}.  The generator
+has a few options which are documented in its man page.
+
+@node Adding translations,Updating legal documents,Generating the Legal Terms,Customization
+@anchor{taler-merchant-manual adding-translations}@anchor{39}
+@section Adding translations
 
 
+Translations must be available in subdirectories
+@code{locale/$LANGUAGE/LC_MESSAGES/$ETAG.po}.
+To start translating, you first need to add a new
+language:
+
 @example
-cond %@{STATUS@} =404
-set-status 403
+$ taler-terms-generator -i $ETAG -l $LANGUAGE
 @end example
 
-@node Customization,Upgrade procedure,Secure setup,Top
-@anchor{taler-merchant-manual customization}@anchor{41}
-@chapter Customization
+Here, @code{$LANGUAGE} should be a two-letter language
+code like @code{de} or @code{fr}.  The command will generate
+a file @code{locale/$LANGUAGE/LC_MESSAGES/$ETAG.po}
+which contains each English sentence or paragraph
+in the original document and an initially empty
+translation.  Translators should update the @code{.po}
+file. Afterwards, simply re-run
 
+@example
+$ taler-terms-generator -i $ETAG
+@end example
 
-@menu
-* Templates:: 
-* Static files:: 
-* Internationalization:: 
-* Limitations:: 
+to make the current translation(s) available to the
+service.
 
-@end menu
+@cartouche
+@quotation Note 
+You must restart the service whenever adding or updating legal documents or their translations.
+@end quotation
+@end cartouche
+
+@node Updating legal documents,Mustach HTML Templates,Adding translations,Customization
+@anchor{taler-merchant-manual updating-legal-documents}@anchor{3a}
+@section Updating legal documents
+
+
+When making minor changes without legal implications, edit the @code{.rst} file,
+then re-run the step to add a new language for each existing translation to
+produce an updated @code{.po} file. Translate the sentences that have changed and
+finally run the generator (without @code{-l}) on the ETAG (@code{-i $ETAG}) to
+create the final files.
+
+When making major changes with legal implications, you should first rename (or
+copy) the existing @code{.rst} file and the associated translation files to a new
+unique name.  Afterwards, make the major changes, update the @code{.po} files,
+complete the translations and re-create the final files.  Finally, do not
+forget to update the @code{ETAG} configuration option to the new name and to
+restart the service.
 
-@node Templates,Static files,,Customization
-@anchor{taler-merchant-manual templates}@anchor{42}
-@section Templates
+@node Mustach HTML Templates,Static files,Updating legal documents,Customization
+@anchor{taler-merchant-manual mustach-html-templates}@anchor{3b}
+@section Mustach HTML Templates
 
 
 The installation process will install various HTML templates to be served
@@ -1965,8 +1938,8 @@ to trigger the wallet interaction. You may change those templates to your
 own design. The templating language used is Mustach, and the templates
 are in the @code{share/taler/merchant/templates/} directory.
 
-@node Static files,Internationalization,Templates,Customization
-@anchor{taler-merchant-manual static-files}@anchor{43}
+@node Static files,Internationalization,Mustach HTML Templates,Customization
+@anchor{taler-merchant-manual static-files}@anchor{3c}
 @section Static files
 
 
@@ -1976,7 +1949,7 @@ logic to load a CSS file, but you can also put other resources such as
 images or JavaScript.
 
 @node Internationalization,Limitations,Static files,Customization
-@anchor{taler-merchant-manual internationalization}@anchor{44}
+@anchor{taler-merchant-manual internationalization}@anchor{3d}
 @section Internationalization
 
 
@@ -1993,16 +1966,17 @@ returned. Otherwise, an internationalized file based on the language
 preferences indicated by the browser is returned.
 
 @node Limitations,,Internationalization,Customization
-@anchor{taler-merchant-manual limitations}@anchor{45}
+@anchor{taler-merchant-manual limitations}@anchor{3e}
 @section Limitations
 
 
 All of the static files must fit into memory and it must be possible for the
 process to hold open file handles for all of these files.  You may want
 to increase the @code{ulimit} of the @code{taler-merchant-httpd} process if you have
-templates for many languages.
+many static files. Note that Mustach templates do not increase the number of
+open files.
 
-The backend determines the MIME type based on the file's extension. The list
+The backend determines the MIME type based on the file’s extension. The list
 of supported extensions is hard-coded and includes common text and image
 formats.
 
@@ -2010,13 +1984,13 @@ The current backend only provides a limited set of variables for the Mustach
 template expansion, and does not make use of scopes and other Mustach
 features.
 
-@node Upgrade procedure,Tipping visitors,Customization,Top
-@anchor{taler-merchant-manual upgrade-procedure}@anchor{46}
+@node Upgrade procedure,Advanced topics,Customization,Top
+@anchor{taler-merchant-manual upgrade-procedure}@anchor{3f}
 @chapter Upgrade procedure
 
 
-This is the general upgrade procedure.  Please see the release notes
-for your specific version to check if a particular release has special
+This section describes the general upgrade procedure.  Please see the release
+notes for your specific version to check if a particular release has special
 upgrade requirements.
 
 Please note that upgrades are ONLY supported for released version of the
@@ -2035,147 +2009,22 @@ $ taler-merchant-dbinit
 @end example
 
 to upgrade the database to the latest schema.  After that, you may again
-REVOKE the database permissions. Finally, restart the HTTP service, either via
-your systemd or init system, or directly using:
-
-@example
-$ taler-merchant-httpd
-@end example
-
-@node Tipping visitors,Advanced topics,Upgrade procedure,Top
-@anchor{taler-merchant-manual id17}@anchor{47}@anchor{taler-merchant-manual tipping-visitors}@anchor{48}
-@chapter Tipping visitors
-
-
-@geindex tipping
-
-Taler can also be used to tip Web site visitors. For example, you may be
-running an online survey, and you want to reward those people that have
-dutifully completed the survey. If they have installed a Taler wallet,
-you can provide them with a tip for their deeds. This section describes
-how to setup the Taler merchant backend for tipping.
-
-There are three basic steps that must happen to tip a visitor.
-
-@menu
-* Fund the reserve:: 
-* Authorize a tip:: 
-* Picking up of the tip:: 
-
-@end menu
-
-@node Fund the reserve,Authorize a tip,,Tipping visitors
-@anchor{taler-merchant-manual fund-the-reserve}@anchor{49}@anchor{taler-merchant-manual id18}@anchor{4a}
-@section Fund the reserve
-
-
-@geindex reserve
-
-First, the reserve must be setup in the merchant backend. A reserve
-is always tied to a particular instance. To create a reserve with
-10 KUDOS at instance @code{default} using the demo exchange, use:
-
-@example
-$ taler-merchant-setup-reserve \
-    -a KUDOS:10 \
-    -e https://exchange.demo.taler.net/ \
-    -m http://localhost:8888/instances/default
-@end example
-
-The above command assumes that the merchant runs on localhost on
-port 8888.
-For more information, including how to transmit authentication information
-to the backend, see manpages/taler-merchant-setup-reserve.1.
-
-The command will output a @code{payto://} URI which specifies where to
-wire the funds and which wire transfer subject to use.
-
-FIXME: add full example output.
-
-In our example, the output for the wire transfer subject is:
-
-@example
-QPE24X8PBX3BZ6E7GQ5VAVHV32FWTTCADR0TRQ183MSSJD2CHNEG
-@end example
-
-You now need to make a wire transfer to the exchange’s bank account
-using the given wire transfer subject.
-
-Make your wire transfer and (optionally) check at
-“@indicateurl{https://exchange/reserves/QPE24X}...” whether your transfer has arrived at the
-exchange.
-
-Once the funds have arrived, you can start to use the reserve for
-tipping.
-
-Note that an exchange will typically close a reserve after four weeks, wiring
-all remaining funds back to the sender’s account. Thus, you should plan to
-wire funds corresponding to a campaign of about two weeks to the exchange
-initially. If your campaign runs longer, you should setup another reserve
-every other week to ensure one is always ready.
-
-@node Authorize a tip,Picking up of the tip,Fund the reserve,Tipping visitors
-@anchor{taler-merchant-manual authorize-a-tip}@anchor{4b}@anchor{taler-merchant-manual id19}@anchor{4c}
-@section Authorize a tip
-
-
-When your frontend has reached the point where a client is supposed to receive
-a tip, it needs to first authorize the tip. For this, the frontend must use
-a POST to @code{/private/reserves/$RESERVE_PUB/authorize-tip}. To authorize a
-tip, the frontend has to provide the following information in the body of the
-POST request:
-
-
-@itemize -
-
-@item 
-The amount of the tip
-
-@item 
-The justification (only used internally for the back-office)
-
-@item 
-The URL where the wallet should navigate next after the tip was
-processed
+REVOKE the database permissions. Finally, restart the merchant services
+processes, either via your systemd or init system, or directly.
 
-@item 
-The tip-pickup URL (see next section)
-@end itemize
-
-In response to this request, the backend will return a tip token, an
-expiration time and the exchange URL. The expiration time will indicate
-how long the tip is valid (when the reserve expires). The tip token is
-an opaque string that contains all the information needed by the wallet
-to process the tip. The frontend must send this tip token to the browser
-in a special “402 Payment Required” response inside the @code{X-Taler-Tip}
-header.
-
-The frontend should handle errors returned by the backend, such as
-misconfigured instances or a lack of remaining funds for tipping.
-
-@node Picking up of the tip,,Authorize a tip,Tipping visitors
-@anchor{taler-merchant-manual id20}@anchor{4d}@anchor{taler-merchant-manual picking-up-of-the-tip}@anchor{4e}
-@section Picking up of the tip
-
-
-The wallet will POST a JSON object to the shop’s
-@code{/tips/$TIP_ID/pickup} handler.
-The frontend must then forward this request to the backend. The response
-generated by the backend can then be forwarded directly to the wallet.
-
-@node Advanced topics,Advanced experimental features,Tipping visitors,Top
-@anchor{taler-merchant-manual advanced-topics}@anchor{4f}
+@node Advanced topics,Temporarily Abandoned Features,Upgrade procedure,Top
+@anchor{taler-merchant-manual advanced-topics}@anchor{40}
 @chapter Advanced topics
 
 
 @menu
 * Database Scheme:: 
-* Configuration format: Configuration format<2>. 
+* Benchmarking:: 
 
 @end menu
 
-@node Database Scheme,Configuration format<2>,,Advanced topics
-@anchor{taler-merchant-manual database-scheme}@anchor{50}@anchor{taler-merchant-manual merchantdatabasescheme}@anchor{51}
+@node Database Scheme,Benchmarking,,Advanced topics
+@anchor{taler-merchant-manual database-scheme}@anchor{41}@anchor{taler-merchant-manual merchantdatabasescheme}@anchor{42}
 @section Database Scheme
 
 
@@ -2190,353 +2039,77 @@ The database scheme used by the merchant looks as follows:
 
 @image{taler-merchant-figures/merchant-db,,,,png}
 
-@node Configuration format<2>,,Database Scheme,Advanced topics
-@anchor{taler-merchant-manual id21}@anchor{52}
-@section Configuration format
-
-
-@geindex configuration
-
-In Taler realm, any component obeys to the same pattern to get
-configuration values. According to this pattern, once the component has
-been installed, the installation deploys default values in
-@code{$@{prefix@}/share/taler/config.d/}, in @code{.conf} files. In order to override
-these defaults, the user can write a custom .conf file and either pass
-it to the component at execution time, or name it @code{taler.conf} and place
-it under @code{$HOME/.config/}.
-
-A config file is a text file containing sections, and each section
-contains its values. The right format follows:
-
-@example
-[section1]
-value1 = string
-value2 = 23
-
-[section2]
-value21 = string
-value22 = /path22
-@end example
-
-Throughout any configuration file, it is possible to use @code{$}-prefixed
-variables, like @code{$VAR}, especially when they represent filesystem
-paths. It is also possible to provide defaults values for those
-variables that are unset, by using the following syntax:
-@code{$@{VAR:-default@}}. However, there are two ways a user can set
-@code{$}-prefixable variables:
-
-by defining them under a @code{[paths]} section, see example below,
-
-@example
-[paths]
-TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
-...
-[section-x]
-path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
-@end example
-
-or by setting them in the environment:
-
-@example
-$ export VAR=/x
-@end example
-
-The configuration loader will give precedence to variables set under
-@code{[path]}, though.
-
-The utility @code{taler-config}, which gets installed along with the
-exchange, serves to get and set configuration values without directly
-editing the @code{.conf}. The option @code{-f} is particularly useful to resolve
-pathnames, when they use several levels of @code{$}-expanded variables. See
-@code{taler-config --help}.
+@node Benchmarking,,Database Scheme,Advanced topics
+@anchor{taler-merchant-manual benchmarking}@anchor{43}@anchor{taler-merchant-manual merchantbenchmarking}@anchor{44}
+@section Benchmarking
 
-Note that, in this stage of development, the file
-@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
-components. For example, both an exchange and a bank can read values from
-it.
 
-The deployment repository@footnote{https://git.taler.net/deployment} contains examples of
-configuration file used in our demos. See under @code{deployment/config}.
+The merchant codebase offers the @code{taler-merchant-benchmark} tool to populate
+the database with fake payments.  The main goal of the benchmarking tool is to
+serve as a starting point (!) for merchants that are interested in developing
+stress tests to see how far their infrastructure can scale. As is, it
+currently is not actually good at stressing the payment system.
 
-@quotation
+The @code{taler-unified-setup.sh} script can be used to launch all required
+services and clients. However, the resulting deployment is simplistic
+(everything on the local machine, one single-threaded process per service
+type) and not optimized for performance at all. However, this can still be
+useful to assess the performance impact of changes
+to the code or configuration.
 
-@strong{Note}
+Various configuration files that can be used in the code snippets in this
+section can be found in the @code{src/merchant-tools/} directory of the
+merchant. These are generally intended as starting points.  Note that the
+configuration files ending in @code{.edited} are created by
+@code{taler-unified-setup.sh} and contain some options that are determined at
+runtime by the setup logic provided by @code{taler-unified-setup.sh}.
 
-Expectably, some components will not work just by using default
-values, as their work is often interdependent. For example, a
-merchant needs to know an exchange URL, or a database name.
-@end quotation
+See Taler Exchange Manual for how to use @code{taler-unified-setup.sh} to setup the system and in particular on how to specify the bank to be used.
 
 @menu
-* Using taler-config: Using taler-config<2>. 
+* Running taler-merchant-benchmark:: 
 
 @end menu
 
-@node Using taler-config<2>,,,Configuration format<2>
-@anchor{taler-merchant-manual id22}@anchor{53}@anchor{taler-merchant-manual using-taler-002dconfig}@anchor{54}
-@subsection Using taler-config
-
-
-@geindex taler-config
-
-The tool @code{taler-config} can be used to extract or manipulate
-configuration values; however, the configuration use the well-known INI
-file format and can also be edited by hand.
-
-Run:
-
-@example
-$ taler-config -s $SECTION
-@end example
-
-to list all of the configuration values in section @code{$SECTION}.
-
-Run:
-
-@example
-$ taler-config -s $section -o $option
-@end example
+@node Running taler-merchant-benchmark,,,Benchmarking
+@anchor{taler-merchant-manual running-taler-merchant-benchmark}@anchor{45}
+@subsection Running taler-merchant-benchmark
 
-to extract the respective configuration value for option @code{$option} in
-section @code{$section}.
 
-Finally, to change a setting, run:
+You can run the tool as follows:
 
 @example
-$ taler-config -s $section -o $option -V $value
+$ CONF=benchmark-rsa.conf
+$ taler-unified-setup.sh -emwt -c "$CONF" -f -u exchange-account-1
+$ time taler-merchant-benchmark ordinary -c "$CONF".edited -u exchange-account-1 -f -p 20
 @end example
 
-to set the respective configuration value to @code{$value}. Note that you
-have to manually restart the Taler backend after you change the
-configuration to make the new configuration go into effect.
-
-Some default options will use @code{$}-variables, such as @code{$DATADIR} within
-their value. To expand the @code{$DATADIR} or other @code{$}-variables in the
-configuration, pass the @code{-f} option to @code{taler-config}. For example,
-compare:
-
-@example
-$ taler-config -s PATHS \
-               -o TALER_DATA_HOME
-$ taler-config -f -s PATHS \
-               -o TALER_DATA_HOME
-@end example
-
-While the configuration file is typically located at
-@code{$HOME/.config/taler.conf}, an alternative location can be specified
-to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
-option.
-
-@node Advanced experimental features,Temporarily Abandoned Features,Advanced topics,Top
-@anchor{taler-merchant-manual advanced-experimental-features}@anchor{55}
-@chapter Advanced experimental features
-
-
-This section describes features that most merchants will not
-need, or will not need initially.
-
-@menu
-* Benchmarking:: 
-* Benchmark setup:: 
-* Running the benchmark command:: 
-
-@end menu
-
-@node Benchmarking,Benchmark setup,,Advanced experimental features
-@anchor{taler-merchant-manual benchmarking}@anchor{56}@anchor{taler-merchant-manual merchantbenchmarking}@anchor{57}
-@section Benchmarking
-
-
-The merchant codebase offers the @code{taler-merchant-benchmark} tool to
-populate the database with fake payments. This tool is in charge of
-starting a merchant, exchange, and bank processes, and provides them all
-the input to accomplish payments. Note that each component will use its
-own configuration (as they would do in production).
-
-The main goal of the benchmarking tool is to serve as a starting point (!) for
-merchants that are interested in developing stress tests to see how far their
-infrastructure can scale.
-
 The current tool has already a few options, but we expect that to deliver
-@emph{relevant} results it will need to be customized to better reflect the
+`relevant' results it will need to be customized to better reflect the
 workload of a particular merchant.  This customization would at this point
 likely involve writing (C) code.  We welcome contributions to make it easier
 to customize the benchmark and/or to cover more realistic workloads from the
 start.
 
-@node Benchmark setup,Running the benchmark command,Benchmarking,Advanced experimental features
-@anchor{taler-merchant-manual benchmark-setup}@anchor{58}
-@section Benchmark setup
-
-
-The @code{taler-merchant-benchmark} tool will automatically launch and configure the
-exchange, (Python) bank and other tools required for the benchmark. However,
-the configuration file must be provided and have consistent options set.  The
-options that require special care include the exchange's public key (which
-must match the private key in the file specified by the configuration), the
-currency (which must be consistent across the file), the denomination
-structure (which must enable payments in the range of 100ths of the unit
-currency (often called cents)). Furthermore, the benchmark will set the
-Exchange bank account password to be "x", so the configuration must also
-specify "x" for the passphrase.  Finally, the bank must be configured to allow
-for substantial debt least the transactions by the benchmark run out of
-digital cash.
-
-A relatively minimal configuration could look like this:
-
-@example
-[PATHS]
-# Persistent data storage for the benchmark
-TALER_TEST_HOME = benchmark_home/
-
-[taler]
-# If you change the currency here, you MUST change it
-# throughout the file.
-CURRENCY = EUR
-CURRENCY_ROUND_UNIT = EUR:0.01
-
-[merchant]
-SERVE = tcp
-PORT = 8080
-DB = postgres
-
-[merchantdb-postgres]
-CONFIG = postgres:///talercheck
-
-[exchange]
-DB = postgres
-SERVE = tcp
-PORT = 8081
-BASE_URL = http://localhost:8081/
-MASTER_PUBLIC_KEY = T1VVFQZZARQ1CMF4BN58EE7SKTW5AV2BS18S87ZEGYS4S29J6DNG
-
-[exchangedb-postgres]
-CONFIG = postgres:///talercheck
-
-[auditor]
-DB = postgres
-SERVE = tcp
-PORT = 8083
-BASE_URL = http://the.auditor/
-
-[auditordb-postgres]
-CONFIG = postgres:///talercheck
-
-[bank]
-DATABASE = postgres:///talerbank
-SERVE = http
-HTTP_PORT = 8082
-MAX_DEBT = EUR:5000.0
-MAX_DEBT_BANK = EUR:0.0
-
-[merchant-exchange-test]
-MASTER_KEY = T1VVFQZZARQ1CMF4BN58EE7SKTW5AV2BS18S87ZEGYS4S29J6DNG
-EXCHANGE_BASE_URL = http://localhost:8081/
-CURRENCY = EUR
-
-[exchange-account-exchange]
-# The account name MUST be 'Exchange'
-PAYTO_URI = payto://x-taler-bank/localhost/Exchange
-WIRE_RESPONSE = $@{TALER_CONFIG_HOME@}/exchange/account.json
-WIRE_GATEWAY_URL = http://localhost:8082/taler-wire-gateway/Exchange/
-WIRE_GATEWAY_AUTH_METHOD = basic
-USERNAME = Exchange
-# The password MUST be 'x'
-PASSWORD = x
-ENABLE_DEBIT = YES
-ENABLE_CREDIT = YES
-
-[fees-x-taler-bank]
-WIRE-FEE-2020 = EUR:0.01
-WIRE-FEE-2021 = EUR:0.01
-WIRE-FEE-2022 = EUR:0.01
-WIRE-FEE-2023 = EUR:0.01
-WIRE-FEE-2024 = EUR:0.01
-WIRE-FEE-2025 = EUR:0.01
-WIRE-FEE-2026 = EUR:0.01
-WIRE-FEE-2027 = EUR:0.01
-CLOSING-FEE-2020 = EUR:0.01
-CLOSING-FEE-2021 = EUR:0.01
-CLOSING-FEE-2022 = EUR:0.01
-CLOSING-FEE-2023 = EUR:0.01
-CLOSING-FEE-2024 = EUR:0.01
-CLOSING-FEE-2025 = EUR:0.01
-CLOSING-FEE-2026 = EUR:0.01
-CLOSING-FEE-2027 = EUR:0.01
-
-[coin_eur_ct_1]
-value = EUR:0.01
-duration_withdraw = 7 days
-duration_spend = 2 years
-duration_legal = 3 years
-fee_withdraw = EUR:0.00
-fee_deposit = EUR:0.00
-fee_refresh = EUR:0.01
-fee_refund = EUR:0.01
-rsa_keysize = 1024
-
-[coin_eur_ct_10]
-value = EUR:0.10
-duration_withdraw = 7 days
-duration_spend = 2 years
-duration_legal = 3 years
-fee_withdraw = EUR:0.01
-fee_deposit = EUR:0.01
-fee_refresh = EUR:0.03
-fee_refund = EUR:0.01
-rsa_keysize = 1024
-
-[coin_eur_1]
-value = EUR:1
-duration_withdraw = 7 days
-duration_spend = 2 years
-duration_legal = 3 years
-fee_withdraw = EUR:0.01
-fee_deposit = EUR:0.01
-fee_refresh = EUR:0.03
-fee_refund = EUR:0.01
-rsa_keysize = 1024
-
-[coin_eur_5]
-value = EUR:5
-duration_withdraw = 7 days
-duration_spend = 2 years
-duration_legal = 3 years
-fee_withdraw = EUR:0.01
-fee_deposit = EUR:0.01
-fee_refresh = EUR:0.03
-fee_refund = EUR:0.01
-rsa_keysize = 1024
-
-@end example
-
-Note that the public key must match the exchange's
-private key and that the PostgreSQL database must
-exist before launching the benchmark.  You also
-will need to ensure that the Exchange's
-details are set up.
-For details, see the Exchange Operator Manual.
-
-@node Running the benchmark command,,Benchmark setup,Advanced experimental features
-@anchor{taler-merchant-manual running-the-benchmark-command}@anchor{59}
-@section Running the benchmark command
-
-
 The tool takes all of the values it needs from the command line, with
-one of them being mandatory:
+some of them being common to all subcommands:
 
 
 @itemize -
 
 @item 
-@code{--exchange-account=SECTION} Specifies which configuration
+@code{--exchange-account-section=SECTION} Specifies which configuration
 section specifies the bank account for the exchange that
 should be used for the benchmark. For the example
 configuration above, the SECTION value provided must be
 @code{exchange-account-exchange}.
+
+@item 
+@code{--fakebank} Specifies that the benchmark should expect to interact
+with a fakebank (instead of libeufin).
 @end itemize
 
-The tool comes with two operation modes: @emph{ordinary}, and @emph{corner}.
+The tool comes with two operation modes: `ordinary', and `corner'.
 The first just executes normal payments, meaning that it uses the
 default instance and make sure that all payments get aggregated. The
 second gives the chance to leave some payments unaggregated, and also to
@@ -2554,43 +2127,34 @@ possibilities. For example:
 $ taler-merchant-benchmark corner --help
 @end example
 
-will show all the options offered by the @emph{corner} mode. Among the most
+will show all the options offered by the `corner' mode. Among the most
 interesting, there are:
 
 
 @itemize -
 
 @item 
-@code{--two-coins=TC} This option instructs the tool to perform @emph{TC}
+@code{--two-coins=TC} This option instructs the tool to perform `TC'
 many payments that use two coins, because normally only one coin is
 spent per payment.
 
 @item 
 @code{--unaggregated-number=UN} This option instructs the tool to
-perform @emph{UN} (one coin) payments that will be left unaggregated.
+perform `UN' (one coin) payments that will be left unaggregated.
 @end itemize
 
 As for the @code{ordinary} subcommand, it is worth explaining the following
-options:
+option:
 
 
 @itemize -
 
 @item 
-@code{--payments-number=PN} Instructs the tool to perform @emph{PN} payments.
-
-@item 
-@code{--tracks-number=TN} Instructs the tool to perform @emph{TN} tracking
-operations. Note that the @strong{total} amount of operations will be two
-times @emph{TN}, since "one" tracking operation accounts for
-@code{/track/transaction} and @code{/track/transfer}. This command should
-only be used to see if the operation ends without problems, as no
-actual measurement of performance is provided (despite of the
-’benchmark’ word used in the tool’s name).
+@code{--payments-number=PN} Instructs the tool to perform `PN' payments.
 @end itemize
 
-@node Temporarily Abandoned Features,Index,Advanced experimental features,Top
-@anchor{taler-merchant-manual temporarily-abandoned-features}@anchor{5a}
+@node Temporarily Abandoned Features,Index,Advanced topics,Top
+@anchor{taler-merchant-manual temporarily-abandoned-features}@anchor{46}
 @chapter Temporarily Abandoned Features
 
 
@@ -2600,7 +2164,7 @@ actual measurement of performance is provided (despite of the
 @end menu
 
 @node Installing Taler using Docker,,,Temporarily Abandoned Features
-@anchor{taler-merchant-manual installing-taler-using-docker}@anchor{5b}
+@anchor{taler-merchant-manual installing-taler-using-docker}@anchor{47}
 @section Installing Taler using Docker
 
 
@@ -2612,7 +2176,7 @@ the @code{docker} command should connect to a @code{docker-machine} instance
 that uses the VirtualBox driver.
 
 Therefore, the needed tools are: “docker“, “docker-machine“, and
-“docker-compose“. Please refer to Docker’s official  @footnote{@w{(1)} 
+“docker-compose“. Please refer to Docker’s official  @footnote{
 @indicateurl{https://docs.docker.com/}
 } documentation
 in order to get those components installed, as that is not in this