From ce22ffac43f8de45fa1fcf98bed572ce7be63f7b Mon Sep 17 00:00:00 2001 From: Marc Stibane Date: Wed, 25 Oct 2023 09:29:50 +0200 Subject: DD 51: removed decimal_separator, group_separator and is_currency_name_leading (they should always be taken from the user's locale) --- design-documents/051-fractional-digits.rst | 88 +++++++++++++----------------- 1 file changed, 39 insertions(+), 49 deletions(-) (limited to 'design-documents') diff --git a/design-documents/051-fractional-digits.rst b/design-documents/051-fractional-digits.rst index 31e2959d..acd19f14 100644 --- a/design-documents/051-fractional-digits.rst +++ b/design-documents/051-fractional-digits.rst @@ -19,7 +19,7 @@ end-user apps should follow these guidelines. Requirements ============ -There is already a specification for ScopedCurrencyInfo - this needs to change +There was already a specification for ScopedCurrencyInfo - which got renamed to CurrencySpecification. We need three core characteristics for fractional digits for each currency: @@ -30,22 +30,23 @@ n) the number of fractional digits n in [0..8] to be rendered as 'n'ormal charac The UI should never round or truncate any amount, but always render all existing digits (except trailing zeroes, see c). z) the number of fractional digits z in [0..8] to be rendered as trailing 'z'eroes (including SuperScript digits). - E.g. if z = 2 (and n = 2), then render $5 as “$ 5.00”. - If z = 3 (and n = 2), then render $5 as “$ 5.00⁰” with two normal trailing zeroes and one superscript trailing zero. + E.g. if z = 2 (and n = 2), then render $5 as `$ 5.00´. + If z = 3 (and n = 2), then render $5 as `$ 5.00⁰´ with two normal trailing zeroes and one superscript trailing zero. The values e, n, and z are independent from each other. Each could be any value from 0 to 8. However, when a user enters an amount, s/he should be able to input all normal fractionals. Thus e should never be smaller than n. Usually, all these three numbers have the same value (e = n = z), which means -that in case of e.g. “2” (used for €,$,£) the user can enter cent/penny values +that in case of e.g. '2' (used for €,$,£) the user can enter cent/penny values (but not a fraction of those), these cents/pennies are always shown (even if they are 0) as two normal digits after the decimal separator, and fractions of a cent/penny are rendered as SuperScriptDigits, but appear only if they are not trailing zeroes. For japanese ¥, all three values could be 0, which means that the user cannot -enter fractionals at all. Fractions would never be rendered as normal digits -but always as SuperScript, and appear only if they are not trailing zeroes. +enter fractions at all. If there are fractions they would never be rendered as +normal digits but always as SuperScript, and appear only if they are not +trailing zeroes. Additionally, some cryptocurrencies have such huge units, that they are commonly rendered in milli-units, such as mBTC (milliBTC, 1/1000 of a BTC), @@ -57,20 +58,6 @@ could also make sense for inflated currencies in some cases. So we probably should also have the ability to ship such a conversion map. - -iOS has a built-in currency formatter, which knows how to deal with -thousands-separators and where to apply them (e.g. India uses a mixture of -hundreds and thousands instead of putting the separator after each 3 digits -like western currencies). However, this formatter will round after two (or -three) fractional digits and thus cannot be used for the whole amount. But it -could be used to convert the integer part plus the fractional part to be -rendered as normal digits (n) into a string, and then remaining fractional -digits (if not zero, or if trailing SuperScript zeroes should be shown) -could be added as SuperScript digits to this formatted string. - -(please add information about Android and WebEx here) - - Proposed Solution ================= @@ -78,7 +65,7 @@ Protocol considerations ----------------------- The exchange, bank and merchant backends would need to be configured (via -their configuration files) to return the following ScopedCurrencyInfo in their +their configuration files) to return the following CurrencySpecification in their ``/config`` and/or ``/keys`` endpoints. The bank returns this so that the bank SPA can render amounts correctly, the exchange informs the wallets about the desired way to render the currency, and the merchant backend informs the @@ -88,34 +75,37 @@ provisioned by all three services. .. code-block:: swift - public struct ScopedCurrencyInfo: Codable, Sendable { + public struct CurrencySpecification: Codable, Sendable { // e.g. “Japanese Yen” or "Bitcoin (Mainnet)" let name: String - // e.g. “.” for $ and ¥; “,” for € - let decimal_separator: String - // how many digits the user may enter after the decimalSeparator - let num_fractional_input_digits: Integer + // how many digits the user may enter after the decimal separator + let fractional_input_digits: Int // €,$,£: 2; some arabic currencies: 3, ¥: 0 - let num_fractional_normal_digits: Int - // usually same as numFractionalNormalDigits, but e.g. might be 2 for ¥ - let num_fractional_trailing_zero_digits: Int - // true for “$ 3.50”; false for “3,50 €” - let is_currency_name_leading: Bool - // map of powers of 10 to alternative currency names / symbols, must - // always have an entry under "0" that defines the base name, - // e.g. "0 => €" or "3 => k€". For BTC, would be "0 => BTC, -3 => mBTC". + let fractional_normal_digits: Int + // usually same as fractionalNormalDigits, but e.g. might be 2 for ¥ + let fractional_trailing_zero_digits: Int + // map of powers of 10 to alternative currency names / symbols, + // must always have an entry under "0" that defines the base name, + // e.g. "0 : €" or "3 : k€". For BTC, would be "0 : BTC, -3 : mBTC". // This way, we can also communicate the currency symbol to be used. - let alt_unit_names: Map + let alt_unit_names: [Int : String] } +(Note: decimal_separator, group_separator and is_currency_name_leading were +removed from this struct since they should always be taken from the user's +locale.) + + + + For very large (2400000) or very tiny amounts (0.000056) the software would then first represent the number compactly without any fraction (so for our examples above, 24 * 10^6 and 56 * 10^-6) and then search for the nearest fit in the alt_unit_names table. The result might then be 24000 KGELD or 0.056 mGELD, assuming the map had entries for 3 and -3 respectively. Depending on -the table, the result could also be 24 MGELD (6 => MGELD), or 5.6 nGELD -(assuming -6 => nGeld). Fractional rendering rules would still be applied -to the alternative unit name, alas the "num_fractional_input_digits" would +the table, the result could also be 24 MGELD (6 : MGELD), or 5.6 nGELD +(assuming -6 : nGeld). Fractional rendering rules would still be applied +to the alternative unit name, alas the "fractional_input_digits" would always apply to the unit currency and may need to be adjusted if amounts are input using an alternative unit name. @@ -132,52 +122,52 @@ section. The map could be given directly in JSON. For example: ENABLED = YES name = "Euro" code = "EUR" - decimal_separator = "," fractional_input_digits = 2 fractional_normal_digits = 2 fractional_trailing_zero_digits = 2 - is_currency_name_leading = NO alt_unit_names = {"0":"€"} [currency-japanese-yen] ENABLED = YES name = "Japanese Yen" code = "JPY" - decimal_separator = "." fractional_input_digits = 2 fractional_normal_digits = 0 fractional_trailing_zero_digits = 2 - is_currency_name_leading = YES alt_unit_names = {"0":"¥"} [currency-bitcoin-mainnet] ENABLED = NO name = "Bitcoin (Mainnet)" code = "BITCOINBTC" - decimal_separator = "." fractional_input_digits = 8 fractional_normal_digits = 3 fractional_trailing_zero_digits = 0 - is_currency_name_leading = NO alt_unit_names = {"0":"BTC","-3":"mBTC"} [currency-ethereum] ENABLED = NO name = "WAI-ETHER (Ethereum)" code = "EthereumWAI" - decimal_separator = "." fractional_input_digits = 0 fractional_normal_digits = 0 fractional_trailing_zero_digits = 0 - is_currency_name_leading = NO alt_unit_names = {"0":"WAI","3":"KWAI","6":"MWAI","9":"GWAI","12":"Szabo","15":"Finney","18":"Ether","21":"KEther","24":"MEther"} Implementation considerations ----------------------------- -For iOS, we plan to format the integer part of the amount with the built-in -currency formatter, then add the fractional part according to this document. +iOS has a built-in currency formatter, which can be configured from a locale. +It knows how to deal with group-separators and where to apply them (e.g. India +uses a mixture of thousands and hundreds instead of putting the separator after +each 3 digits like western currencies). +Set the formatter's parameter 'maximumFractionDigits' to 8, then it will not +round the value and thus can be used for the whole amount. +Set its parameter 'minimumFractionDigits' to 'z' (fractionalTrailingZeroDigits) +to let it automatically add trailing zeroes. +Then convert all fractional digits after 'n' (fractionalNormalDigits) to +SuperScript digits. (please add information about Android and WebEx here) @@ -213,7 +203,7 @@ Discussion / Q&A We probably should NOT have the decimalSeparator in this definition. Instead that should be taken from the locale of the user, so they see currency amounts formatted like they're used to. -If we really keep this, then we would also need the thousandsSeparator to ensure it is +If we really keep this, then we would also need the groupSeparator to ensure it is not identical to the decimalSeparator. Better to leave this can of worms to the operating system our app runs on, and render according to the user's preferences (locale)... -- cgit v1.2.3 From e691373fd1c176729875524d23ad38df9cea2599 Mon Sep 17 00:00:00 2001 From: MS Date: Fri, 27 Oct 2023 12:30:44 +0200 Subject: DD 50 Cutting the step where Nexus asks to the bank to confirm their bank account metadata. --- design-documents/050-libeufin-nexus.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'design-documents') diff --git a/design-documents/050-libeufin-nexus.rst b/design-documents/050-libeufin-nexus.rst index 779e0b58..a471007e 100644 --- a/design-documents/050-libeufin-nexus.rst +++ b/design-documents/050-libeufin-nexus.rst @@ -315,3 +315,17 @@ Discussion / Q&A the bank response, may lead double-submission even if the HTTP talk ended well: it suffices to crash after having received a "200 OK" response but before setting the submitted flag to the database. + +* Given that PostFinance does not provide the IBAN & BIC pair + on HTD (or other "admin" message types), the client cannot + confirm the bank account metadata with the bank. As a result, + it can only rely on what the configuration has in the + ACCOUNT_NUMBER value. + + The current design however does NOT mandate any particular + format for such configuration value, and given that the debtor + BIC is mandatory in the pain.001 generation, ACCOUNT_NUMBER + should be a Payto address with BIC and account holder name. + + Possibly, it may even be renamed to better match its content, + for example to ACCOUNT_METADATA. -- cgit v1.2.3 From 2edbf79c7735edd923879bd173502fe96e513d25 Mon Sep 17 00:00:00 2001 From: MS Date: Fri, 27 Oct 2023 12:46:33 +0200 Subject: adapt DD 50 to latest choice --- design-documents/050-libeufin-nexus.rst | 21 +-------------------- 1 file changed, 1 insertion(+), 20 deletions(-) (limited to 'design-documents') diff --git a/design-documents/050-libeufin-nexus.rst b/design-documents/050-libeufin-nexus.rst index a471007e..e9e3b49b 100644 --- a/design-documents/050-libeufin-nexus.rst +++ b/design-documents/050-libeufin-nexus.rst @@ -60,10 +60,9 @@ Configuration file USER_ID = myuser PARTNER_ID = myorg SYSTEM_ID = banksys - ACCOUNT_NUMBER = DE1234567890 # This value must identify with how the bank calls the bank account + ACCOUNT_NUMBER = payto://iban/BIC/IBAN?receiver-name=NexusUser # all fields mandatory BANK_PUBLIC_KEYS_FILE = enc-auth-keys.json CLIENT_PRIVATE_KEYS_FILE = my-private-keys.json - ACCOUNT_META_DATA_FILE = ebics-meta.json BANK_DIALECT = postfinance # EBICS+ISO20022 style used by the bank. [nexus-postgres] @@ -112,15 +111,6 @@ JSON with: * submitted_ini (boolean) * submitted_hia (boolean) -File contents: ACCOUNT_META_DATA_FILE -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -JSON with: - - * account_holder_iban - * bank_code - * account_holder_name - Database schema --------------- @@ -194,15 +184,6 @@ The ebics-setup tool performs the following: accept them (or auto-accept via --auto-accept-keys). If the user accepted the public key, update the flag to "accepted". - * If all of the above has happened and we have accepted public keys from the - bank, try to download the list of bank accounts associated with the - connection and check that the configured account number is among them. On - success, store the associated meta data in the account meta data file. On - failure, show an error message with the list of available accounts (also - show this list via --show-associated-accounts). If the configured account - number is available, show a brief "setup ready" message. - - nexus-ebics-fetch ----------------- -- cgit v1.2.3 From 3828df4d792d76ec8086874a90e3a76096e69cb8 Mon Sep 17 00:00:00 2001 From: MS Date: Sat, 28 Oct 2023 10:34:55 +0200 Subject: DD 50 ACCOUNT_NUMBER gone in favor of the account triple IBAN, BIC, NAME. --- design-documents/050-libeufin-nexus.rst | 18 +++--------------- 1 file changed, 3 insertions(+), 15 deletions(-) (limited to 'design-documents') diff --git a/design-documents/050-libeufin-nexus.rst b/design-documents/050-libeufin-nexus.rst index e9e3b49b..62d1602f 100644 --- a/design-documents/050-libeufin-nexus.rst +++ b/design-documents/050-libeufin-nexus.rst @@ -60,7 +60,9 @@ Configuration file USER_ID = myuser PARTNER_ID = myorg SYSTEM_ID = banksys - ACCOUNT_NUMBER = payto://iban/BIC/IBAN?receiver-name=NexusUser # all fields mandatory + IBAN = MY-IBAN + BIC = MY-BIC + NAME = MY NAME BANK_PUBLIC_KEYS_FILE = enc-auth-keys.json CLIENT_PRIVATE_KEYS_FILE = my-private-keys.json BANK_DIALECT = postfinance # EBICS+ISO20022 style used by the bank. @@ -296,17 +298,3 @@ Discussion / Q&A the bank response, may lead double-submission even if the HTTP talk ended well: it suffices to crash after having received a "200 OK" response but before setting the submitted flag to the database. - -* Given that PostFinance does not provide the IBAN & BIC pair - on HTD (or other "admin" message types), the client cannot - confirm the bank account metadata with the bank. As a result, - it can only rely on what the configuration has in the - ACCOUNT_NUMBER value. - - The current design however does NOT mandate any particular - format for such configuration value, and given that the debtor - BIC is mandatory in the pain.001 generation, ACCOUNT_NUMBER - should be a Payto address with BIC and account holder name. - - Possibly, it may even be renamed to better match its content, - for example to ACCOUNT_METADATA. -- cgit v1.2.3 From c7dffa32e3bbaeccde89149e9f06528bc0fcbc83 Mon Sep 17 00:00:00 2001 From: MS Date: Tue, 31 Oct 2023 14:04:00 +0100 Subject: Nexus submit. Updating the manpage and DD 50, after the implementation. --- design-documents/050-libeufin-nexus.rst | 12 ++++++++++++ manpages/libeufin-nexus.1.rst | 17 +++++++++++++++++ 2 files changed, 29 insertions(+) (limited to 'design-documents') diff --git a/design-documents/050-libeufin-nexus.rst b/design-documents/050-libeufin-nexus.rst index 62d1602f..1d563936 100644 --- a/design-documents/050-libeufin-nexus.rst +++ b/design-documents/050-libeufin-nexus.rst @@ -298,3 +298,15 @@ Discussion / Q&A the bank response, may lead double-submission even if the HTTP talk ended well: it suffices to crash after having received a "200 OK" response but before setting the submitted flag to the database. + +* the ebics-submit section mentions the EBICS order ID. The following excerpt + was found however at page 88 of the EBICS 3 specifications: + + ``OrderID is only present if a file is transmitted to the bank relating to an order with an + already existing order number (only allowed for AdminOrderType = HVE or HVS)`` + + Nexus does not support HVE or HVS. + +* As of private communication, the responsibility of submitting idempotent payments + relies on the use of ``request_uid`` (a database column of the initiated payment) + as the ``MsgId`` value of the corresponding pain.001 document. diff --git a/manpages/libeufin-nexus.1.rst b/manpages/libeufin-nexus.1.rst index 253f1b38..8fb41ed5 100644 --- a/manpages/libeufin-nexus.1.rst +++ b/manpages/libeufin-nexus.1.rst @@ -75,6 +75,23 @@ Its options are as follows: **-r** \| **--reset** If present, deletes any database table (WARNING: potential data loss) + +ebics-submit +------------ + +This subcommand submits any initiated payment, that was not already sent to the bank. In the current version, initiated payments may come either from a cash-out operation or from a bounced incoming payment. There is therefore **no** way to manually initiate a payment at this moment. This tool is Taler friendly, therefore bounced payments are those that do not contain a valid subject to start a Taler withdrawal. Cash-out operations come from a tightly integrated bank that offers their customers to convert their currency to the currency whose the EBICS subscriber bank account is tied to. + + +Its options are as follows: + +**-h** \| **--help** + Print short help on options. +**-c** \| **--config** \ ‌\ *FILENAME* + Specifies the configuration file. +**--transient** + This flag, enabled by default, causes the command to run only once without any long-polling behaviour. + The configuration value `FREQUENCY` gets therefore ignored. + Bugs ==== -- cgit v1.2.3 From 61043529ef53a90e7264a5d779467daa0a6417b6 Mon Sep 17 00:00:00 2001 From: MS Date: Tue, 31 Oct 2023 15:28:23 +0100 Subject: nexus manual --- design-documents/050-libeufin-nexus.rst | 1 - libeufin/index.rst | 2 +- libeufin/nexus-manual.rst | 93 ++++ libeufin/nexus-tutorial.rst | 956 -------------------------------- 4 files changed, 94 insertions(+), 958 deletions(-) create mode 100644 libeufin/nexus-manual.rst delete mode 100644 libeufin/nexus-tutorial.rst (limited to 'design-documents') diff --git a/design-documents/050-libeufin-nexus.rst b/design-documents/050-libeufin-nexus.rst index 1d563936..272e7a7b 100644 --- a/design-documents/050-libeufin-nexus.rst +++ b/design-documents/050-libeufin-nexus.rst @@ -59,7 +59,6 @@ Configuration file HOST_ID = mybank USER_ID = myuser PARTNER_ID = myorg - SYSTEM_ID = banksys IBAN = MY-IBAN BIC = MY-BIC NAME = MY NAME diff --git a/libeufin/index.rst b/libeufin/index.rst index 4ccbe1aa..2f1ef49c 100644 --- a/libeufin/index.rst +++ b/libeufin/index.rst @@ -12,7 +12,7 @@ LibEuFin is a project providing free software tooling for European FinTech. iso20022 banking-protocols frontend - nexus-tutorial + nexus-manual ebics3-test-tutorial performance transaction-identification diff --git a/libeufin/nexus-manual.rst b/libeufin/nexus-manual.rst new file mode 100644 index 00000000..1c8adf59 --- /dev/null +++ b/libeufin/nexus-manual.rst @@ -0,0 +1,93 @@ +.. target audience: operator, developer + +LibEuFin Manual +############### + +.. contents:: Table of Contents + +LibEuFin Nexus is an EBICS facilitator. It offers a command line +interface to setup EBICS access, download banking records, and submit payments. +Future versions will offer a Web API to allow Taler Exchanges to talk to their +banks. + +In this manual, we explain how to setup an EBICS subscriber. We assume that +the bank had already granted EBICS access to the subscriber. The installation +is described at `Installing Nexus`_. + +Setting up the EBICS subscriber +=============================== + +The following snippet shows the mandatory configuration values. + +.. code-block:: console + + [nexus-postgres] + CONFIG = postgres:///libeufincheck + + [nexus-ebics] + CURRENCY = EUR + HOST_BASE_URL = http://bank.example.com/ + HOST_ID = mybank + USER_ID = myuser + PARTNER_ID = myorg + IBAN = myiban + BIC = mybic + NAME = myname + BANK_PUBLIC_KEYS_FILE = enc-auth-keys.json + CLIENT_PRIVATE_KEYS_FILE = private-keys-again.json + BANK_DIALECT = postfinance + +Assuming that the configuration file exists at ``$config_file``, the following +command would start the EBICS setup process. The files CLIENT_PRIVATE_KEYS_FILE +and BANK_PUBLIC_KEYS_FILE would be created at the CWD. Adjust their path to your +setup ('$HOME' is currently not supported along paths). + +.. code-block:: console + + libeufin-nexus ebics-setup -c $config_file + +If the previous command succeeded, the subscriber keys reached the bank, but the setup +**should** fail with an ``EBICS_AUTHENTICATION_FAILED`` error code. That happens because +the client tries to download the bank keys *before* having confirmed the subscriber keys +via the traditional post service. + +To that purpose, the previous run should have left a PDF document that the subscriber can +print, sign, and send to the bank to confirm their subscriber keys. Look for the message +looking like ``PDF file with keys hex encoding created at: /tmp/libeufin-nexus-keys-$timestamp.pdf``. + +Once the bank received and approved such printed document, run the same command again, in +order to download the bank keys and let the user accept them. + +.. code-block:: console + + libeufin-nexus ebics-setup -c $config_file + +The setup is considered finished once both party have accepted the counterpart keys. + +Installing Nexus +================ + +The following section was tested on an *OpenJDK 17* environment. + +Building from source +-------------------- + +Nexus belongs to the LibEuFin project, and can be downloaded via Git: + +.. code-block:: console + + $ git clone git://git.taler.net/libeufin + +Note that Kotlin and Gradle should already work on the host system. + +Navigate into the *libeufin* local repository, and from top-level run: + +.. code-block:: console + + $ ./bootstrap + $ ./configure --prefix=$PREFIX + $ make install-nexus + +If the previous steps succeeded, the ``libeufin-nexus`` command should +be found in the $PATH. + diff --git a/libeufin/nexus-tutorial.rst b/libeufin/nexus-tutorial.rst deleted file mode 100644 index aeea4667..00000000 --- a/libeufin/nexus-tutorial.rst +++ /dev/null @@ -1,956 +0,0 @@ -.. target audience: operator, developer - -LibEuFin How-To -############### - -.. contents:: Table of Contents - -The LibEuFin Nexus is a Web service that provides a JSON abstraction layer to -access bank accounts. It does **not** itself offer banking services, but is a -translator between JSON requests and other banking protocols (such as EBICS), -that are offered by banks. - -This document explains how to set up Nexus to access a bank account -via the EBICS protocol. - -In order to follow all the steps below, the reader should either -have access to a bank account with EBICS support or follow the -steps in :ref:`Configuring the Sandbox `. - - -Installing LibEuFin -=================== - -Installation on Debian ----------------------- - -.. include:: ../frags/installing-debian.rst - -To install LibEuFin, you can now simply run: - -.. code-block:: console - - # apt install libeufin-nexus libeufin-sandbox - -Administration via SystemD --------------------------- - -After the Debian installation, the installed unit files -should be listed by the following command: - -.. code-block:: console - - # systemctl list-unit-files | egrep '(nexus|sandbox)' - -Both ``nexus.service`` and ``sandbox.service`` should appear. - -At this point, the services can be started on boot: - -.. code-block:: console - - # systemctl enable libeufin-nexus # use 'disable' to rollback - # systemctl enable libeufin-sandbox # only if you want the sandbox - -Or just manually: - -.. code-block:: console - - # systemctl start libeufin-nexus # use 'stop' to terminate. - # systemctl start libeufin-sandbox # only if you want the sandbox - -The following command should inform the user about the status -of the running / terminated service: - -.. code-block:: console - - # systemctl status libeufin-nexus - -For more diagnostics, use: - -.. code-block:: console - - # journalctl -u libeufin-nexus - -Run-time dependencies ---------------------- - -LibEuFin has the following run-time dependencies: - -* OpenJDK 11 -* Python 3.8 -* python3-click (can be installed via ``pip3 install click``) -* python3-requests (can be installed via ``pip3 install requests``) - -These dependencies only need to be installed manually when building from source -or using the prebuilt binaries. - -Downloading prebuilt binaries ------------------------------ - -Pre-built packages can be obtained from the `taler.net website -`__. - -Unpack the ``libeufin-$version.zip`` file to -your desired location (typically ``/opt`` or ``~/opt``) and make sure that your ``PATH`` -environment variable contains the ``bin/`` directory of the unpacked archive. - - -.. _building-from-source: - -Building from source --------------------- - -Nexus belongs to the LibEuFin project, and can be downloaded via Git: - -.. code-block:: console - - $ git clone git://git.taler.net/libeufin - -It is recommended to run the ``v0.9.1`` version, hence -the following command may now be given. - -.. code-block:: console - - $ git checkout v0.9.1 - -Note that Kotlin and Gradle should already work on the host system. - -Navigate into the *libeufin* local repository, and from top-level run: - -.. code-block:: console - - $ ./bootstrap - $ ./configure --prefix=$PREFIX - $ make install # Note: This may require Java=18; Java=17 had errors, Java>=19 is unsupported by Gradle - -Verifying your installation ---------------------------- - -In case of success, the three following commands should be found: - -.. code-block:: console - - $ which libeufin-nexus - $ which libeufin-sandbox - $ which libeufin-cli - - -.. _configuring-the-sandbox: - -Configuring the Sandbox (Optional) -================================== - -If you don't have access to a real bank account with an EBICS API, you can set -up the sandbox. The sandbox is a simplistic and incomplete implementation of a -core banking system with EBICS access to bank accounts. - -The sandbox uses HTTP Basic auth, with username ``admin``. -Choose a password and set env var ``LIBEUFIN_SANDBOX_ADMIN_PASSWORD`` to it. - -The sandbox relies on a database, which you must specify using a Postgres -connection URI with the ``LIBEUFIN_SANDBOX_DB_CONNECTION`` environment -variable, before invoking any commands. -If this variable is not set, ``libeufin-sandbox`` complains and exits: - -.. code-block:: console - - $ export LIBEUFIN_SANDBOX_ADMIN_PASSWORD=secret - $ libeufin-sandbox serve - DB connection string not found in the env variable LIBEUFIN_SANDBOX_DB_CONNECTION. - The following two examples are valid connection strings: - postgresql://localhost:5432/libeufindb?user=Foo&password=secret - postgres:///libeufindb - -Before being usable, a Sandbox needs to be configured. This is done -by creating the ``default`` demobank. A demobank is a set of configuration -values associated to one name; in the example below, we'll create one -named ``default``, that is mandatory to have. - -.. note:: - - By design, many demobanks can be hosted by one running Sandbox, - although at the time of writing only the ``default`` one is supported. - -A default demobank having the EUR currency is created with the following command: - -.. code-block:: console - - $ export LIBEUFIN_SANDBOX_DB_CONNECTION=postgres:///libeufintestdb - $ libeufin-sandbox config --currency EUR default - -In order to use Taler, a default exchange needs to be configured. - -.. code-block:: console - - $ export LIBEUFIN_SANDBOX_DB_CONNECTION=postgres:///libeufintestdb - $ libeufin-sandbox default-exchange --demobank default $exchange_base_url $exchange_payto_address - -The sandbox service can now be started with the following command: - -.. code-block:: console - - $ export LIBEUFIN_SANDBOX_ADMIN_PASSWORD=secret - $ export LIBEUFIN_SANDBOX_DB_CONNECTION=postgres:///libeufintestdb - $ libeufin-sandbox serve --port 5016 - -The instructions below hook Nginx to the Sandbox: - -.. code-block:: nginx - - redirect / to /demobanks/default; - rewrite ^/$ https://$host/demobanks/default; - location / { - proxy_set_header Host $host; - proxy_set_header X-Forwarded-Host $host; - proxy_set_header X-Forwarded-Proto "https"; - proxy_set_header X-Forwarded-Prefix "/"; - proxy_pass http://localhost:5016/; - } - -To reset the state of the sandbox, delete the database. - -For invocations of the LibEuFin command-line interface tool (``libeufin-cli``), -the following environment variables must be set to the authentication -information, and the URL of the sandbox service: - -.. code-block:: console - - $ export LIBEUFIN_SANDBOX_USERNAME=admin - $ export LIBEUFIN_SANDBOX_PASSWORD=secret - $ export LIBEUFIN_SANDBOX_URL=http://localhost:5016 - -Note that the password is the same as for ``LIBEUFIN_SANDBOX_ADMIN_PASSWORD``. -Verify that the sandbox is running: - -.. code-block:: console - - $ libeufin-cli sandbox check - Hello, this is the Sandbox - -Now an EBICS host can be created: - -.. code-block:: console - - $ libeufin-cli sandbox ebicshost create --host-id testhost - $ libeufin-cli sandbox ebicshost list - { - "ebicsHosts" : [ "testhost" ] - } - -Note that most ``libeufin-cli`` subcommands will ask for input interactively if -the respective value is not specified on the command line. - -Next, register a user. For the ``libeufin-cli sandbox demobank register`` -command, the ``LIBEUFIN_SANDBOX_USERNAME`` and ``LIBEUFIN_SANDBOX_PASSWORD`` -are assumed to be ``jrluser`` and ``easy``, respectively. - -.. note:: - - All the following commands address the ``default`` demobank, see ``libeufin-cli sandbox demobank --help``. - -.. code-block:: console - - $ export LIBEUFIN_SANDBOX_USERNAME=jrluser - $ export LIBEUFIN_SANDBOX_PASSWORD=easy - $ libeufin-cli sandbox demobank register - -Check the balance of the user just created: - -.. code-block:: console - - $ libeufin-cli sandbox \ - demobank info --bank-account jrluser - -With a user registered, we can now create an EBICS subscriber (identified by -the partner ID and user ID) for the host. This command requires admin -privileges, so ``LIBEUFIN_SANDBOX_USERNAME`` and ``LIBEUFIN_SANDBOX_PASSWORD`` -are reset back to ``admin`` and ``secret``, respectively. - -.. The plan is to replace the ‘sandbox ebicssubscriber list’ command - below with a ‘sandbox demobank show-ebicssubscriber’ command. - Need to implement it first! - -.. code-block:: console - - $ export LIBEUFIN_SANDBOX_USERNAME=admin - $ export LIBEUFIN_SANDBOX_PASSWORD=secret - $ libeufin-cli sandbox \ - demobank new-ebicssubscriber \ - --host-id testhost \ - --partner-id partner01 \ - --user-id user02 \ - --bank-account jrluser - $ libeufin-cli sandbox ebicssubscriber list - { - "subscribers" : [ { - "host_id" : "testhost", - "partner_id" : "partner01", - "user_id" : "user02", - "system_id" : null, - "demobank_account_label" : "jrluser" - } ] - } - -The ``libeufin-cli sandbox demobank new-ebicssubscriber`` command -also creates an associated bank account. You can see it with command: - -.. code-block:: console - - $ libeufin-cli sandbox bankaccount list - [ { - "label" : "bank", - "name" : "Bank account owner's name", - "iban" : "DE895351", - "bic" : "SANDBOXX" - }, { - "label" : "jrluser", - "name" : "Bank account owner's name", - "iban" : "DE724881", - "bic" : "SANDBOXX" - } ] - -The account name ``jrluser`` is the unique identifier of the account within -the sandbox. The EBICS parameters identify the subscriber that should have -access to the bank account via EBICS. - -The account already has one transaction, the "Sign-up bonus" from the bank. -Note that in the following examples we transition to using the ``bankaccount`` -subcommand, because there is no need to rely on EBICS: - -.. code-block:: console - - $ libeufin-cli sandbox bankaccount transactions jrluser - { - "payments" : [ { - "account_label" : "jrluser", - "creditor_iban" : "DE724881", - "creditor_bic" : "SANDBOXX", - "creditor_name" : "Unknown", - "debtor_iban" : "DE895351", - "debtor_bic" : "SANDBOXX", - "debtor_name" : "The Bank", - "amount" : "100", - "currency" : "EUR", - "subject" : "Sign-up bonus", - "date" : "Tue, 22 Feb 2022 00:04:15 GMT", - "credit_debit_indicator" : "credit", - "account_servicer_reference" : "2NG75I0O", - "payment_information_id" : null - } ] - } - -To populate the account with some more transactions, run the following command: - -.. code-block:: console - - $ libeufin-cli sandbox bankaccount generate-transactions jrluser - -.. code-block:: console - - $ libeufin-cli sandbox bankaccount simulate-incoming-transaction jrluser \ - --debtor-iban DE06500105174526623718 \ - --debtor-bic INGDDEFFXXX \ - --debtor-name "Joe Foo" \ - --subject "Hello World" \ - --amount 10.50 - -Now the list of transactions has grown by several entries: - -.. code-block:: console - - $ libeufin-cli sandbox bankaccount transactions jrluser - { - "payments" : [ { - "account_label" : "jrluser", - "creditor_iban" : "DE724881", - "creditor_bic" : "SANDBOXX", - "creditor_name" : "Unknown", - "debtor_iban" : "DE895351", - "debtor_bic" : "SANDBOXX", - "debtor_name" : "The Bank", - "amount" : "100", - "currency" : "EUR", - "subject" : "Sign-up bonus", - "date" : "Tue, 22 Feb 2022 00:04:15 GMT", - "credit_debit_indicator" : "credit", - "account_servicer_reference" : "2NG75I0O", - "payment_information_id" : null - }, { - "account_label" : "jrluser", - "creditor_iban" : "DE724881", - "creditor_bic" : "SANDBOXX", - "creditor_name" : "Creditor Name", - "debtor_iban" : "DE64500105178797276788", - "debtor_bic" : "DEUTDEBB101", - "debtor_name" : "Max Mustermann", - "amount" : "22", - "currency" : "EUR", - "subject" : "sample transaction GSF7S5LC", - "date" : "Tue, 22 Feb 2022 01:26:18 GMT", - "credit_debit_indicator" : "credit", - "account_servicer_reference" : "GSF7S5LC", - "payment_information_id" : null - }, { - "account_label" : "jrluser", - "creditor_iban" : "DE64500105178797276788", - "creditor_bic" : "DEUTDEBB101", - "creditor_name" : "Max Mustermann", - "debtor_iban" : "DE724881", - "debtor_bic" : "SANDBOXX", - "debtor_name" : "Debitor Name", - "amount" : "10", - "currency" : "EUR", - "subject" : "sample transaction 1WUP303Q", - "date" : "Tue, 22 Feb 2022 01:26:18 GMT", - "credit_debit_indicator" : "debit", - "account_servicer_reference" : "1WUP303Q", - "payment_information_id" : null - }, { - "account_label" : "jrluser", - "creditor_iban" : "DE724881", - "creditor_bic" : "SANDBOXX", - "creditor_name" : "Creditor Name", - "debtor_iban" : "DE06500105174526623718", - "debtor_bic" : "INGDDEFFXXX", - "debtor_name" : "Joe Foo", - "amount" : "10.50", - "currency" : "EUR", - "subject" : "Hello World", - "date" : "Tue, 22 Feb 2022 01:26:41 GMT", - "credit_debit_indicator" : "credit", - "account_servicer_reference" : "sandbox-ALQP8TXKJWRVKMAH", - "payment_information_id" : null - } ] - } - -.. note:: - - The sandbox is intended as a testing tool and thus not stable. - -.. _disable-registrations: - -Disable registrations (experimental) ------------------------------------- - -Demobanks can disable/enable registrations for new users. -The responsible options are -``--with-registrations`` / ``--without-registrations``. - -For more information on the available commands, use the built-in ``--help`` flag. -The full functionality of the sandbox is available via -the :ref:`Core Bank API `. - -Connect Nexus with the bank. -============================ - -Nexus relies on a database, which you must specify using a Postgres -connection URI with the ``LIBEUFIN_NEXUS_DB_CONNECTION`` environment -variable, before invoking any commands. -(If this variable is not set, ``libeufin-nexus`` complains and exits.) - -Use the following command to run the Nexus service: - - Neuxs defaults to *not* storing the messages that it downloads - from the bank. To revert this behaviour, export also the environment - variable ``LIBEUFIN_NEXUS_KEEP_BANK_MESSAGES`` to ``yes`` before - running the following command. - -.. code-block:: console - - $ export LIBEUFIN_NEXUS_DB_CONNECTION=postgresql://localhost:5433/libeufindb?user=foo&password=secret - $ libeufin-nexus serve --port 5017 - -This assumes that the PostgreSQL service with a database -called ``libeufindb`` listens on port 5433 -for requests from the Nexus service. -The Nexus service itself listens on port 5017. -Note that you must have the ``LIBEUFIN_NEXUS_DB_CONNECTION`` -environment variable set for most uses of the libeufin-nexus -command. - -At this point a superuser account needs to be created: - -.. code-block:: console - - $ libeufin-nexus superuser foo --password secret - -If you omit ``--password secret``, 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. - -.. note:: - - User and permissions management in LibEuFin is still under development. - In particular, permissions for non-superusers are very limited at the moment. - -The command line interface needs the following three values -to be defined in the environment: ``LIBEUFIN_NEXUS_URL``, ``LIBEUFIN_NEXUS_USERNAME``, -and ``LIBEUFIN_NEXUS_PASSWORD``. In this example, ``LIBEUFIN_NEXUS_USERNAME`` should be -set to ``foo``, and ``LIBEUFIN_NEXUS_PASSWORD`` to the value given for its password -in the previous step (with the ``libeufin-nexus superuser`` command). The -``LIBEUFIN_NEXUS_URL`` could be given as ``http://localhost:5017``. - -Nexus speaks two protocols to reach the bank: EBICS and x-libeufin-bank. -In Nexus speech, each protocol is also known as a *bank connection*. -The following two sections show how to setup such bank connections. Note: -only one is needed to operate! - -EBICS ------ - -.. note:: - - For the sandbox setup in this guide, the ``EBICS_BASE_URL`` - should be ``http://localhost:5016/ebicsweb``. - This is the value of environment variable - ``LIBEUFIN_SANDBOX_URL`` suffixed with ``/ebicsweb``, - since the sandbox will be providing EBICS services. - - Similarly, ``EBICS_HOST_ID`` should be ``testhost``, - and ``EBICS_PARTNER_ID`` should be ``partner01``. - For ``EBICS_USER_ID`` we will use ``user02`` (for account ``jrluser``), - and for ``CONNECTION_NAME``, we will use ``conn01``. - -.. code-block:: console - - $ 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 - -If this step executes correctly -(use ``libeufin-cli connections list-connections`` -and ``libeufin-cli connections show-connection`` to check), -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. - -.. code-block:: console - - $ libeufin-cli \ - connections \ - export-backup \ - --passphrase $SECRET \ - --output-file $BACKUP_FILE \ - $CONNECTION_NAME - -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: - -.. code-block:: console - - $ libeufin-cli connections get-key-letter $CONNECTION_NAME out.pdf - -.. note:: - - When using the LibEuFin sandbox, subscribers are automatically - activated after keys are received electronically. - -.. code-block:: console - - $ libeufin-cli \ - connections \ - connect \ - $CONNECTION_NAME - -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 ``$CONNECTION_NAME``. - -.. code-block:: console - - $ libeufin-cli \ - connections \ - download-bank-accounts \ - $CONNECTION_NAME - -It is now possible to list the accounts offered by the connection. - -.. _list-connections: - -.. code-block:: console - - $ libeufin-cli \ - connections \ - list-offered-bank-accounts \ - $CONNECTION_NAME - -.. note:: - - The ``nexusBankAccountId`` field should at this step be ``null``, - as we have not yet imported the bank account and thus the account - does not yet have a local name. - -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. - -.. code-block:: console - - $ libeufin-cli \ - connections \ - import-bank-account \ - --offered-account-id testacct01 \ - --nexus-bank-account-id $LOCAL_ACCOUNT_NAME \ - $CONNECTION_NAME - -Once a Nexus user imported a bank account (``$LOCAL_ACCOUNT_NAME``) -under a certain connection (``$CONNECTION_NAME``), it is possible -to accomplish the usual operations for any bank account: asking for the -list of transactions, and making a payment. - -The last step is to create background tasks that fetch and submit -the information from and to the bank. The following command submits -the prepared payments to the bank each second. - -.. _submit-task: - -.. code-block:: console - - $ libeufin-cli accounts task-schedule $LOCAL_ACCOUNT_NAME \ - --task-type submit \ - --task-name submit-payments-each-second \ - --task-cronspec "* * *" - -The following step downloads from the bank all the new transactions, -each second. The ``report`` value indicates that Nexus is interested -in the transactions which did reach already the booked state, in order -to provide faster times to its users. - -.. code-block:: console - - $ libeufin-cli accounts task-schedule $LOCAL_ACCOUNT_NAME \ - --task-type fetch \ - --task-name fetch-reports-each-second \ - --task-cronspec "* * *" \ - --task-param-level report \ - --task-param-range-type latest - -For example, the cronspec can be changed to every five seconds by the -following value: ``"*/5 * *"`` (remember to quote, to protect from shell -filename expansion). - -x-libeufin-bank ---------------- - -This is a faster bank connection, because it relies on JSON and HTTP basic -auth, as oppsed to EBICS XML and RSA cryptography. It is also planned to equip -the server side with long-polling, in order to loop more slowly when asking -for new data. - -The first step is to create one x-libeufin-bank connection. Make sure that -the usual env variables LIBEUFIN_NEXUS_USERNAME, LIBEUFIN_NEXUS_PASSWORD, and -LIBEUFIN_NEXUS_URL are set. The following command instructs Nexus about -the bank URL and the credentials it needs - -.. code-block:: console - - libeufin-cli connections new-xlibeufinbank-connection \ - --bank-url "http://localhost:5016/demobanks/default/access-api" \ - --username jrluser \ - --password easy \ - $CONNECTION_NAME - -The ``--password`` option can be omitted, and in this case the CLI will -prompt to collect it. - - The credentials are exactly the same as the ones used to register a - new bank account at Sandbox. - -Once the connection is created, we need -- just as in the EBICS case -- -the "connect" step. In this case, the connect step will check if the -credentials and URL are correct and (as a side effect) download basic -information about the bank account. - -.. code-block:: console - - libeufin-cli connections connect $CONNECTION_NAME - -As a proof, you can `list `_ which bank account -arrived at Nexus after the connect command succeeds. Now the bank -account can be imported under a local name at Nexus, just as it was -in the EBICS case. - -.. note:: - - One main difference with EBICS is that now we don't need the - ``download-bank-accounts`` step, because ``connect`` carried - it out as a side effect of checking the credentials. - - -.. code-block:: console - - libeufin-cli connections import-bank-account \ - --offered-account-id jrluser \ - --nexus-bank-account-id $LOCAL_ACCOUNT_NAME \ - $CONNECTION_NAME - - -Now that the account is imported, the background tasks need to -be setup, to provide always the most updated information from the -bank. - -The submit task can be `the same `_ as EBICS. The fetch -task however needs one different setting, and namely it has to require -``statement`` instead of 'report' because x-libeufin-bank has only the -booked state for transactions. The time range is also different, because -x-libeufin-bank does NOT offer ``latest``. Any unsupported setting should -however generate one error and therefore not create wrong background tasks. - -.. code-block:: console - - libeufin-cli accounts task-schedule \ - --task-type fetch \ - --task-name fetch-every-second \ - --task-cronspec "* * *" \ - --task-param-level statement \ - --task-param-range-type since-last \ - $LOCAL_ACCOUNT_NAME - -Request history of transactions -=============================== - -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: - -.. code-block:: console - - $ libeufin-cli accounts fetch-transactions $LOCAL_ACCOUNT_NAME - -.. 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). - -Once Nexus has stored all the information in the database, the -client can ask to actually see the transactions: - -.. code-block:: console - - $ libeufin-cli accounts transactions $LOCAL_ACCOUNT_NAME - -Make a payment -============== - -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: - -.. code-block:: console - - $ 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 - -Note: the ``$AMOUNT`` value needs the format ``CURRENCY:X.Y``; for example -``EUR:10``, or ``EUR:1.01``. - -The previous command should return a value (``$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**: - -.. code-block:: console - - $ libeufin-cli accounts submit-payments \ - --payment-uuid $UUID \ - $LOCAL_ACCOUNT_NAME - -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 : - -.. code-block:: console - - $ libeufin-cli accounts task-schedule myacct \ - --task-type="submit" \ - --task-name='submit-payments-hourly' \ - --task-cronspec='0 0 *' - - $ libeufin-cli accounts task-schedule myacct \ - --task-type="fetch" \ - --task-name='fetch-5min' \ - --task-cronspec='0 */5 *' \ - --task-param-level=report \ - --task-param-range-type=latest - - $ libeufin-cli accounts task-schedule myacct \ - --task-type="fetch" \ - --task-name='fetch-daily' \ - --task-cronspec='0 0 23' \ - --task-param-level=statement \ - --task-param-range-type=latest - -The cronspec has the following format, which is slightly non-standard due to -the ``SECONDS`` field - -.. code-block:: none - - SECONDS MINUTES HOURS DAY-OF-MONTH[optional] MONTH[optional] DAY-OF-WEEK[optional] - - -Restore the backup -================== - -The following command restores all the details associated with -one bank connection subscription. For EBICS, this means that the -INI and HIA secret keys will be restored for the requesting user. - -.. code-block:: console - - $ libeufin-cli connections \ - restore-backup \ - --passphrase=$SECRET \ - --backup-file=$BACKUP_FILE \ - $CONNECTION_NAME - -.. - FIXME: - On a bad password given, Nexus responds - "bad backup given" instead of "authentication failed". - - -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 ``$FACADE_NAME`` below: - -.. code-block:: console - - $ libeufin-cli facades new-taler-wire-gateway-facade \ - --currency EUR \ - --facade-name $FACADE_NAME \ - $CONNECTION_NAME \ - $LOCAL_ACCOUNT_NAME - -At this point, the additional *taler-wire-gateway* (FIXME: link -here to API here) 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 located when listing the facades: - -.. code-block:: console - - $ libeufin-cli facades list - -Creating a Anastasis facade -=========================== - -The following command creates a Anastasis facade. At this point, *only* -the superuser is able to create facades; please set the environment variables -``LIBEUFIN_NEXUS_USERNAME`` and ``LIBEUFIN_NEXUS_PASSWORD`` accordingly. - -.. code-block:: console - - $ libeufin-cli facades new-anastasis-facade \ - --currency EUR \ - --facade-name $FACADE_NAME \ - $CONNECTION_NAME \ - $LOCAL_ACCOUNT_NAME - -If the previous command succeeded, it is possible to see the -facade's base URL with: - -.. code-block:: console - - $ libeufin-cli facades list - -At this point, to allow a non superuser to use the facade, a history -permission needs to be set: - -.. code-block:: console - - $ libeufin-cli permissions grant \ - user $USERNAME \ - facade $FACADENAME \ - facade.anastasis.history - -.. note:: - - There is no need to set/unset a transfer permission on the facade - since this one does not offer any endpoint to issue wire transfers. - -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 ``users`` subcommand of the CLI: - -.. code-block:: console - - $ libeufin-cli users list - # [ ... shows available users ... ] - - $ libeufin-cli users create $USERNAME - # [ ... will prompt for password ... ] - -Permissions are managed with the ``permissions`` subcommand. -The following commands grant permissions to view the transaction history -and create payment initiations with a Taler wire gateway facade: - - -.. code-block:: console - - $ libeufin-cli permissions grant \ - user $USERNAME \ - facade $FACADENAME \ - facade.talerWireGateway.history - - $ libeufin-cli permissions grant \ - user $USERNAME \ - facade $FACADENAME \ - facade.talerWireGateway.transfer - -The list of all granted permissions can be reviewed: - -.. code-block:: console - - $ libeufin-cli permissions list -- cgit v1.2.3 From 8f7bf709b7ad5263096749a5620bf4eec5639d64 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Wed, 1 Nov 2023 11:37:08 +0100 Subject: -document new -k option --- core/api-exchange.rst | 2 +- core/api-merchant.rst | 4 ++-- design-documents/051-fractional-digits.rst | 10 +++------- manpages/taler-unified-setup.1.rst | 6 +++++- taler-developer-manual.rst | 9 +++++++-- taler-user-guide.rst | 2 +- 6 files changed, 19 insertions(+), 14 deletions(-) (limited to 'design-documents') diff --git a/core/api-exchange.rst b/core/api-exchange.rst index 3992b7e2..08599471 100644 --- a/core/api-exchange.rst +++ b/core/api-exchange.rst @@ -1825,7 +1825,7 @@ Batch Withdraw } - .. ts:def:: WithdrawResponse + .. ts:def:: WithdrawResponse interface WithdrawResponse { // The blinded signature over the 'coin_ev', affirms the coin's diff --git a/core/api-merchant.rst b/core/api-merchant.rst index 142e83f8..b6bdb0dd 100644 --- a/core/api-merchant.rst +++ b/core/api-merchant.rst @@ -318,7 +318,7 @@ Making the payment // Custom inputs from the wallet for the contract. wallet_data?: Object; - + // The session for which the payment is made (or replayed). // Only set for session-based payments. session_id?: string; @@ -3311,7 +3311,7 @@ Adding templates // The user may specify any amount, but it must be // in this currency. // This parameter is optional and should not be present - // if "amount" is given. + // if "amount" is given. currency?: string; // The price is imposed by the merchant and cannot be changed by the customer. diff --git a/design-documents/051-fractional-digits.rst b/design-documents/051-fractional-digits.rst index acd19f14..4321fd53 100644 --- a/design-documents/051-fractional-digits.rst +++ b/design-documents/051-fractional-digits.rst @@ -23,15 +23,11 @@ There was already a specification for ScopedCurrencyInfo - which got renamed to We need three core characteristics for fractional digits for each currency: -e) the number of fractional digits e in [0..8] the user may 'e'nter in a TextInputField + e) the number of fractional digits e in [0..8] the user may 'e'nter in a TextInputField -n) the number of fractional digits n in [0..8] to be rendered as 'n'ormal characters (same font and size as the integer digits). - All additional fractional digits will be rendered as SuperScriptDigits as known from gas filling stations. - The UI should never round or truncate any amount, but always render all existing digits (except trailing zeroes, see c). + n) the number of fractional digits n in [0..8] to be rendered as 'n'ormal characters (same font and size as the integer digits). All additional fractional digits will be rendered as SuperScriptDigits as known from gas filling stations. The UI should never round or truncate any amount, but always render all existing digits (except trailing zeroes, see c). -z) the number of fractional digits z in [0..8] to be rendered as trailing 'z'eroes (including SuperScript digits). - E.g. if z = 2 (and n = 2), then render $5 as `$ 5.00´. - If z = 3 (and n = 2), then render $5 as `$ 5.00⁰´ with two normal trailing zeroes and one superscript trailing zero. + z) the number of fractional digits z in [0..8] to be rendered as trailing 'z'eroes (including SuperScript digits). E.g. if z = 2 (and n = 2), then render $5 as ``$ 5.00``. If z = 3 (and n = 2), then render $5 as ``$ 5.00⁰`` with two normal trailing zeroes and one superscript trailing zero. The values e, n, and z are independent from each other. Each could be any value from 0 to 8. However, when a user enters an amount, s/he should be able to input diff --git a/manpages/taler-unified-setup.1.rst b/manpages/taler-unified-setup.1.rst index 02d09879..fe60d1e5 100644 --- a/manpages/taler-unified-setup.1.rst +++ b/manpages/taler-unified-setup.1.rst @@ -21,6 +21,7 @@ Synopsis [**-e**] [**-f**] [**-h**] +[**-k**] [**-l** *FILENAME*] [**-m**] [**-n**] @@ -64,6 +65,9 @@ systemd and not via this tool. **-h** \| **--help** Prints a compiled-in help text. +**-k** + Start challenger (KYC service) + **-L** *LOGLEVEL* Specifies the log level to use. Accepted values are: ``DEBUG``, ``INFO``, ``WARNING``, ``ERROR``. @@ -97,7 +101,7 @@ See Also ======== taler-exchange-dbinit(1), taler-exchange-offline(1), taler-merchant-benchmark(1), -taler-exchange-httpd(1), taler-unified-setup(1), taler.conf(5) +taler-exchange-httpd(1), taler.conf(5) Bugs ==== diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst index a5a73ba9..ecee786f 100644 --- a/taler-developer-manual.rst +++ b/taler-developer-manual.rst @@ -909,8 +909,13 @@ Taler.xcworkspace expects the QuickJS framework sub-project to be at ``../quickjs-tart/QuickJS-rt.xcodeproj``. Build wallet-core first: - cd ~/Developer/GNU_Taler/wallet-core - date; time make embedded; open packages/taler-wallet-embedded/dist + +.. code-block:: shell-session + + $ cd wallet-core + $ make embedded + $ open packages/taler-wallet-embedded/dist + then drag or move its product "taler-wallet-core-qjs.mjs" into your quickjs-tart folder right at the top level. diff --git a/taler-user-guide.rst b/taler-user-guide.rst index 39bbf69c..a88faae3 100644 --- a/taler-user-guide.rst +++ b/taler-user-guide.rst @@ -294,7 +294,7 @@ you can specify which URL, which HTTP headers, which HTTP method and what HTTP body to send to the Webhook. Webhooks are automatically retried (with increasing delays) when the target server returns a temporary error. -`Mustach templates __` are used +`Mustach templates `__ are used when defining the contents of Webhooks. Depending on the triggering event, the templates will be expanded with event-specific data. -- cgit v1.2.3 From 4d4e4ceb1624e74b68e06e0a9cf4695c9018dfc3 Mon Sep 17 00:00:00 2001 From: MS Date: Thu, 2 Nov 2023 10:30:05 +0100 Subject: notes to DD50 about fetching payments --- design-documents/050-libeufin-nexus.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'design-documents') diff --git a/design-documents/050-libeufin-nexus.rst b/design-documents/050-libeufin-nexus.rst index 272e7a7b..82982dc3 100644 --- a/design-documents/050-libeufin-nexus.rst +++ b/design-documents/050-libeufin-nexus.rst @@ -196,6 +196,23 @@ nexus-ebics-fetch over (before committing any transactions with the next day!) also fetches a final statement of the previous day, thus ensuring we get a statement every day plus intra-day reports. + + .. note:: + + (1) "from that day forward (inclusive)" must **not** rely on EBICS returning + the unseen messages: that's because they might **already** be downloaded but + never made it to the database. + + (2) "and when the day rolls over". When does a day roll over? => A day rolls + over when the current time is at least on the day after the transaction with the + most recent timestamp that's stored in the database. + + (3) "Afterwards, fetches reports". This must happen **only after** any possible + previous statement got downloaded. + + To summarize: at any point in time the database must contain (the content of) any + possible statement up to the current time, plus any possible report up to the current + time (in case that's not covered by any statement so far). * Bounces transactions with mal-formed wire transfer subjects. -- cgit v1.2.3 From 6c0d79ea6d4907f4bd6d52cdce315a8ee1f10592 Mon Sep 17 00:00:00 2001 From: MS Date: Fri, 3 Nov 2023 09:07:57 +0100 Subject: DD 50: new payment submission states. --- design-documents/050-libeufin-nexus.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'design-documents') diff --git a/design-documents/050-libeufin-nexus.rst b/design-documents/050-libeufin-nexus.rst index 82982dc3..bc459e17 100644 --- a/design-documents/050-libeufin-nexus.rst +++ b/design-documents/050-libeufin-nexus.rst @@ -326,3 +326,20 @@ Discussion / Q&A * As of private communication, the responsibility of submitting idempotent payments relies on the use of ``request_uid`` (a database column of the initiated payment) as the ``MsgId`` value of the corresponding pain.001 document. + +* ``submitted`` column of an initiated payment evolved into the following enum: + + .. code-block:: shell-session + + CREATE TYPE submission_state AS ENUM ( + 'unsubmitted' + ,'transient_failure' + ,'permanent_failure' + ,'success' + ,'never_heard_back' + ); + + * ``unsubmitted``: default state when a payment is initiated + * ``transient_failure``: submission failed but can be retried, for example after a network issue. + * ``permanent_failure``: EBICS- or bank-technical error codes were not EBICS_OK (nor any tolerated EBICS code like EBICS_NO_DOWNLOAD_DATA_AVAILABLE), never retry. + * ``never_heard_back``: the payment initiation submission has **been** ``success`` but it was never confirmed by any outgoing transaction (from a camt.5x document) or any pain.002 report. It is responsability of a garbage collector to set this state after a particular time period. -- cgit v1.2.3 From abd7c855b98f0fefc62acb9a47a0ea965c3afd1c Mon Sep 17 00:00:00 2001 From: MS Date: Fri, 3 Nov 2023 09:32:41 +0100 Subject: DD 50, extending the payment initiations table. --- design-documents/050-libeufin-nexus.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'design-documents') diff --git a/design-documents/050-libeufin-nexus.rst b/design-documents/050-libeufin-nexus.rst index bc459e17..6049bda6 100644 --- a/design-documents/050-libeufin-nexus.rst +++ b/design-documents/050-libeufin-nexus.rst @@ -343,3 +343,12 @@ Discussion / Q&A * ``transient_failure``: submission failed but can be retried, for example after a network issue. * ``permanent_failure``: EBICS- or bank-technical error codes were not EBICS_OK (nor any tolerated EBICS code like EBICS_NO_DOWNLOAD_DATA_AVAILABLE), never retry. * ``never_heard_back``: the payment initiation submission has **been** ``success`` but it was never confirmed by any outgoing transaction (from a camt.5x document) or any pain.002 report. It is responsability of a garbage collector to set this state after a particular time period. + +* the initiated_outgoing_transactions table takes two more columns: + ``last_submission_date``, a timestamp in microseconds, and a + ``submission_counter``. Both of them would serve to decide retry + policies. + +* the ``failure_text`` column at the initiated_outgoing_transactions table + should contain a JSON object that contains any useful detail about the problem. + That *could* be modeled after the Taler `ErrorDetail `_, where at least the error code and the hint fields are provided. -- cgit v1.2.3 From 95490a3234556594957a270ff0d051961b4b0ebc Mon Sep 17 00:00:00 2001 From: Özgür Kesim Date: Thu, 7 Dec 2023 20:41:58 +0100 Subject: [dd 28] added motivation --- design-documents/028-deposit-policies.rst | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) (limited to 'design-documents') diff --git a/design-documents/028-deposit-policies.rst b/design-documents/028-deposit-policies.rst index 956945ee..1bdf4801 100644 --- a/design-documents/028-deposit-policies.rst +++ b/design-documents/028-deposit-policies.rst @@ -41,7 +41,19 @@ The policies shall be implemented as *extensions* to the exchange (see Motivation ********** -TODO +GNU Taler's initial set of API's (withdraw, deposit, refresh) support most +payment situations in which customers pay for goods and services within an +otherwise unconditioned transaction. (A notable exception from this the +ability to provide refunds, which will be re-factored into a policy extension). + +However, in many payments depend on additional conditions to be met. GNU Taler +already supports payments with age restriction applied, but there are other +scenarious that we want to support. + +Our aim is to provide an API for extensions of GNU Taler that implement +particular policies and policy-handling for payments (also called *conditioned +payments*). + Background and Requirements *************************** @@ -56,9 +68,16 @@ TODO, explain: - C-structs for policy extensions (esp. the handlers) - Naming conventions for policy extensions - Deadlines and -handling -- API-endpoints (``/extensions/policy_...``) - Typical choreography of a deposit with policy and its fulfillment + +API-Endpoints of the Exchange +============================= + +TODO + + + Database-schema =============== -- cgit v1.2.3 From 866636826187d5fb02ba96a2ed534ae14857a0e1 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Mon, 11 Dec 2023 19:30:56 +0100 Subject: DD48: do not permanently brick wallets when an exchange is badly configured --- design-documents/048-wallet-exchange-lifecycle.rst | 28 +++++++++++++++++----- 1 file changed, 22 insertions(+), 6 deletions(-) (limited to 'design-documents') diff --git a/design-documents/048-wallet-exchange-lifecycle.rst b/design-documents/048-wallet-exchange-lifecycle.rst index b3df4d8a..75ec3afb 100644 --- a/design-documents/048-wallet-exchange-lifecycle.rst +++ b/design-documents/048-wallet-exchange-lifecycle.rst @@ -67,14 +67,24 @@ Update Status ~~~~~~~~~~~~~ * ``initial``: Not updated, no need to update -* ``initial(update)``: Update pending, possibly with error +* ``initial-update``: Update pending, possibly with error * ``suspended``: Exchange was manually disabled, should not be contacted anymore, but record is kept in the wallet. Mostly useful for testing. -* ``failed``: Updating the exchange info failed permanently, the exchange is - not usable for any operations. -* ``outdated(update)`` +* ``unavailable-update``: The exchange is currently unavailable to be used for withdrawals, + but it is possible that the exchange starts working again in the future. + The wallet will re-try contacting the exchange. The wallet will still try + operations that *spend* coins, but the user might be warned about the bad + exchange status. + + Examples: + + * The exchange updated to a new protocol version that is incompatible with the wallet + * The exchange advertises a new master public key. This might be a temporary + configuration issue or malicious attack. + * The exchange only advertises outdated denomination keys, making new withdrawals + impossible. * ``ready``: Exchange is useable. -* ``ready(update)``: Exchange is useable, but currently being updated. +* ``ready-update``: Exchange is useable, but currently being updated. ToS Status ~~~~~~~~~~ @@ -125,4 +135,10 @@ Definition of Done Discussion / Q&A ================ -(This should be filled in with results from discussions on mailing lists / personal communication.) +* Should there be a "permanently failed" update state? + + * dold => I don't think so, as it means that temporary configuration issues on the side of the + exchange might *permanently* brick users' wallets. + The wallet should always re-try contacting the exchange and of course possibly report + information to the auditor. + -- cgit v1.2.3 From 881331a7c2348da384a4d42f9b10c843f3c0c2f0 Mon Sep 17 00:00:00 2001 From: Antoine A <> Date: Fri, 15 Dec 2023 11:57:20 +0000 Subject: [dd 36] update with SQL triggers logic --- .../036-currency-conversion-service.rst | 97 ++++++++++------------ 1 file changed, 43 insertions(+), 54 deletions(-) (limited to 'design-documents') diff --git a/design-documents/036-currency-conversion-service.rst b/design-documents/036-currency-conversion-service.rst index 72a504c5..be3a01a0 100644 --- a/design-documents/036-currency-conversion-service.rst +++ b/design-documents/036-currency-conversion-service.rst @@ -35,11 +35,11 @@ currency. Requirements ============ -* CCS must not impact the Nexus structure. +* CCS must not impact the libeufin-nexus structure. * CCS must trigger Taler withdrawls every time a customer buys the - regional currency ('buy-in' operation). + regional currency ('cash-in' operation). * CCS must offer cash-out operations. -* CCS should react as soon as possible to buy-in and cash-out operations. +* CCS should react as soon as possible to cash-in and cash-out operations. * CCS must show its state to administrators and offer management tools. * CCS must link every fiat-side of a cash-out to its regional currency counterpart. In particular, because every cash-out starts with a @@ -49,60 +49,49 @@ Requirements Proposed Solution ================= -The following design assumes that CCS is coded into libeufin Sandbox. +The following design assumes that CCS is coded in libeufin-bank and that +libeufin-bank and libeufin-nexus share the same database with separate +schemas. The solution relies on SQL triggers to atomically synchronise +cash-in and cash-out operations between the two schemas. + +SQL triggers and conversion operations +-------------------------------------- + +Libeufin-bank controls the conversion support and sets up or removes +conversion SQL triggers when necessary. In order for the SQL triggers to +perform the conversion operations, the configurable rates/fees are stored +in the database and the conversion operations are performed using stored +SQL procedures. The SQL triggers and conversion procedures are stored in +the libeufin-bank schema. Cash-out operation ------------------ -The libeufin Sandbox component learns instantly about a cash-out -operation, because it's *the* service offering such feature. -Therefore, as soon as a cash-out operation gets TAN-confirmed, -Sandbox performs a first wire transfer from regio-user to regio-issuer -by specifying the amount without any rates/fees applied. Along -the same database transaction, Sandbox stores the *instructions* -of another payment *P* from fiat-issuer to fiat-target, but this time -**with** the cash-out rates/fees. Notably, P includes the **current** -fiat-target and the rates/fees, since these are configurable. - -Asynchronously, a background task picks P and sends it to the fiat bank. -Finally, fiat bank conducts P and fiat-target receives the wanted -amount. The same background task should also retry previous payments -like P that failed to be submitted to fiat bank. - -CCS offers management endpoints for prepared fiat-transactions. -Through them, adminisrators can see, retry, or cancel every fiat-transaction -that was prepared to pay fiat-target. - -Buy-in operation +Libeufin-bank learns instantly about a cash-out operation, because it's +*the* service offering such feature. Therefore, as soon as a cash-out +operation gets TAN-confirmed, libeufin-bank performs a wire transfer from +regio-user to regio-issuer by specifying the amount without any rates/fees +applied. Along the same database transaction, a SQL trigger store the +*instructions* of another payment *P* from fiat-issuer to fiat-target, +but this time **with** the cash-out rates/fees. + +Asynchronously, a libeufin-nexus background task picks P and sends it to +the fiat bank. Finally, fiat bank conducts P and fiat-target receives the +wanted amount. The same libeufin-nexus background task should also retry +previous payments like P that failed to be submitted to fiat bank. + +Cash-in operation ---------------- -A buy-in operation starts as soon as the customer sends a fiat -payment from fiat-customer to fiat-issuer. Sandbox is responsible to -detect such an incoming payment in a timely fashion. The detection -happens by long polling on the Nexus JSON API. Nexus is ultimately -responsible to query the fiat bank via EBICS every X seconds. X -should match the tightest interval allowed by the bank. - -When Sandbox detects one incoming payment on fiat-issuer, it applies the -**current** buy-in rates/fees and wires the resuling amount from regio-issuer -to regio-exchange. At this point, Nexus detects the incoming payment on -regio-exchange and makes the exchange aware via the Taler Wire Gateway API. -From now on, the system proceeds like it always did in Taler. - -Milestones to a MVP -=================== - -* Refactor configuration in Sandbox: `7527 `_, `7515 `_. -* Make rates/fees and TAN channels configurable in Sandbox: `7694 `_. -* Long polling in Nexus to serve TWG: `6987 `_, `6383 `_. -* Long polling in Nexus to serve fiat-transactions via native API: `7693 `_. -* Long polling in Sandbox to ask Nexus fiat-transactions via native API. -* Serve transactions with date ranges in Sandbox Access API: `7685 `_ -* Implement JSON-based "bank connection" in Nexus. That's how Nexus - gets regio-transactions to serve in the TWG. -* Implement fiat-bank's EBICS flavor. -* Ask transactions with date ranges in such flavor in Nexus: `7686 `_. -* Implement fiat-transactions management tools. - -.. note:: - The list can be incomplete and not necessarily ordered. +A cashin-in operation starts as soon as the customer sends a fiat +payment from fiat-customer to fiat-issuer. + +The libeufin-nexus component is responsible to query the fiat bank +via EBICS every X seconds. X should match the tightest interval allowed +by the bank. + +When libeufin-nexus registers an incoming payment on fiat-issuer in the +database, a SQL trigger applies the **current** cash-in rates/fees and +performs a wire transfer from regio-issuer to regio-exchange. Libeufin-bank +makes the exchange aware via the Taler Wire Gateway API and from now on, +the system proceeds like it always did in Taler. \ No newline at end of file -- cgit v1.2.3 From acc35112010c26254fe509b8f546309f2ccb37bf Mon Sep 17 00:00:00 2001 From: Antoine A <> Date: Fri, 15 Dec 2023 19:10:19 +0000 Subject: [dd 52] document current design solutions --- design-documents/052-libeufin-bank-2fa.rst | 123 +++++++++++++++++++++++++++++ design-documents/index.rst | 1 + 2 files changed, 124 insertions(+) create mode 100644 design-documents/052-libeufin-bank-2fa.rst (limited to 'design-documents') diff --git a/design-documents/052-libeufin-bank-2fa.rst b/design-documents/052-libeufin-bank-2fa.rst new file mode 100644 index 00000000..18ee82e2 --- /dev/null +++ b/design-documents/052-libeufin-bank-2fa.rst @@ -0,0 +1,123 @@ +DD 51: LibEufin Bank Two-factor authentification +################################################ + +Summary +======= + +This document proposes designs for supporting 2-FA for more operations in +libeufin-bank. + +Motivation +========== + +Currently, only cashout operations are protected using 2-FA and we want to also +protects withdrawal, transactions, account reconfiguration and account deletion. + +Requirements +============ + +* Support future TAN channels (YubiKey, trusted devices, etc) without API-breaking changes +* Support mulitple TAN channels per user + +Proposed Solutions +================== + +2 kinds of operations +^^^^^^^^^^^^^^^^^^^^^ + +We have two kinds of operations we would like to protect: + +* state-machine operations that already have a ``pending`` and ``confirmed`` status and require multiple endpoint calls to complete (cashout and withdrawal). +* one-shot operations that are currently completed using a single endpoint call (transaction, account reconfiguration and account deletion). + +We could choose different designs for each kind of operation, as they have different implementation challenges. + +Fine-grained or coarse-grained authentification +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fine-grained authorization is when one challenge is linked to a unique unalterable operation. They are the most secure and have the usability advantage that clients can show users exactly what they are allowing. They are complicated to implement especially for one-shot operations. +* Coarse-grained authorization is when each challenge allows to perform one or many protected operations of any kind. They are the simplest to implement and might be enough for our needs. + +We should also take in consideration how hard it would be to maintain the solution and how hard it would be to protect a new kind of operation in the future. + +State machines operations only +------------------------------ + +If we transform all operations to become state-machine ones, we can use the same design currently used for cashout operations. All operations are created in a ``pending`` state and need to be confirmed later. The TAN challenge code is sent when the operation is created and checked during confirmation. Operation creation is idempotent and can be used to trigger code retransmission. + +The good +^^^^^^^^ + ++ Fine-grained authorization + +The bad +^^^^^^^ + +- Requires to store pending operations in the database, requires new tables to store pending state for one-shot ones +- Requires to add many endpoints to track operations status, list pending operations, confirm operations, etc +- Requires to mix TAN challenge logic with operation logic, this means asking for TAN channel alongside operation data and returning TAN specific error in all operation creation and confirmation endpoints, therefore TAN logic changes can impact all those endpoints +- Operation logic rewrite +- Big backend and database change (new table or column and new API per operation) + + +Centralized 2FA endpoints +------------------------- + +To improve upon the previous design we can separate endpoints to perform TAN challenges from operation ones. When creating operations they return a challenge ID that can be used with TAN-specific endpoints to receive and solve a challenge. Those endpoints will handle the TAN channel choice and TAN-specific errors. Protected endpoints will error when a pending challenge hasn't been solved. + +The good +^^^^^^^^ + ++ Fine-grained authorization ++ Centralized TAN challenge logic and error handling, TAN logic changes only impact TAN-specific endpoints + +The bad +^^^^^^^ + +- Requires to store pending operations in the database +- Requires adding many endpoints to track operations status, confirm operations, list pending operations, etc. +- Operation logic rewrite +- Big backend and database change (new table or column and new API per operation) + +2FA tokens +---------- + +To improve upon the previous design, if coarse-grained authorization is enough, we can have a simpler design where a successful challenge produces a one-use 2FA token. Protected endpoints will error when a 2FA token is required and the token is provided through an HTTP header. + +We could require a 2FA token when confirming state-machine operations or when performing one-shot ones. Removing the need for new database tables and operation endpoints. + +The good +^^^^^^^^ + ++ Existing database tables stay the same ++ Centralized TAN challenge logic and error handling ++ Most endpoints stay the same except the cashout API ++ Can protect new operations without changing their logic but need to add token consumption logic to the database transaction ++ Small backend and database change per operation (token consumption logic) + +The bad +^^^^^^^ + +- Using a nonstandard header can be complicated for some clients +- The pending state of one-shot operations is kept at the client level, this is a simplification for the backend but we do not want to lose this state. This might be easy to do as all oneshot operations are simple ones and the token can be obtained in advance. +- Coarse-grained authorization, one token for any operation. We could fix this by adding a ``kind`` field and an optional ``operation_id`` (state-machine operation) or ``operation_body`` (one-shot operations) field per challenge but this is ugly. + +2FA auth tokens +--------------- +To improve upon the previous design, we could reuse the existing authentification token logic and create a new scope, ``2fa``, that works as an augmented ``readwrite``. Those auth tokens would be valid for a short amount of time (~3 minute) and would not be refreshable. + +The good +^^^^^^^^ + ++ Existing database tables stay the same ++ Centralized TAN challenge logic and error handling ++ Most endpoints stay the same except the cashout API ++ Can protect new operations without changing their logic ++ Trivial backend and database change per operation (one line of code per operation) + +The bad +^^^^^^^ + +- Having a short-term token in addition to a long-term refreshable token can be confusing for clients. +- We still keep the pending state of one-shot operations at the client level. +- Coarse-grained authorization, one token for any operation for a short amount of time. diff --git a/design-documents/index.rst b/design-documents/index.rst index eba03307..b37d8860 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -63,4 +63,5 @@ Design documents that start with "XX" are considered deprecated. 049-auth.rst 050-libeufin-nexus.rst 051-fractional-digits.rst + 052-libeufin-bank-2fa.rst 999-template -- cgit v1.2.3 From 522eb3d1a7f02adfa610b5916f42c223deb4811e Mon Sep 17 00:00:00 2001 From: Antoine A <> Date: Fri, 15 Dec 2023 19:19:54 +0000 Subject: [dd 52] fix typo --- design-documents/052-libeufin-bank-2fa.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'design-documents') diff --git a/design-documents/052-libeufin-bank-2fa.rst b/design-documents/052-libeufin-bank-2fa.rst index 18ee82e2..8e5711bb 100644 --- a/design-documents/052-libeufin-bank-2fa.rst +++ b/design-documents/052-libeufin-bank-2fa.rst @@ -1,4 +1,4 @@ -DD 51: LibEufin Bank Two-factor authentification +DD 52: LibEufin Bank Two-factor authentification ################################################ Summary -- cgit v1.2.3 From 1b404c2d1f5ec16dbca30e245d51a91e136ddcc6 Mon Sep 17 00:00:00 2001 From: Antoine A <> Date: Fri, 15 Dec 2023 19:37:57 +0000 Subject: [dd 52] add Q / A --- design-documents/052-libeufin-bank-2fa.rst | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) (limited to 'design-documents') diff --git a/design-documents/052-libeufin-bank-2fa.rst b/design-documents/052-libeufin-bank-2fa.rst index 8e5711bb..3d0900e2 100644 --- a/design-documents/052-libeufin-bank-2fa.rst +++ b/design-documents/052-libeufin-bank-2fa.rst @@ -17,7 +17,7 @@ Requirements ============ * Support future TAN channels (YubiKey, trusted devices, etc) without API-breaking changes -* Support mulitple TAN channels per user +* Support multiple TAN channels per user Proposed Solutions ================== @@ -30,8 +30,6 @@ We have two kinds of operations we would like to protect: * state-machine operations that already have a ``pending`` and ``confirmed`` status and require multiple endpoint calls to complete (cashout and withdrawal). * one-shot operations that are currently completed using a single endpoint call (transaction, account reconfiguration and account deletion). -We could choose different designs for each kind of operation, as they have different implementation challenges. - Fine-grained or coarse-grained authentification ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -121,3 +119,18 @@ The bad - Having a short-term token in addition to a long-term refreshable token can be confusing for clients. - We still keep the pending state of one-shot operations at the client level. - Coarse-grained authorization, one token for any operation for a short amount of time. + +Q / A +===== + +* Q: Where do we want to handle TAN challenges logic and error handling, in each operation API or a TAN-specific API? + + * In each operation means fewer API calls and TAN-specific means more API calls but better/cleaner logic separation. + +* Q: Where do we want to store pending states for oneshot transactions in the client or the backend database? + + * In the client makes things simpler for the backend but is incompatible with coarse-grained authorization. + +* Q: Do we need coarse-grained authorization or fine-grained is enough? + + * Coarse-grained authorization requires that we store pending states for operations even for the ones that are currently oneshot. We could use a different strategy for each kind. \ No newline at end of file -- cgit v1.2.3 From 57a78d71ab7a4bd774bdf7f8509710dc498b4c98 Mon Sep 17 00:00:00 2001 From: Devan Carpenter Date: Sun, 17 Dec 2023 19:39:17 -0500 Subject: DD44: update path references CI dirs are under "contrib/" now --- design-documents/044-ci-system.rst | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) (limited to 'design-documents') diff --git a/design-documents/044-ci-system.rst b/design-documents/044-ci-system.rst index e777f345..78d64830 100644 --- a/design-documents/044-ci-system.rst +++ b/design-documents/044-ci-system.rst @@ -43,23 +43,24 @@ Example directory structure: :: - ci - ├── ci.sh - ├── Containerfile - └── jobs - ├── 0-codespell - │   ├── config.ini - │   ├── dictionary.txt - │   └── job.sh - ├── 1-build - │   ├── build.sh - │   └── job.sh - └── 2-docs - ├── docs.sh - └── job.sh + contrib + └── ci + ├── ci.sh + ├── Containerfile + └── jobs + ├── 0-codespell + │   ├── config.ini + │   ├── dictionary.txt + │   └── job.sh + ├── 1-build + │   ├── build.sh + │   └── job.sh + └── 2-docs + ├── docs.sh + └── job.sh Job directories **MUST** follow this pattern: -``/ci/jobs//`` +``/contrib/ci/jobs//`` ``n`` is an integer used for ordering the build steps. @@ -78,10 +79,11 @@ Available config options: WARN_ON_FAILURE = True|False CONTAINER_BUILD = True|False CONTAINER_NAME = + CONTAINER_ARCH = Unless *all* jobs specify a "CONTAINER_NAME" in their custom config a -container file **MUST** be present at ``/ci/Containerfile``. +container file **MUST** be present at ``/contrib/ci/Containerfile``. The container file will be built and used to run all of a repo's jobs by default. -- cgit v1.2.3 From ac94943039f6cd70cd19b03846f5019d2eecc152 Mon Sep 17 00:00:00 2001 From: Devan Carpenter Date: Sun, 17 Dec 2023 19:40:47 -0500 Subject: DD44: document using script to run jobs local --- design-documents/044-ci-system.rst | 38 +++++++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 15 deletions(-) (limited to 'design-documents') diff --git a/design-documents/044-ci-system.rst b/design-documents/044-ci-system.rst index 78d64830..cfb733aa 100644 --- a/design-documents/044-ci-system.rst +++ b/design-documents/044-ci-system.rst @@ -94,24 +94,32 @@ Running CI Locally Running the CI scripts locally can be useful for development and testing. -*Be aware that custom configs for a given job may specify a alternate -container.* - - -Example of building the environment and running a job locally: +Included in each CI directory is a script which simplifies running jobs +in the same way the CI Worker does, in containers, using either `podman` +or `docker`, detecting if you have either installed. :: - # From root of repo directory, build the container: - docker build -t -f ci/Containerfile . # <- don't forget the "." - - # Then to run one of the job scripts. For example: - docker run --rm --volume $PWD:/workdir --workdir /workdir ci/jobs/1-build/job.sh - - # or to get an interactive shell in the container, with the repo mounted at /workdir: - docker run -ti --rm --volume $PWD:/workdir --workdir /workdir /bin/bash - - + # Usage: + ./contrib/ci/ci.sh + + # For example, if the CI jobs tree looks like this: + ./contrib/ci/jobs + ├── 0-codespell/ + ├── 1-build/ + ├── 2-test/ + ├── 3-docs/ + ├── 4-deb-package/ + └── 5-deploy-package/ + + # Then you can run job '0-codespell' as follows: + ./contrib/ci/ci.sh 0-codespell + + # If you are using podman and have "qemu-user-binfmt" installed + # then you may attempt to run any job under an alternative CPU + # architecture by providing a second argument. + # For example: + ./contrib/ci/ci.sh 0-codespell arm64 Additional Builders -- cgit v1.2.3 From 00e43c15cd1211cf6c1a7bb50963ab15f2ae6ee0 Mon Sep 17 00:00:00 2001 From: Sebastian Date: Tue, 26 Dec 2023 17:36:40 -0300 Subject: first draft of UI spec --- design-documents/053-wallet-ui.rst | 289 +++++++++++++++++++++++++++++++++++++ design-documents/index.rst | 1 + 2 files changed, 290 insertions(+) create mode 100644 design-documents/053-wallet-ui.rst (limited to 'design-documents') diff --git a/design-documents/053-wallet-ui.rst b/design-documents/053-wallet-ui.rst new file mode 100644 index 00000000..5891eb37 --- /dev/null +++ b/design-documents/053-wallet-ui.rst @@ -0,0 +1,289 @@ +DD 53: Wallet UI Design +####################### + +Summary +======= + +This document proposes designs wallet UI. It defines what Android, iOS and +WebExtension should follow in order to have a coherent UI between platforms. + +Motivation +========== + +We want user to be able to help each others independent of the implementation +they are using. +We want user to be able to capitalize the effort of learning how to use one +wallet and be able to use a different one without the need to learn +anything new. +Currently development of different platform specific implementation are independent +and every developer needs to choose the layout, texts and buttons and navigation. + +Requirements +============ + +Every screen MUST be defined in a document with the following information: + +* **Identifiable UI screens**: every UI should have an unique identifier that will + be use for development discussion and bug reports. There should be an option + in the application to enable an active rendering of the id. + +* **Description**: the reason to be of the screen, should help to define what will + be included into, what is going to left for other screens and when and from + where should be linked. + +The screen MAY also have: + +* **Predefined assets**: every implementation should resue the same icons, images, + fonts and sounds. + +Additionaly the document COULD defined the components of the UI. If one of this +properties is defined in the spec the implementation must implement it. The specification +should be minimal to achieve the objective in the description. + +* **Info**: Spec of information that the user should have access. The type of info + could be a field (id and value) or a banner (information and instructions). + The spec will help to reuse the text for i18n across apps and defined + +* **Inputs**: Spec of information need to provide in current screen. The type of input, + range of values and validation should be defined if necessary. + +* **Actions**: Spec of buttons and interactable elements that will have a significant + change in the current state. It should also mention navigation when applicable. + +* **Layout**: Spec position of elements when needed. The spec should be "soft" in a sense + that elements should be easy to find following directions like "close to X" or + "at the start/end of the screen". + +Screen should be defined using the most relaxed definition that are good enough to +be clear for the user. Platform will use this definition and adapt to the differences +on the platform taking advantange of platform API and screen sizes. + +When a screen have multiple uses for the same purpose, a substate section should be +included with the difference with the main definition. + +Part of the screens that are reused shoud also be defined in this document as screen. + +Common definition: + * navigation between screen should not happen if the user didn't take any action + + +Proposed Solutions +================== + +List of dall screens with the defined properties + +cta-withdraw +------------ + +``Description``: this screen is used for the confirmation of a manual withdrawal, +bank-integrated witdrawals and exchange withdrawals. +the success of this operation will be an increase of the balance in the wallet. +fee, restrictions and ETA should be clear for the user. + +``Info``: + * exchange to be used showing the URL + * table of details of the operation: use the ``operation-table-details`` screen + * starting currency: if the exchange has the currency conversion service enabled user should be able to the details based on the wire transfer currency + * taler URI: show copy button or QR to complete the operation with another device + +``Inputs``: + * age restriction: allow the selection of the restriction in the age group possible by the exchange + * service provider: allow the selection of different exchange + +``Actions``: + * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed + * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen + * cancel: user will be redirected to ``balance`` + +.. attention:: + User should be able to play with the amount, not possible in the current design + +cta-payment +------------ + +``Description``: this screen is used for the confirmation of a payment to a merchant. +the success of this operation will be an decrease of the balance in the wallet +and save a ticket/invoice of the purchase. +fee, restrictions and ETA should be clear for the user. + +``Info``: + * merchant offering the order showing the URL + * order summary + * table of details of the operation: use the ``operation-table-details`` screen + * receipt: order id + * payment deadline: absolute time before the claimed order expires + * taler URI: show copy button or QR to complete the operation with another device + * cant pay desc: if the user has enough balance but unable to use it + * payment status: if the + +``Actions``: + * confirm operation: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed + * get more cash: if there is not enough balance, it will be redirected to ``cta-witddraw`` + * cancel: user will be redirected to ``balance`` + +cta-deposit +------------ + +``Description``: this screen is used for the confirmation of a deposit. +the success of this operation will be an decrease of the balance in the wallet +and save a deposit ticket for reference. +fee, restrictions and ETA should be clear for the user. + +``Info``: + * bank account where the money is going to + * table of details of the operation: use the ``operation-table-details`` screen + +``Actions``: + * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed + * cancel: user will be redirected to ``balance`` + +.. attention:: + User should be able to play with the amount, not possible in the current design + +cta-peer-pull-initiate +---------------------- + +``Description``: this screen is used for the confirmation of the creation of +a peer pull transaction or invoice to request money from another wallet. +the success of this operation will not change the balance immediately in the wallet +and allow the user to share a taler URI to the payer. +fee, restrictions and ETA should be clear for the user. + +``Info``: + * exchange to be used showing the URL + * table of details of the operation: use the ``operation-table-details`` screen + +``Inputs``: + * subject: short description of the transaction + * expiration: absolute time/date after which the invoice is not valid anymore + * service provider: allow the selection of different exchange + +``Actions``: + * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed + * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen + * cancel: user will be redirected to ``balance`` + +.. attention:: + Is the invoice creation always free of charge or does the exchange have a mechanism + to impose a fee to pay on creation? + + +cta-peer-pull-confirm +--------------------- + +``Description``: this screen is used for the confirmation of the payment of +a peer pull transaction or invoice to send money from another wallet. +the success of this operation will be an will decrease the balance in the wallet. +fee, restrictions and ETA should be clear for the user. + +``Info``: + * exchange to be used showing the URL + * subject: short description of the transaction + * table of details of the operation: use the ``operation-table-details`` screen + * expiration: absolute time/date after which the invoice is not valid anymore + +``Actions``: + * confirm operation: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed + * get more cash: if there is not enough balance, it will be redirected to ``cta-witddraw`` + * cancel: user will be redirected to ``balance`` + +cta-peer-push-initiate +---------------------- + +``Description``: this screen is used for the confirmation of the creation of +a peer push transaction or transfer money to another wallet. +the success of this operation will reduce the balance immediately in the wallet +and allow the user to share a taler URI to the receiver. +fee, restrictions and ETA should be clear for the user. + +``Info``: + * table of details of the operation: use the ``operation-table-details`` screen + +``Inputs``: + * subject: short description of the transaction + * expiration: absolute time/date after which the transfer is not valid anymore + +``Actions``: + * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed + * cancel: user will be redirected to ``balance`` + +cta-peer-push-confirm +--------------------- + +``Description``: this screen is used for the confirmation of the acceptance of +a peer push transaction or transfer money to this wallet. +the success of this operation will be an will decrease the balance in the wallet. +fee, restrictions and ETA should be clear for the user. + +``Info``: + * subject: short description of the payment + * expiration: absolute time/date after which the invoice is not valid anymore + * table of details of the operation: use the ``operation-table-details`` screen + +``Actions``: + * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed + * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen + * cancel: user will be redirected to ``balance`` + +cta-reward +----------- + +``Description``: this screen is used for the confirmation of the acceptance of +a reward from a merchant. +the success of this operation will be an will decrease the balance in the wallet. +fee, restrictions and ETA should be clear for the user. + +``Info``: + * amount: effective amount to receive + * exchange: from where this money comes from + * merchant: offering the reward + +``Actions``: + * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed + * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen + * cancel: user will be redirected to ``balance`` + + +operation-table-details +----------------------- + +``Description``: with the table it should be clear how much the operation will cost, +the initial amount and the final amount with all the items related to the operations (like fee) + +``labels``: initial amount of the operation, and final amount are always shown. +Fee should be shown as an extra row in the table if it is non-zero. +Converted amount should be shown as an extra row if initial amount currency is not the same +as the final amount currency. + +Initial amount label by operation: + + * payment -> Price + * deposit -> Send + * peer-pull-credit -> Invoice + * peer-pull-debit -> Invoice + * peer-push-debit -> Send + * peer-push-credit -> Transfer + * withdrawal -> Transfer + * refund -> Refund + + +accept-tos +---------- + +``Description``: this screen can be use everytime that the user is going to interact +with an exchange. since at any moment wallet may find that ToS changed the user needs +to be prevented from continue before reading/accepting new rules. If possible, this +screen should be used inplace of other actions and hidden if not required (for example, +user already accepted ToS) + +``Inputs``: + * format: allow the selection of a ToS format + * languange: allow the selection of a languange different from system lang + +``Actions``: + * accept tos: will mark this version as accepted in wallet core and redirect the user to the screen from where it was invoked + * save/print tos: will save the ToS outside of the wallet + +Q / A +===== + diff --git a/design-documents/index.rst b/design-documents/index.rst index b37d8860..1199b1fc 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -64,4 +64,5 @@ Design documents that start with "XX" are considered deprecated. 050-libeufin-nexus.rst 051-fractional-digits.rst 052-libeufin-bank-2fa.rst + 053-wallet-ui.rst 999-template -- cgit v1.2.3 From 05a762edf2e5b26be763573476c5721c3200978f Mon Sep 17 00:00:00 2001 From: Sebastian Date: Tue, 2 Jan 2024 18:18:43 -0300 Subject: first version of dynamic forms --- design-documents/054-dynamic-form.rst | 182 ++++++++++++++++++++++++++++++++++ design-documents/index.rst | 1 + 2 files changed, 183 insertions(+) create mode 100644 design-documents/054-dynamic-form.rst (limited to 'design-documents') diff --git a/design-documents/054-dynamic-form.rst b/design-documents/054-dynamic-form.rst new file mode 100644 index 00000000..b2d2e262 --- /dev/null +++ b/design-documents/054-dynamic-form.rst @@ -0,0 +1,182 @@ +DD 53: Dynamic Web Form +####################### + +Summary +======= + +This document defines an approach of a dynamic web form. + +Motivation +========== + +Currently when a web app need a form a new page needs to be coded +with HTML, css and js. +Exchange AML have multiple forms and different instance may have +different form depending on the jurisdiction. + +Requirements +============ + +A form consist of a layout and a set of fields. +Layout requirements: + +* **editable by system admin**: if new form is required system admin should +be able to create a new form. + +* **accesibility**: forms should satisfy accesibility level AA. + +* **responsive**: forms should work on all devices. + +* **metadata**: generated info by the form should contain enough information +to handle multiple version of the form. + +Fields requirements: + +* **validations**: each field may required custom validation + +* **custom data type**: a field may consist of a list, string, number or a complex +composite structure. + + +Proposed Solutions +================== + +Forms are initialized with the follow structure: + +``` +interface FormType { + value: Partial; + initial?: Partial; + readOnly?: boolean; + onUpdate?: (v: Partial) => void; + computeFormState?: (v: Partial) => FormState; +} +``` + +`T`: is the type of the result object +`value`: is a reference to the current value of the result +`readOnly`: when true, fields won't allow input +`onUpdate`: notification of the result update +`computeFormState`: compute a new state of the form based on the current value + +Form state have the same shape of `T` but every field type is `FieldUIOptions`. + +Fields type can be: + * strings + * numbers + * boolean + * arrays + * object + +The field type `AmountJson` and `AbsoluteTime` are opaque since field is used as a whole. + +The form can be instanciated using + +``` +import { FormProvider } from "@gnu-taler/web-util/browser"; +``` + +Then the field component can access all the properties by the `useField(name)` hook, +which will return + +``` +interface InputFieldHandler { + value: Type; + onChange: (s: Type) => void; + state: FieldUIOptions; + isDirty: boolean; +} +``` + +`value`: the current value of the field +`onChange`: a function to call anytime the user want to change the value +`state`: the state of the field (hidden, error, etc..) +`isDirty`: if the user already tried to change the value + +A set of common form field exist in `@gnu-taler/web-util`: + + * InputAbsoluteTime + * InputAmount + * InputArray + * InputFile + * InputText + * InputToggle + +and should be used inside a `Form` context. + +``` +function MyFormComponent():VNode { + return + + + + +} + +Example +------------------------- + +For example, for the form shape: + +``` +type theFormType = { + name: string, + age: number, + savings: AmountJson, + nextBirthday: AbsoluteTime, + pets: string[], + addres: { + street: string, + city: string, + } +} +``` + +one example instance of the form: + +``` +const theFormValue = { + name: "Sebastian", + age: 15, + pets: ["dog","cat"], + address: { + street: "long", + city: "big", + } +} +``` + +and one example valid state + +``` +function computeFormStateBasedOnFormValues(formValues): { + //returning fixed state as an example + //the return state will be commonly be computed from the values of the form + return { + age: { + hidden: true, + }, + pets: { + disabled: true, + elements: [{ + disabled: false, + }], + }, + address: { + street: { + required: true, + error: "the street name was not found", + }, + city: { + required: true, + }, + }, + } +} +``` + + + +Q / A +===== + diff --git a/design-documents/index.rst b/design-documents/index.rst index 1199b1fc..91bfce4c 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -65,4 +65,5 @@ Design documents that start with "XX" are considered deprecated. 051-fractional-digits.rst 052-libeufin-bank-2fa.rst 053-wallet-ui.rst + 054-dynamic-form.rst 999-template -- cgit v1.2.3 From ae0c46261c8fd8d71b38cfdd529dcf78767d327b Mon Sep 17 00:00:00 2001 From: Sebastian Date: Tue, 2 Jan 2024 18:19:07 -0300 Subject: rewords DD 54 --- design-documents/054-dynamic-form.rst | 61 +++++++++++++++++++++-------------- 1 file changed, 37 insertions(+), 24 deletions(-) (limited to 'design-documents') diff --git a/design-documents/054-dynamic-form.rst b/design-documents/054-dynamic-form.rst index b2d2e262..336339bf 100644 --- a/design-documents/054-dynamic-form.rst +++ b/design-documents/054-dynamic-form.rst @@ -4,44 +4,52 @@ DD 53: Dynamic Web Form Summary ======= -This document defines an approach of a dynamic web form. +This document outlines the approach for implementing a dynamic web form feature. Motivation ========== -Currently when a web app need a form a new page needs to be coded -with HTML, css and js. -Exchange AML have multiple forms and different instance may have -different form depending on the jurisdiction. +Currently, creating a new form for a web app involves coding a new +page with HTML, CSS, and JS. Exchange AML requires multiple forms, +and different instances may have distinct forms based on jurisdiction. + Requirements ============ A form consist of a layout and a set of fields. -Layout requirements: -* **editable by system admin**: if new form is required system admin should -be able to create a new form. +Layout requirements +------------------- -* **accesibility**: forms should satisfy accesibility level AA. +* **editable by system admin**: System admins should be able to create new forms +or edit current one shipped with the source. -* **responsive**: forms should work on all devices. +* **accesibility**: Forms should meet accessibility level AA. -* **metadata**: generated info by the form should contain enough information -to handle multiple version of the form. +* **responsive**: Forms should be responsive and function on all devices. + +* **metadata**: Generated form information should contain enough data +to handle multiple form versions. -Fields requirements: +Fields requirements +------------------- -* **validations**: each field may required custom validation +* **validations**: Each field may require custom validation + +* **custom data type**: A field may consist of a list, string, number, or a +complex composite structure. -* **custom data type**: a field may consist of a list, string, number or a complex -composite structure. - Proposed Solutions ================== -Forms are initialized with the follow structure: +Forms are initialized using a flexible structure defined by the +TypeScript interface FormType. This interface comprises properties +such as value (current form data), initial (initial form data for resetting), +readOnly (flag to disable input), onUpdate (callback on form data update), +and computeFormState (function to derive the form state based on current data). + ``` interface FormType { @@ -55,6 +63,7 @@ interface FormType { `T`: is the type of the result object `value`: is a reference to the current value of the result +`initial`: data for resetting `readOnly`: when true, fields won't allow input `onUpdate`: notification of the result update `computeFormState`: compute a new state of the form based on the current value @@ -114,12 +123,12 @@ function MyFormComponent():VNode { } Example -------------------------- +-------- -For example, for the form shape: +Consider a form shape represented by the TypeScript type: ``` -type theFormType = { +type TheFormType = { name: string, age: number, savings: AmountJson, @@ -132,10 +141,10 @@ type theFormType = { } ``` -one example instance of the form: +An example instance of this form could be: ``` -const theFormValue = { +const theFormValue: TheFormType = { name: "Sebastian", age: 15, pets: ["dog","cat"], @@ -146,7 +155,11 @@ const theFormValue = { } ``` -and one example valid state +For such a form, a valid state can be computed using a function like +`computeFormStateBasedOnFormValues`, returning an object indicating +the state of each field, including properties such as `hidden`, +`disabled`, and `required`. + ``` function computeFormStateBasedOnFormValues(formValues): { -- cgit v1.2.3 From f700a38dd22765bf8027023144e33ea4f1cf8e16 Mon Sep 17 00:00:00 2001 From: Sebastian Date: Wed, 3 Jan 2024 17:16:26 -0300 Subject: aml forms documentation --- design-documents/054-dynamic-form.rst | 199 ++++++++++++++++++---------------- taler-exchange-manual.rst | 41 +++++++ 2 files changed, 144 insertions(+), 96 deletions(-) (limited to 'design-documents') diff --git a/design-documents/054-dynamic-form.rst b/design-documents/054-dynamic-form.rst index 336339bf..968ca83b 100644 --- a/design-documents/054-dynamic-form.rst +++ b/design-documents/054-dynamic-form.rst @@ -23,14 +23,14 @@ Layout requirements ------------------- * **editable by system admin**: System admins should be able to create new forms -or edit current one shipped with the source. + or edit current one shipped with the source. * **accesibility**: Forms should meet accessibility level AA. * **responsive**: Forms should be responsive and function on all devices. * **metadata**: Generated form information should contain enough data -to handle multiple form versions. + to handle multiple form versions. Fields requirements ------------------- @@ -38,7 +38,7 @@ Fields requirements * **validations**: Each field may require custom validation * **custom data type**: A field may consist of a list, string, number, or a -complex composite structure. + complex composite structure. Proposed Solutions @@ -51,24 +51,25 @@ readOnly (flag to disable input), onUpdate (callback on form data update), and computeFormState (function to derive the form state based on current data). -``` -interface FormType { - value: Partial; - initial?: Partial; - readOnly?: boolean; - onUpdate?: (v: Partial) => void; - computeFormState?: (v: Partial) => FormState; -} -``` +.. code-block:: javascript -`T`: is the type of the result object -`value`: is a reference to the current value of the result -`initial`: data for resetting -`readOnly`: when true, fields won't allow input -`onUpdate`: notification of the result update -`computeFormState`: compute a new state of the form based on the current value + interface FormType { + value: Partial; + initial?: Partial; + readOnly?: boolean; + onUpdate?: (v: Partial) => void; + computeFormState?: (v: Partial) => FormState; + } + + +``T``: is the type of the result object +``value``: is a reference to the current value of the result +``initial``: data for resetting +``readOnly``: when true, fields won't allow input +``onUpdate``: notification of the result update +``computeFormState``: compute a new state of the form based on the current value -Form state have the same shape of `T` but every field type is `FieldUIOptions`. +Form state have the same shape of ``T`` but every field type is ``FieldUIOptions``. Fields type can be: * strings @@ -77,32 +78,34 @@ Fields type can be: * arrays * object -The field type `AmountJson` and `AbsoluteTime` are opaque since field is used as a whole. +The field type ``AmountJson`` and ``AbsoluteTime`` are opaque since field is used as a whole. The form can be instanciated using -``` -import { FormProvider } from "@gnu-taler/web-util/browser"; -``` +.. code-block:: javascript -Then the field component can access all the properties by the `useField(name)` hook, + import { FormProvider } from "@gnu-taler/web-util/browser"; + + +Then the field component can access all the properties by the ``useField(name)`` hook, which will return -``` -interface InputFieldHandler { - value: Type; - onChange: (s: Type) => void; - state: FieldUIOptions; - isDirty: boolean; -} -``` +.. code-block:: javascript -`value`: the current value of the field -`onChange`: a function to call anytime the user want to change the value -`state`: the state of the field (hidden, error, etc..) -`isDirty`: if the user already tried to change the value + interface InputFieldHandler { + value: Type; + onChange: (s: Type) => void; + state: FieldUIOptions; + isDirty: boolean; + } -A set of common form field exist in `@gnu-taler/web-util`: + +``value``: the current value of the field +``onChange``: a function to call anytime the user want to change the value +``state``: the state of the field (hidden, error, etc..) +``isDirty``: if the user already tried to change the value + +A set of common form field exist in ``@gnu-taler/web-util``: * InputAbsoluteTime * InputAmount @@ -111,82 +114,86 @@ A set of common form field exist in `@gnu-taler/web-util`: * InputText * InputToggle -and should be used inside a `Form` context. +and should be used inside a ``Form`` context. + +.. code-block:: javascript + + function MyFormComponent():VNode { + return + + + + + } -``` -function MyFormComponent():VNode { - return - - - - -} Example -------- Consider a form shape represented by the TypeScript type: -``` -type TheFormType = { - name: string, - age: number, - savings: AmountJson, - nextBirthday: AbsoluteTime, - pets: string[], - addres: { - street: string, - city: string, +.. code-block:: javascript + + type TheFormType = { + name: string, + age: number, + savings: AmountJson, + nextBirthday: AbsoluteTime, + pets: string[], + addres: { + street: string, + city: string, + } } -} -``` An example instance of this form could be: -``` -const theFormValue: TheFormType = { - name: "Sebastian", - age: 15, - pets: ["dog","cat"], - address: { - street: "long", - city: "big", +.. code-block:: javascript + + const theFormValue: TheFormType = { + name: "Sebastian", + age: 15, + pets: ["dog","cat"], + address: { + street: "long", + city: "big", + } } -} -``` + For such a form, a valid state can be computed using a function like -`computeFormStateBasedOnFormValues`, returning an object indicating -the state of each field, including properties such as `hidden`, -`disabled`, and `required`. - - -``` -function computeFormStateBasedOnFormValues(formValues): { - //returning fixed state as an example - //the return state will be commonly be computed from the values of the form - return { - age: { - hidden: true, - }, - pets: { - disabled: true, - elements: [{ - disabled: false, - }], - }, - address: { - street: { - required: true, - error: "the street name was not found", +``computeFormStateBasedOnFormValues``, returning an object indicating +the state of each field, including properties such as ``hidden``, +``disabled``, and ``required``. + + +.. code-block:: javascript + + function computeFormStateBasedOnFormValues(formValues): { + //returning fixed state as an example + //the return state will be commonly be computed from the values of the form + return { + age: { + hidden: true, }, - city: { - required: true, + pets: { + disabled: true, + elements: [{ + disabled: false, + }], }, - }, + address: { + street: { + required: true, + error: "the street name was not found", + }, + city: { + required: true, + }, + }, + } } -} -``` + diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst index f66463d1..4b3fe044 100644 --- a/taler-exchange-manual.rst +++ b/taler-exchange-manual.rst @@ -2009,6 +2009,47 @@ 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'. +AML Forms +--------- + +AML forms are defined by the DD 54 dynamic forms. +The shipped implementation with of the exchange is installed in + +.. code-block:: shell-session + + ${INSTALL_PREFIX}/share/taler/exchange/spa/forms.js + + +The variable ``form`` contains the list of all form available. For +every entry in the list the next properties are expected to be present: + +``label``: used in the UI as the name of the form + +``icon``: an SVN used in the UI + +``id``: identification name, this will be saved in the exchange database +along with the values to correctly render the form again. +It should simple, short and without any character outside numbers, +letters and underscore. + +``version``: when editing a form, instead of just replacing fields +it will be better to create a new form with the same id and new version. +That way old forms in the database will used old definition of the form. +It should be a number. + +``impl`` : a function that returns the design and behavior of form. +See DD 54 dynamic forms. + +.. attention:: + + do not remove a form the list if it has been used. Otherwise you + won't be able to see the information save in the exchange database. + +To add a new one you can simply copy and paste one element, and edit it. + +It is much easier to download ``@gnu-taler/aml-backoffice-ui`` source +from ``https://git.taler.net/wallet-core.git/``, compile and copy the file +from the ``dist/prod``. Setup Linting -- cgit v1.2.3 From 4688ad2730d57a8cfc016bc2f30d06affff7d420 Mon Sep 17 00:00:00 2001 From: Sebastian Date: Wed, 3 Jan 2024 17:29:30 -0300 Subject: 53 -> 54 --- design-documents/054-dynamic-form.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'design-documents') diff --git a/design-documents/054-dynamic-form.rst b/design-documents/054-dynamic-form.rst index 968ca83b..6a6d96af 100644 --- a/design-documents/054-dynamic-form.rst +++ b/design-documents/054-dynamic-form.rst @@ -1,4 +1,4 @@ -DD 53: Dynamic Web Form +DD 54: Dynamic Web Form ####################### Summary -- cgit v1.2.3 From 2f78f048c007ade79421fd921e2cafdab1a2c9ee Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sat, 6 Jan 2024 14:01:39 +0100 Subject: -misc fixes, add taler-merchant-depositcheck --- conf.py | 7 ++ .../036-currency-conversion-service.rst | 52 ++++++------- design-documents/044-ci-system.rst | 13 ++-- design-documents/054-dynamic-form.rst | 37 +++++---- libeufin/regional-manual.rst | 88 +++++++++++----------- manpages/taler-merchant-depositcheck.1 | 72 ++++++++++++++++++ taler-auditor-manual.rst | 1 + 7 files changed, 174 insertions(+), 96 deletions(-) create mode 100644 manpages/taler-merchant-depositcheck.1 (limited to 'design-documents') diff --git a/conf.py b/conf.py index fc747f0a..e1663ff4 100644 --- a/conf.py +++ b/conf.py @@ -609,6 +609,13 @@ man_pages = [ "GNU Taler contributors", 1, ), + ( + "manpages/taler-merchant-depositcheck.1", + "taler-merchant-depositcheck", + "check status of deposits with exchange", + "GNU Taler contributors", + 1, + ), ( "manpages/taler-merchant-setup-reserve.1", "taler-merchant-setup-reserve", diff --git a/design-documents/036-currency-conversion-service.rst b/design-documents/036-currency-conversion-service.rst index be3a01a0..92d88499 100644 --- a/design-documents/036-currency-conversion-service.rst +++ b/design-documents/036-currency-conversion-service.rst @@ -44,54 +44,54 @@ Requirements * CCS must link every fiat-side of a cash-out to its regional currency counterpart. In particular, because every cash-out starts with a payment *P* from regio-user to regio-issuer and ends with another - payment *Q* from fiat-issuer to fiat-target, CCS must link P and Q. + payment *Q* from fiat-issuer to fiat-target, CCS must link P and Q. Proposed Solution ================= -The following design assumes that CCS is coded in libeufin-bank and that -libeufin-bank and libeufin-nexus share the same database with separate -schemas. The solution relies on SQL triggers to atomically synchronise +The following design assumes that CCS is coded in libeufin-bank and that +libeufin-bank and libeufin-nexus share the same database with separate +schemas. The solution relies on SQL triggers to atomically synchronise cash-in and cash-out operations between the two schemas. SQL triggers and conversion operations -------------------------------------- -Libeufin-bank controls the conversion support and sets up or removes -conversion SQL triggers when necessary. In order for the SQL triggers to -perform the conversion operations, the configurable rates/fees are stored -in the database and the conversion operations are performed using stored -SQL procedures. The SQL triggers and conversion procedures are stored in +Libeufin-bank controls the conversion support and sets up or removes +conversion SQL triggers when necessary. In order for the SQL triggers to +perform the conversion operations, the configurable rates/fees are stored +in the database and the conversion operations are performed using stored +SQL procedures. The SQL triggers and conversion procedures are stored in the libeufin-bank schema. Cash-out operation ------------------ Libeufin-bank learns instantly about a cash-out operation, because it's -*the* service offering such feature. Therefore, as soon as a cash-out -operation gets TAN-confirmed, libeufin-bank performs a wire transfer from -regio-user to regio-issuer by specifying the amount without any rates/fees -applied. Along the same database transaction, a SQL trigger store the -*instructions* of another payment *P* from fiat-issuer to fiat-target, +*the* service offering such feature. Therefore, as soon as a cash-out +operation gets TAN-confirmed, libeufin-bank performs a wire transfer from +regio-user to regio-issuer by specifying the amount without any rates/fees +applied. Along the same database transaction, a SQL trigger store the +*instructions* of another payment *P* from fiat-issuer to fiat-target, but this time **with** the cash-out rates/fees. -Asynchronously, a libeufin-nexus background task picks P and sends it to -the fiat bank. Finally, fiat bank conducts P and fiat-target receives the -wanted amount. The same libeufin-nexus background task should also retry +Asynchronously, a libeufin-nexus background task picks P and sends it to +the fiat bank. Finally, fiat bank conducts P and fiat-target receives the +wanted amount. The same libeufin-nexus background task should also retry previous payments like P that failed to be submitted to fiat bank. Cash-in operation ----------------- +----------------- A cashin-in operation starts as soon as the customer sends a fiat -payment from fiat-customer to fiat-issuer. +payment from fiat-customer to fiat-issuer. -The libeufin-nexus component is responsible to query the fiat bank -via EBICS every X seconds. X should match the tightest interval allowed +The libeufin-nexus component is responsible to query the fiat bank +via EBICS every X seconds. X should match the tightest interval allowed by the bank. -When libeufin-nexus registers an incoming payment on fiat-issuer in the -database, a SQL trigger applies the **current** cash-in rates/fees and -performs a wire transfer from regio-issuer to regio-exchange. Libeufin-bank -makes the exchange aware via the Taler Wire Gateway API and from now on, -the system proceeds like it always did in Taler. \ No newline at end of file +When libeufin-nexus registers an incoming payment on fiat-issuer in the +database, a SQL trigger applies the **current** cash-in rates/fees and +performs a wire transfer from regio-issuer to regio-exchange. Libeufin-bank +makes the exchange aware via the Taler Wire Gateway API and from now on, +the system proceeds like it always did in Taler. diff --git a/design-documents/044-ci-system.rst b/design-documents/044-ci-system.rst index cfb733aa..e38632c0 100644 --- a/design-documents/044-ci-system.rst +++ b/design-documents/044-ci-system.rst @@ -6,7 +6,7 @@ Summary This documents describes Taler's CI system based on Buildbot. -This document uses `RFC 2119 `_ +This document uses `RFC 2119 `_ keywords throughout. Motivation @@ -58,13 +58,13 @@ Example directory structure: └── 2-docs ├── docs.sh └── job.sh - -Job directories **MUST** follow this pattern: + +Job directories **MUST** follow this pattern: ``/contrib/ci/jobs//`` ``n`` is an integer used for ordering the build steps. -Job directories **MUST** contain a script named ``job.sh`` which **MAY** +Job directories **MUST** contain a script named ``job.sh`` which **MAY** execute other scripts. Config files may optionally be created, and MUST be named ``config.ini`` and @@ -84,7 +84,7 @@ Available config options: Unless *all* jobs specify a "CONTAINER_NAME" in their custom config a container file **MUST** be present at ``/contrib/ci/Containerfile``. -The container file will be built and used to run all of a repo's jobs +The container file will be built and used to run all of a repo's jobs by default. All projects SHOULD have a ``build`` step and a ``test`` step, at a minimum. @@ -95,8 +95,7 @@ Running CI Locally Running the CI scripts locally can be useful for development and testing. Included in each CI directory is a script which simplifies running jobs -in the same way the CI Worker does, in containers, using either `podman` -or `docker`, detecting if you have either installed. +in the same way the CI Worker does, in containers, using ``podman``. :: diff --git a/design-documents/054-dynamic-form.rst b/design-documents/054-dynamic-form.rst index 6a6d96af..6ff84d41 100644 --- a/design-documents/054-dynamic-form.rst +++ b/design-documents/054-dynamic-form.rst @@ -9,15 +9,15 @@ This document outlines the approach for implementing a dynamic web form feature. Motivation ========== -Currently, creating a new form for a web app involves coding a new -page with HTML, CSS, and JS. Exchange AML requires multiple forms, +Currently, creating a new form for a web app involves coding a new +page with HTML, CSS, and JS. Exchange AML requires multiple forms, and different instances may have distinct forms based on jurisdiction. Requirements ============ -A form consist of a layout and a set of fields. +A form consist of a layout and a set of fields. Layout requirements ------------------- @@ -28,8 +28,8 @@ Layout requirements * **accesibility**: Forms should meet accessibility level AA. * **responsive**: Forms should be responsive and function on all devices. - -* **metadata**: Generated form information should contain enough data + +* **metadata**: Generated form information should contain enough data to handle multiple form versions. Fields requirements @@ -37,17 +37,17 @@ Fields requirements * **validations**: Each field may require custom validation -* **custom data type**: A field may consist of a list, string, number, or a +* **custom data type**: A field may consist of a list, string, number, or a complex composite structure. Proposed Solutions ================== -Forms are initialized using a flexible structure defined by the -TypeScript interface FormType. This interface comprises properties -such as value (current form data), initial (initial form data for resetting), -readOnly (flag to disable input), onUpdate (callback on form data update), +Forms are initialized using a flexible structure defined by the +TypeScript interface FormType. This interface comprises properties +such as value (current form data), initial (initial form data for resetting), +readOnly (flag to disable input), onUpdate (callback on form data update), and computeFormState (function to derive the form state based on current data). @@ -80,15 +80,15 @@ Fields type can be: The field type ``AmountJson`` and ``AbsoluteTime`` are opaque since field is used as a whole. -The form can be instanciated using +The form can be instanciated using .. code-block:: javascript import { FormProvider } from "@gnu-taler/web-util/browser"; -Then the field component can access all the properties by the ``useField(name)`` hook, -which will return +Then the field component can access all the properties by the ``useField(name)`` hook, +which will return .. code-block:: javascript @@ -123,7 +123,7 @@ and should be used inside a ``Form`` context. - + } @@ -133,7 +133,7 @@ Example Consider a form shape represented by the TypeScript type: .. code-block:: javascript - + type TheFormType = { name: string, age: number, @@ -161,9 +161,9 @@ An example instance of this form could be: } -For such a form, a valid state can be computed using a function like -``computeFormStateBasedOnFormValues``, returning an object indicating -the state of each field, including properties such as ``hidden``, +For such a form, a valid state can be computed using a function like +``computeFormStateBasedOnFormValues``, returning an object indicating +the state of each field, including properties such as ``hidden``, ``disabled``, and ``required``. @@ -199,4 +199,3 @@ the state of each field, including properties such as ``hidden``, Q / A ===== - diff --git a/libeufin/regional-manual.rst b/libeufin/regional-manual.rst index 1ece9dda..0d09a150 100644 --- a/libeufin/regional-manual.rst +++ b/libeufin/regional-manual.rst @@ -11,7 +11,7 @@ how to set up one using GNU Taler and LibEuFin technology. How to create/destroy regional currency ======================================= - + In this model, the regional currency is backed by the fiat currency and users are offered two operations: *cash-in* to create regional currency starting from the fiat, and *cash-out* to destroy regional currency and obtain fiat currency back. @@ -58,7 +58,7 @@ Guided basic setup ================== Prerequisites -------------- ++++++++++++++ For this manual, we assume that the system is deployed on a contemporary Debian GNU/Linux or Ubuntu LTS system using the binary packages provided. @@ -72,7 +72,7 @@ in the ``regional-currency/`` folder. Obtaining the scripts ---------------------- ++++++++++++++++++++++ First, download the deployment scripts via Git: @@ -81,7 +81,7 @@ First, download the deployment scripts via Git: $ git clone git://git.taler.net/deployment Guided Configuration --------------------- +++++++++++++++++++++ This approach sets up a regional currency with cash-in/-out rates of 1:1. @@ -110,8 +110,8 @@ desired setup, in particular: like "uuidgen". * The DNS domain name of your setup (i.e: domain.tld). The installer will create by itself all the needed subdomains for your domain name, - as (``bank.$DOMAIN``, ``exchange.$DOMAIN`` and ``backend.$DOMAIN``). - But, these subdomain names, must have been added beforehand to your + as (``bank.$DOMAIN``, ``exchange.$DOMAIN`` and ``backend.$DOMAIN``). + But, these subdomain names, must have been added beforehand to your DNS domain control panel, and they must be pointing to the IP address of the system on which you are running the installation (before you execute the installer)). @@ -160,7 +160,7 @@ and fees may apply to these conversions. This section explains how to setup Lib Nexus to communicate with the fiat bank account that backs the regional currency. Prerequisites -------------- ++++++++++++++ You must have a bank account at a bank dealing in fiat currency that offers an online banking protocol supported by LibEuFin Nexus. As legacy transactions @@ -173,7 +173,7 @@ own dialects of finance messages and thus other retail banks may or may not work Contact us if you need support for another bank or core banking protocol. EBICS setup ------------ ++++++++++++ Follow the instructions from :ref:`EBICS subscriber setup ` to configure the LibEuFin Nexus for access to your fiat bank account, but do edit @@ -224,7 +224,7 @@ After providing the details and confirming, the shop is ready to generate orders and accept payments. Make an order -------------- ++++++++++++++ Click on ``Orders`` at the top left corner of the merchant backoffice page; the following page should appear @@ -243,7 +243,7 @@ to withdraw Taler coins and spend them to buy the order we just created. .. _withdraw-simulation: Pay for the order ------------------ ++++++++++++++++++ This section explains how to pay for the order in a scenario where the fiat bank is simulated. The simulation takes place by crafting ad-hoc XML files as if the @@ -338,18 +338,18 @@ should then be able to start a cash out operation. Enable regional currency conversion =================================== - + Prerequisites - ------------- - + +++++++++++++ + This step assumes that you already have a working regional currency bank and have successfully connected to a backing fiat bank account. - + Additionally, for each account that is allowed to convert regional currency into fiat, you must configure the (fiat) bank account number of the fiat currency with the respective account profile. Only the bank ``admin`` is allowed to set fiat bank account numbers. - + Furthermore, to achieve a reasonable security level, you must enable two factor authentication for "cash out" transactions. This requires you to configure an e-mail address or phone number for every account that supports @@ -357,85 +357,85 @@ should then be able to start a cash out operation. SMS. This manual does not cover setting up e-mail. For SMS delivery, you will need to obtain credentials from an SMS provider and provide a script to send messages via such a provider. - + Configuration - ------------- - + +++++++++++++ + You have to enable conversion and at least one TAN channel for cashout in the ``/etc/libeufin/libeufin-bank.conf`` configuration file: - + .. code-block:: console - + [libeufin-bank] ALLOW_CONVERSION = yes FIAT_CURRENCY = EUR - + TAN_SMS = libeufin-tan-sms.sh # And/Or TAN_EMAIL = libeufin-tan-email.sh - + Afterwards, restart the bank: - + .. code-block:: console - + # systemctl restart libeufin-bank - - + + The scripts TAN_SMS/EMAIL must accept the phone number / e-mail address as the ``$1`` parameter and the content in their standard input. The LibEuFin repository offers them in ``contrib/``: adjust to your setup! .. note:: - + the TAN_SMS script relies on a Telesign account. For this reason, it needs a telesign-secret file found in the PATH, that defines the environment variables API_KEY and CUSTOMER_ID - + Web-based Configuration - ----------------------- - + +++++++++++++++++++++++ + Now you should be able to setup conversion rates and ``admin`` debt limit though the Web interface of the bank as the ``admin`` user. - - + + Conversion ON! - -------------- - + ++++++++++++++ + The last step is to enable the Nexus services to import incoming bank transactions (cash in) and to trigger outgoing bank transactions (cash out): - + .. code-block:: console - + # systemd enable --now libeufin-nexus-ebics-fetch # systemd enable --now libeufin-nexus-ebics-submit - + Going live! =========== - + Exchange setup - -------------- - + ++++++++++++++ + First, you need to use the ``taler-exchange-offline`` tool to inform the exchange about the fiat bank account that can be used for cash in operations and also specify the URL for currency conversion. Additionally, you may also configure restrictions on the bank accounts that may originate the funds, for example to prevent international wire transfers that may expose you to additional compliance risks. - + Given the ``$IBAN`` of the fiat currency bank account and ``$NAME`` as the (URL-encoded) name of the exchange-account owner, the following ``taler-exchange-offline`` invocation can be used to inform wallets about the possibility of currency conversion (cash in) when wallets download ``/keys`` with bank account data from the exchange: - + .. code-block:: console - + # taler-exchange-offline \ enable-account \ payto://iban/$IBAN?receiver-name=$NAME \ conversion-url "$CONVERSION_URL" \ upload - + Here, the ``$CONVERSION_URL`` must be set to the base URL of the conversion endpoint of the bank, which should be ``https://bank.$DOMAIN/conversion-info/`` in our setup. diff --git a/manpages/taler-merchant-depositcheck.1 b/manpages/taler-merchant-depositcheck.1 new file mode 100644 index 00000000..d0af4cda --- /dev/null +++ b/manpages/taler-merchant-depositcheck.1 @@ -0,0 +1,72 @@ +taler-merchant-depositcheck(1) +############################## + +.. only:: html + + Name + ==== + + **taler-merchant-depositcheck** - check if deposits are associated with wire transfers + + +Synopsis +======== + +**taler-merchant-depositcheck** +[**-c** *FILENAME* | **--config=**\ ‌\ *FILENAME*] +[**-e** *BASE_URL* | **--exchange=**\ \ *BASE_URL*] +[**-h** | **--help**] +[**-L** *LOGLEVEL* | **--loglevel=**\ ‌\ *LOGLEVEL*] +[**-l** *FILENAME* | **--logfile=**\ ‌\ *FILENAME*] +[**-t** | **--test**] +[**-v** | **--version**] + +Description +=========== + +**taler-merchant-depositcheck** is a command-line tool to inquire with exchanges about whether they completed +bank transfers in response to deposits made by the +merchant backend. This will allow the merchant backend to detect deposit issues, for example if a KYC is blocking +a wire transfer. + +Its options are as follows: + +**-c** *FILENAME* \| **--config=**\ ‌\ *FILENAME* + Use the configuration and other resources for the merchant to operate + from *FILENAME*. + +**-e** *BASE_URL* \| **--exchange=**\ ‌\ *BASE_URL* + Base URL of the exchange to monitor. If not given, a worker process will be spawned for each exchange in the configuration ("merchant-exchange-" sections). + +**-h** \| **--help** + Print short help on options. + +**-L** *LOGLEVEL* \| **--loglevel=**\ ‌\ *LOGLEVEL* + Specifies the log level to use. Accepted values are: ``DEBUG``, ``INFO``, + ``WARNING``, ``ERROR``. + +**-l** *FILENAME* \| **--logfile=**\ ‌\ *FILENAME* + Send logging output to *FILENAME*. + +**-s** *SECTION* \| **--section=**\ \ *SECTION* + Configuration section to use. Default is taler-merchant-depositcheck. Needed + if different processes are used to watch multiple bank accounts (for the + same instance or different instances). + +**-t** \| **--test** + Run in test mode. Only runs until the current list of bank + transactions are all imported. + +**-v** \| **–version** + Print version information. + +See Also +======== + +taler-merchant-httpd(1), taler.conf(5). + +Bugs +==== + +Report bugs by using https://bugs.taler.net or by sending electronic +mail to . diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst index 680dd02c..9f9bf1f7 100644 --- a/taler-auditor-manual.rst +++ b/taler-auditor-manual.rst @@ -667,6 +667,7 @@ local tables: CONFIG = "postgres:///taler-ingress" .. code-block:: console + # As the 'ingress' user of the exchange: $ taler-exchange-dbinit -- cgit v1.2.3 From ba11950f168e73aab72e4ff61683688bfdd7eb7e Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Mon, 22 Jan 2024 21:35:24 +0100 Subject: DD35: management API --- design-documents/035-regional-currencies.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'design-documents') diff --git a/design-documents/035-regional-currencies.rst b/design-documents/035-regional-currencies.rst index 0b4553e6..8be7ea49 100644 --- a/design-documents/035-regional-currencies.rst +++ b/design-documents/035-regional-currencies.rst @@ -144,6 +144,16 @@ The last part should probably be hidden by default. There might be nicer ways t this, such as some hoverable (?) icon after the amount that shows details about what currencies the merchant accepts. +Wallet-core API for scope management +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ``listGlobalCurrencyExchanges`` lists all ``(currency, exchangeUrl, exchangePub)`` triples + where funds are considered to be in global scope (i.e. non-regional). +* ``listGlobalCurrencyAuditors`` lists all ``(currency, auditorUrl, auditorPub)`` triples + where funds are considered to be in global scope (i.e. non-regional). +* ``addGlobalCurrencyExchange`` and ``removeGlobalCurrencyExchange`` adds/removes a ``(currency, exchangeUrl, exchangePub)`` +* ``addGlobalCurrencyAuditor`` and ``removeGlobalCurrencyAuditor`` adds/removes a ``(currency, auditorUrl, auditorPub)`` + Implementation Breakdown ^^^^^^^^^^^^^^^^^^^^^^^^ -- cgit v1.2.3 From 968813951b4c10005f12ec15afafab97c0e8ee68 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Tue, 23 Jan 2024 21:55:12 +0100 Subject: dd39: document decision --- design-documents/039-taler-browser-integration.rst | 39 +++++++++++++++++----- 1 file changed, 30 insertions(+), 9 deletions(-) (limited to 'design-documents') diff --git a/design-documents/039-taler-browser-integration.rst b/design-documents/039-taler-browser-integration.rst index 71feb1c6..2ca24de4 100644 --- a/design-documents/039-taler-browser-integration.rst +++ b/design-documents/039-taler-browser-integration.rst @@ -81,11 +81,32 @@ Requirements should work smoothly with future browsers that have native, built-in support for Taler payments. +Proposed Solution +================= + +.. note:: + + As of 2023-01-23, we've decided to go ahead with the approach + described in this section. + +Now +^^^ + +* Handling ``taler://`` URIs by overriding the onclick handler of ``a`` HTML elements. + This requires excessive permissions but would be a viable work-around, + at least on pages that opt in with a special ```` tag. + It does not work in all use-cases, for example when a navigation + to a ``taler://`` URI is initiated programmatically or by pasting + the URI in the browser's address bar. + +* Handling a ``taler://`` URI by putting it directly in a meta tag that causes the + wallet to get triggered *on page load*. -Alternatives -============ -* JavaScript API: The WebExtension could inject a JavaScript API into Websites +Future (post-1.0) +^^^^^^^^^^^^^^^^^ + +* JavaScript API: The WebExtension can inject a JavaScript API into Websites that allow interacting with the Taler wallet. This is the approach taken by the MetaMask crypto wallet. It requires excessive permissions, may break some Websites (https://github.com/brave/browser-laptop/issues/13711) and @@ -100,12 +121,12 @@ Alternatives if the Website does not know the extension's ID. Hard-coding the extension IDs would violate the "no vendor lock-in requirement". -* Handling ``taler://`` URIs by overriding the onclick handler of ``a`` HTML elements. - This requires excessive permissions but would be a viable work-around, - at least on pages that opt in with a special ```` tag. - It does not work in all use-cases, for example when a navigation - to a ``taler://`` URI is initiated programmatically or by pasting - the URI in the browser's address bar. + + + +Other Alternatives +================== + * Triggering interactions with the ``taler://`` URI in a ``Taler:`` HTTP header. This approach would allow browsers with native Taler support -- cgit v1.2.3 From 4c60ed435413607769fe48115a7ab44335efb78b Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Tue, 23 Jan 2024 23:40:24 +0100 Subject: dd39: expand on proposed solution --- design-documents/039-taler-browser-integration.rst | 92 ++++++++++++++-------- 1 file changed, 61 insertions(+), 31 deletions(-) (limited to 'design-documents') diff --git a/design-documents/039-taler-browser-integration.rst b/design-documents/039-taler-browser-integration.rst index 2ca24de4..029ca6d4 100644 --- a/design-documents/039-taler-browser-integration.rst +++ b/design-documents/039-taler-browser-integration.rst @@ -89,38 +89,68 @@ Proposed Solution As of 2023-01-23, we've decided to go ahead with the approach described in this section. -Now -^^^ - -* Handling ``taler://`` URIs by overriding the onclick handler of ``a`` HTML elements. - This requires excessive permissions but would be a viable work-around, - at least on pages that opt in with a special ```` tag. - It does not work in all use-cases, for example when a navigation - to a ``taler://`` URI is initiated programmatically or by pasting - the URI in the browser's address bar. - -* Handling a ``taler://`` URI by putting it directly in a meta tag that causes the - wallet to get triggered *on page load*. - - -Future (post-1.0) -^^^^^^^^^^^^^^^^^ - -* JavaScript API: The WebExtension can inject a JavaScript API into Websites - that allow interacting with the Taler wallet. This is the approach taken by - the MetaMask crypto wallet. It requires excessive permissions, may break - some Websites (https://github.com/brave/browser-laptop/issues/13711) and - requires merchants to include extra JavaScript. - - * This type of interaction is useful for Single Page Apps and - might be provided by the GNU Taler wallet reference implementation, - at least when the user grants additional permissions. - * Unfortunately, browsers currently do not provide a safe way - for the communication between a WebExtension and the page - without excessive permissions. This especially applies - if the Website does not know the extension's ID. Hard-coding - the extension IDs would violate the "no vendor lock-in requirement". +Overview +^^^^^^^^ +The following integration approaches between Websites and the Taler Wallet webextension +are provided: + +1. Directly triggering a ``taler://...`` URI on page load (via a meta tag). +2. Overriding ```` tags to trigger the wallet. + The onclick handler (which must call preventDefault) can implement behavior + that happens only when the webextension is not available. +3. Future (possibly post-1.0): A ``window.taler`` JavaScript API that is injected + into every page that requests it via a meta tag. This is useful for SPAs that + want to programmatically trigger the Taler wallet. + + +Usage +^^^^^ + +To directly trigger the handling of a ``taler://`` URI on page load, the following meta tag can be used: + +.. code:: + + + + +To enable additional communication features between a website and the GNU Taler Wallet webextension, the page must +include the following meta tag: + +.. code:: + + + +where ``$features`` is a comma-separated list of features. + +The following features are supported: + +* ``uri`` will hijack anchor elements (````) and replace their onclick handler + with a different handler that lets the webexension wallet handle the ``taler://`` URI. +* (future): ``api`` will inject the ``window.taler`` API into the page + + +Caveats and Comments +^^^^^^^^^^^^^^^^^^^^ + +* Anchor tag hijacking does not work in all use-cases, for example when a navigation +to a ``taler://`` URI is initiated programmatically or by pasting +the URI in the browser's address bar. + +* The ``window.taler`` API injection may break some websites + (https://github.com/brave/browser-laptop/issues/13711). + +* All these approaches require excessive permissions, as unfortunately, + browsers currently do not provide a safe way for the communication between a + WebExtension and the page without excessive permissions. This especially + applies if the Website does not know the extension's ID. Hard-coding the + extension IDs would violate the "no vendor lock-in requirement". + +* A neat feature of the anchor hijacking is that the ``taler://`` URI can be always be copied + in the browser (via "copy link address"). Clicking the link always results in either: + * The native URI handler, if no Taler Wallet webextension is installed and no onclick handler is defined + * The execution of the websites onclick handler if no Taler Wallet webextension is installed + * Triggering the webextension wallet to handle the ``taler://`` URI. -- cgit v1.2.3 From 905ffc59c7d0b70cfab7cc829bd843df680d854a Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Wed, 24 Jan 2024 15:07:16 +0100 Subject: dd39: remove confusing example/suggestion --- design-documents/039-taler-browser-integration.rst | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) (limited to 'design-documents') diff --git a/design-documents/039-taler-browser-integration.rst b/design-documents/039-taler-browser-integration.rst index 029ca6d4..e34a8d00 100644 --- a/design-documents/039-taler-browser-integration.rst +++ b/design-documents/039-taler-browser-integration.rst @@ -54,13 +54,7 @@ The problems with individual browsers are: either. Another issue is that Websites can't easily find out whether a browser -extension handling the ``taler://`` protocol is installed. To avoid using this -information for fingerprinting, anchors could provide an alternative ``href`` -in case the main one is not handled, such as: - -.. code:: html - - ... +extension handling the ``taler://`` protocol is installed. Requirements ============ @@ -184,6 +178,10 @@ Other Alternatives the Web Payments API would not support the withdrawal flow (``taler://withdraw`` URIs). +* Browsers could provide anchor elements with a fallback when the protocol isn't supported, such as + ``...``. + + Related Work and References =========================== -- cgit v1.2.3 From 4362ba6cc4044b22ff53f1a63611b6c42b55209f Mon Sep 17 00:00:00 2001 From: Sebastian Date: Wed, 24 Jan 2024 11:20:55 -0300 Subject: comment on window.taler injection --- design-documents/039-taler-browser-integration.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'design-documents') diff --git a/design-documents/039-taler-browser-integration.rst b/design-documents/039-taler-browser-integration.rst index e34a8d00..b7cd346c 100644 --- a/design-documents/039-taler-browser-integration.rst +++ b/design-documents/039-taler-browser-integration.rst @@ -121,6 +121,7 @@ The following features are supported: * ``uri`` will hijack anchor elements (````) and replace their onclick handler with a different handler that lets the webexension wallet handle the ``taler://`` URI. + * (future): ``api`` will inject the ``window.taler`` API into the page @@ -142,11 +143,14 @@ the URI in the browser's address bar. * A neat feature of the anchor hijacking is that the ``taler://`` URI can be always be copied in the browser (via "copy link address"). Clicking the link always results in either: + * The native URI handler, if no Taler Wallet webextension is installed and no onclick handler is defined * The execution of the websites onclick handler if no Taler Wallet webextension is installed * Triggering the webextension wallet to handle the ``taler://`` URI. - +* Future ``window.taler`` injection should be based on user preferences on + sites where the user has explicitly accepted to disclose that is owner of a + Taler wallet. Other Alternatives ================== -- cgit v1.2.3 From 60b071096b1b26da6b2aa5810ae906a27467bcce Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Wed, 31 Jan 2024 21:16:08 +0100 Subject: major updates to taler-merchant-manual --- design-documents/039-taler-browser-integration.rst | 10 +- libeufin/bank-manual.rst | 21 ++ libeufin/index.rst | 20 ++ libeufin/nexus-manual.rst | 21 ++ libeufin/regional-manual.rst | 35 ++- taler-merchant-manual.rst | 245 ++++++++++----------- taler-merchant-pos-terminal.rst | 6 +- taler-wallet.rst | 42 ++++ 8 files changed, 257 insertions(+), 143 deletions(-) (limited to 'design-documents') diff --git a/design-documents/039-taler-browser-integration.rst b/design-documents/039-taler-browser-integration.rst index b7cd346c..980f3f25 100644 --- a/design-documents/039-taler-browser-integration.rst +++ b/design-documents/039-taler-browser-integration.rst @@ -112,7 +112,7 @@ To enable additional communication features between a website and the GNU Taler include the following meta tag: .. code:: - + where ``$features`` is a comma-separated list of features. @@ -129,8 +129,8 @@ Caveats and Comments ^^^^^^^^^^^^^^^^^^^^ * Anchor tag hijacking does not work in all use-cases, for example when a navigation -to a ``taler://`` URI is initiated programmatically or by pasting -the URI in the browser's address bar. + to a ``taler://`` URI is initiated programmatically or by pasting + the URI in the browser's address bar. * The ``window.taler`` API injection may break some websites (https://github.com/brave/browser-laptop/issues/13711). @@ -148,8 +148,8 @@ the URI in the browser's address bar. * The execution of the websites onclick handler if no Taler Wallet webextension is installed * Triggering the webextension wallet to handle the ``taler://`` URI. -* Future ``window.taler`` injection should be based on user preferences on - sites where the user has explicitly accepted to disclose that is owner of a +* Future ``window.taler`` injection should be based on user preferences on + sites where the user has explicitly accepted to disclose that is owner of a Taler wallet. Other Alternatives diff --git a/libeufin/bank-manual.rst b/libeufin/bank-manual.rst index af977492..a61c7429 100644 --- a/libeufin/bank-manual.rst +++ b/libeufin/bank-manual.rst @@ -1,5 +1,26 @@ +.. + This file is part of GNU TALER. + Copyright (C) 2014-2023 Taler Systems SA + + TALER is free software; you can redistribute it and/or modify it under the + terms of the GNU Affero General Public License as published by the Free Software + Foundation; either version 2.1, or (at your option) any later version. + + TALER is distributed in the hope that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR + A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License along with + TALER; see the file COPYING. If not, see + + @author Florian Dold + @author Marcello Stanisci + @author Christian Grothoff + .. target audience: operator, developer +.. _libeufin-bank: + Bank Setup Manual ################# diff --git a/libeufin/index.rst b/libeufin/index.rst index 042388dc..5e4ca054 100644 --- a/libeufin/index.rst +++ b/libeufin/index.rst @@ -1,3 +1,23 @@ +.. + This file is part of GNU TALER. + Copyright (C) 2014-2023 Taler Systems SA + + TALER is free software; you can redistribute it and/or modify it under the + terms of the GNU Affero General Public License as published by the Free Software + Foundation; either version 2.1, or (at your option) any later version. + + TALER is distributed in the hope that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR + A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License along with + TALER; see the file COPYING. If not, see + + @author Florian Dold + @author Marcello Stanisci + @author Christian Grothoff + + LibEuFin ######## diff --git a/libeufin/nexus-manual.rst b/libeufin/nexus-manual.rst index 0fab068b..c4ed2cbc 100644 --- a/libeufin/nexus-manual.rst +++ b/libeufin/nexus-manual.rst @@ -1,5 +1,26 @@ +.. + This file is part of GNU TALER. + Copyright (C) 2014-2023 Taler Systems SA + + TALER is free software; you can redistribute it and/or modify it under the + terms of the GNU Affero General Public License as published by the Free Software + Foundation; either version 2.1, or (at your option) any later version. + + TALER is distributed in the hope that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR + A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License along with + TALER; see the file COPYING. If not, see + + @author Florian Dold + @author Marcello Stanisci + @author Christian Grothoff + .. target audience: operator, developer +.. _libeufin-nexus: + Nexus Manual ############ diff --git a/libeufin/regional-manual.rst b/libeufin/regional-manual.rst index 441f6599..ca355a49 100644 --- a/libeufin/regional-manual.rst +++ b/libeufin/regional-manual.rst @@ -1,3 +1,23 @@ +.. + This file is part of GNU TALER. + Copyright (C) 2014-2023 Taler Systems SA + + TALER is free software; you can redistribute it and/or modify it under the + terms of the GNU Affero General Public License as published by the Free Software + Foundation; either version 2.1, or (at your option) any later version. + + TALER is distributed in the hope that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR + A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License along with + TALER; see the file COPYING. If not, see + + @author Florian Dold + @author Marcello Stanisci + @author Christian Grothoff + + .. target audience: operator Regional Currency Setup Manual @@ -116,9 +136,10 @@ desired setup, in particular: IP address of the system on which you are running the installation (before you execute the installer)). -The information you entered as well as the generated bank admin password will be stored in a file called ``config/user.conf``. -Should you run the script in the future (for example, to upgrade the installation), -you will not be asked these questions a second time. +The information you entered as well as the generated bank admin password will +be stored in a file called ``config/user.conf``. Should you run the script in +the future (for example, to upgrade the installation), you will not be asked +these questions a second time. After answering all of the questions, the actual installation will start. The scripts will download and configure various packages, which may take some time. @@ -167,14 +188,14 @@ Enable regional currency conversion =================================== Prerequisites -------------- ++++++++++++++ This step assumes that you already have a working regional currency bank and have successfully connected to a backing fiat bank account. Follow the instructions from :ref:`EBICS setup `. Configuration -------------- ++++++++++++++ Then you have to enable conversion and at least one TAN channel for cashout in the configuration file. @@ -204,13 +225,13 @@ Then the following command would start the server with conversion API enabled : libeufin-bank serve -c $config_file Web-based Configuration ------------------------ ++++++++++++++++++++++++ Now you should be able to setup conversion rates and ``admin`` debt limit though the Web interface of the bank as the ``admin`` user. Conversion ON! --------------- +++++++++++++++ The last step is to run Nexus to import incoming bank transactions (cash in) and to trigger outgoing bank transactions (cash out). diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst index 072f4ad7..dcf518e7 100644 --- a/taler-merchant-manual.rst +++ b/taler-merchant-manual.rst @@ -396,6 +396,28 @@ This chapter describes how to install the GNU Taler merchant backend. .. _Generic-instructions: +Installing the GNU Taler binary packages on Debian +-------------------------------------------------- + +.. include:: frags/installing-debian.rst + +.. include:: frags/apt-install-taler-merchant.rst + + +Installing the GNU Taler binary packages on Trisquel +---------------------------------------------------- + +.. include:: frags/installing-trisquel.rst + + +Installing the GNU Taler binary packages on Ubuntu +-------------------------------------------------- + +.. include:: frags/installing-ubuntu.rst + +.. include:: frags/apt-install-taler-merchant.rst + + Installing from source ---------------------- @@ -433,30 +455,9 @@ libraries! .. include:: frags/install-before-check.rst -Installing the GNU Taler binary packages on Debian --------------------------------------------------- - -.. include:: frags/installing-debian.rst - -.. include:: frags/apt-install-taler-merchant.rst - - -Installing the GNU Taler binary packages on Trisquel ----------------------------------------------------- - -.. include:: frags/installing-trisquel.rst - -Installing the GNU Taler binary packages on Ubuntu --------------------------------------------------- - -.. include:: frags/installing-ubuntu.rst - -.. include:: frags/apt-install-taler-merchant.rst - - -How to configure the merchant’s backend -======================================= +How to configure the merchant backend +===================================== .. index:: taler.conf @@ -747,7 +748,7 @@ Launching the backend .. index:: taler-merchant-httpd Assuming you have configured everything correctly, you can launch the -merchant backend as ``$USER`` using +merchant backend as ``$USER`` using (to provide a trivial example): .. code-block:: console @@ -757,12 +758,7 @@ merchant backend as ``$USER`` using $ taler-merchant-depositcheck & $ taler-merchant-exchange & -You only need to run ``taler-merchant-webhook`` if one of the instances is -configured to trigger web hooks. Similarly, ``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 +To ensure these processes run 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 @@ -782,7 +778,6 @@ how to start and stop daemons. should be able to visit the merchant backend at the respective HTTP(S) endpoint. - If everything worked as expected, the command .. code-block:: console @@ -794,7 +789,7 @@ should return some basic configuration status data about the service. Please note that your backend might then be globally reachable without any access control. You can either: - * Use the ``--auth=$TOKEN`` command-line option to set an access token to be provided in an ``Authorize: Bearer $TOKEN`` HTTP header. Note that this can be used at anytime to override access control, but remains only in effect until a first instance is created or an existing instance authentication setting is modified. + * Use the ``--auth=$TOKEN`` command-line option to **taler-merchant-httpd** to set an access token to be provided in an ``Authorize: Bearer $TOKEN`` HTTP header. Note that this can be used at anytime to override access control, but remains only in effect until a first instance is created or an existing instance authentication setting is modified. * Set the ``TALER_MERCHANT_TOKEN`` environment variable to ``$TOKEN`` for the same effect. This method has the advantage of ``$TOKEN`` not being visible as a command-line interface to other local users on the same machine. * Set up an instance with an authentication token before some unauthorized person has a chance to access the backend. As the backend is useless without any instance and the chances of remote attackers during the initial configuration is low, this is probably sufficient for most use-cases. Still, keep the first two scenarios in mind in case you ever forget your access token! @@ -809,15 +804,14 @@ and use TLS for improved network privacy, see :ref:`Secure setup ` Instance setup ============== -First of all, we recommend the use of the single-page administration -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 ``wget`` commands given -below. +We recommend the use of the single-page administration 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. Alternatively, you can also use the ``wget`` commands given below. -Regardless of which tool you use, the first step for using the backend +Regardless of which approach you use, the first step for using the backend involves the creation of a ``default`` instance. The ``default`` instance can -also create / delete / configure other instances, similar to the ``root`` +also create, configure or delete other instances, similar to the ``root`` account on UNIX. When no instance exists and ``taler-merchant-httpd`` was started without the ``--auth`` option, then the backend is reachable without any access control (unless you configured some in the reverse proxy). @@ -836,36 +830,29 @@ times, once for each instance. :ref:`reverse proxy `. - Instance setup with the SPA --------------------------- -In order to setup a shop, you need a merchant backend to run. The guided -setup installs and sets one backend up, but the user is required to complete -the shop configuration via the Web browser. - -One fundamental piece of information are the banking details, to allow merchant -receive payments from the exchange. If you don't have a bank account at the regional -bank, contact the administrator and get one. After being able to login to the new -bank account, you can see your IBAN by clicking on the ``Welcome, $USERNAME`` message -in the profile page. The IBAN is shown under the ``Internal IBAN`` box. +In order to setup an instance, you need the merchant backend to already be +running, and you must either have the credentials for the "default" instance, +or no instance must be configured at all yet. -Next, point your browser to ``$proto://backend.$domain_name/``. You should -be welcomed by the following merchant backoffice page: +To start, point your browser to ``$PROTO://backend.$DOMAIN_NAME/``, replacing +"$PROTO" with "https" or (rarely) "http" and "$DOMAIN_NAME" with your +organizations DNS domain or subdomain. -.. image:: screenshots/merchant_first_login.png +.. note:: -Such page offers to create a merchant profile: fill any required field (including -your access token) and click to ``confirm``. It should now be possible to associate -the banking details to the profile just created: click to ``Bank account`` at the -left of the page. The following page should be shown: + The label "backend" here is also just a suggestion, your administrator + can in principle choose any name. -.. image:: screenshots/no_default_account_yet.png +You should be welcomed by the following merchant backoffice page: -Click on the blue "+" sign on the top right of the page, and expect the following -page to appear: +.. image:: screenshots/merchant_first_login.png -.. image:: enter_instance_details.png +After supplying the required fields, primarily the name of your organization +and the desired access token, click ``confirm``. You can change the instance +settings later via the ``Settings`` entry in the menu on the left. Instance setup without the Web interface @@ -912,6 +899,7 @@ Endpoints to modify (reconfigure), permanently disable (while keeping the data) or purge (deleting all associated data) instances exist as well and are documented in the :ref:`Merchant Backend API documentation `. +.. _instance-account-setup: Instance account setup ====================== @@ -922,29 +910,48 @@ operator to tell it where to wire the income from your sales. Every bank account has an associated *wire method* which determines how an exchange can transfer the funds. The most commonly supported wire method is *iban*, which implies that bank accounts are identified by IBAN numbers and wire transfers -are to be executed between IBAN accounts. +are to be executed between IBAN accounts. For regional currency setups, the +wire method could also be *x-taler-bank*. + +.. note:: + + When using a regional currency, you need to first create a bank account at + the regional bank. You may need to contact the respective administrator who + can set one up. After being able to login to the new bank account, you can + see your bank account number by clicking on the ``Welcome, $USERNAME`` + message in the profile page. Next to the bank account number, you can find + a convenient button to copy the number to the clipboard. Not every exchange will support every *wire method*, and if you do not add a bank account with a wire method that is supported by a particular exchange, then you will not be able to receive payments via that exchange even if you configured the merchant backend to trust that exchange. -The simplest way to configure an account is to use the Web interface which -has specific forms for different wire methods. Specifying the revenue gateway -with username and password is optional and discussed below. +The simplest way to configure an account is to use the Web interface which has +specific forms for different wire methods. First, select ``Bank account`` at +the left of the page. The following page should be shown: + +.. image:: screenshots/no_default_account_yet.png + +Click on the blue "+" sign on the top right of the page to add a new +bank account. The following page should appear: -This tutorial is focused on IBAN, so choose ``iban`` as the account type, and -expect the following page to appear: +.. image:: screenshots/enter_instance_details.png + +First, you should select the wire method, after which the dialog will show you +additional fields specific to the wire method. For example, if youchoose +``iban`` as the account type, the following page should appear: .. image:: screenshots/instance_iban_config.png +Specifying the revenue gateway with username and password is optional and +discussed in section :ref:`automatic-settlement-data-import` below. + After providing the details and confirming, the shop is ready to generate orders and accept payments. - - Detecting Settlement: Manually Adding Transfers ----------------------------------------------- @@ -962,75 +969,54 @@ information, the merchant backend will inquire with the exchange which individual payments were aggregated, check that the total amount is correct, and will then flag the respective contracts as wired. +You can manually enter wire transfers under ``Transfers``. However, this is +tedious, and so if your banking setup supports it, we highly recommend +using the automatic settlement data import. + +.. _automatic-settlement-data-import: + Automatic Settlement Data Import -------------------------------- -To automatically import settlement data, you can provide the merchant backend -with the address and access credentials of a Taler revenue API for each bank -account of an instance. The revenue API endpoint will allow the merchant -backend to observe all incoming wire transfers into your bank account and -automatically import them into the list of wire transfers. +To automatically import settlement data, you need to provide the merchant +backend with the address and access credentials of a +:ref:`taler-bank-merchant-http-api` for each bank account of an instance. The +revenue API endpoint will allow the merchant backend to obtain a list of all +incoming wire transfers into your bank account and automatically import them +into the list of confirmed wire transfers. Note that setting up a revenue API endpoint will usually require you to first -ask your bank for EBICS access and to setup libeufin to provide the revenue -API endpoint. The taler-bank used by regional currency setups also provides -a revenue API endpoint at ``$BANK_URL/accounts/$ACCOUNT_NAME/taler-revenue/``. +ask your bank for EBICS access and to set up :ref:`libeufin-nexus` to provide +the revenue API endpoint. The :ref:`libeufin-bank` used by regional currency +setups also provides a revenue API endpoint at +``$BANK_URL/accounts/$ACCOUNT_NAME/taler-revenue/``. Thus, when using a +regional currency setup, simply use the ``$BANK_URL`` of your bank and specify +your bank login name and password in the :ref:`instance-account-setup` dialog. -Make an order -============= +Manually creating an order using the SPA +======================================== Click on ``Orders`` at the top left corner of the merchant backoffice page; the following page should appear .. image:: screenshots/create_orders.png -After having filled the required fields, the interface should show the following -page with the related links to check the status of the order and let wallets pay -for it. Take note of the link beside ``Payment URI`` (we'll call it ``$payUri``). +After having filled the required fields, the interface should show the +following page with the related links to check the status of the order and let +wallets pay for it. .. image:: screenshots/payment_links.png In order to test the setup, it should be now possible to use the command line wallet -to withdraw Taler coins and spend them to buy the order we just created. - - -.. _withdraw-simulation: - -Pay for the order -================= - -This section explains how to pay for the order in a scenario where the fiat bank -is simulated. The simulation takes place by crafting ad-hoc XML files as if the -bank would have issued them. Such XML files carry information about incoming payments -to the regional currency master bank account. Finally, the XML files are passed -to LibEuFin nexus via a convenient CLI method. The responsible script for such -simulation is ``withdraw.sh``. - -Run ``./withdraw.sh`` without any arguments. Assuming that you ran the command -as the ``test-user``, after the execution, 5 units of the regional currency should -be found in the CLI wallet owned by ``test-user``. - - -Check it with: - -.. code-block:: console - - $ taler-wallet-cli balance - -If so, call the wallet in the following way to finally pay for the order just created: - -.. code-block:: console - - $ taler-wallet-cli handle-uri $TALER_PAY_URI - -.. note:: - - Reset the state before going to production, as it impacts the way nexus - asks records to the bank. In particular, delete: any database and the - files ``config/user.conf`` and ``config/internal.conf``, and finally run - ``./main.sh`` again. +to withdraw Taler coins and spend them to pay for the order we just created. +In practice, you will rarely if ever setup orders manually like this. Instead, +a `GNU Taler e-commerce front-end +`_ or the +:ref:`taler-merchant-pos-app` will do this on-demand. Here, you will only need +to provide the respective front-ends with the URL of your instance +(e.g. ``https://backend.$DOMAIN/instances/$NAME``) and your access token. .. _Secure-setup: @@ -1041,11 +1027,12 @@ Secure setup .. index:: security .. index:: TLS -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. +The Taler backend is deliberately simple in terms of support for access +control or transport layer security (TLS). 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. + Using UNIX domain sockets ------------------------- @@ -1305,6 +1292,7 @@ runtime by the setup logic provided by ``taler-unified-setup.sh``. See :ref:`Taler Exchange Manual ` for how to use ``taler-unified-setup.sh`` to setup the system and in particular on how to specify the bank to be used. + Running taler-merchant-benchmark ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -1341,8 +1329,10 @@ second gives the chance to leave some payments unaggregated, and also to use merchant instances other than the default (which is, actually, the one used by default by the tool). -Note: the ability of driving the aggregation policy is useful for testing -the back-office facility. +.. note:: + + The ability to drive the aggregation policy is useful for testing + the back-office facility. Any subcommand is also equipped with the canonical ``--help`` option, so feel free to issue the following command in order to explore all the @@ -1369,9 +1359,6 @@ option: - - - Temporarily Abandoned Features ============================== diff --git a/taler-merchant-pos-terminal.rst b/taler-merchant-pos-terminal.rst index b5833369..0cca1d52 100644 --- a/taler-merchant-pos-terminal.rst +++ b/taler-merchant-pos-terminal.rst @@ -15,8 +15,10 @@ @author Torsten Grote -GNU Taler Merchant POS Manual -############################# +.. _taler-merchant-pos-app: + +GNU Taler Merchant POS App +########################## The GNU Taler merchant POS (point of sale) terminal allows sellers to diff --git a/taler-wallet.rst b/taler-wallet.rst index 04a77e7d..3ea1dbea 100644 --- a/taler-wallet.rst +++ b/taler-wallet.rst @@ -207,6 +207,48 @@ is functional: # The "deposit group id" can be found in the output of the transactions list. $ taler-wallet-cli deposit track $DEPOSIT_GROUP_ID +.. _withdraw-simulation: + + +Paying for an order +=================== + +.. note:: + + This section is in dire need for some editing... + +This section explains how to pay for an order in a scenario where the fiat bank +is simulated. The simulation takes place by crafting ad-hoc XML files as if the +bank would have issued them. Such XML files carry information about incoming payments +to the regional currency master bank account. Finally, the XML files are passed +to LibEuFin nexus via a convenient CLI method. The responsible script for such +simulation is ``withdraw.sh``. + +Run ``./withdraw.sh`` without any arguments. Assuming that you ran the command +as the ``test-user``, after the execution, 5 units of the regional currency should +be found in the CLI wallet owned by ``test-user``. + + +Check it with: + +.. code-block:: console + + $ taler-wallet-cli balance + +If so, call the wallet in the following way to finally pay for the order just created: + +.. code-block:: console + + $ taler-wallet-cli handle-uri "$TALER_PAY_URI" + +.. note:: + + Reset the state before going to production, as it impacts the way nexus + asks records to the bank. In particular, delete: any database and the + files ``config/user.conf`` and ``config/internal.conf``, and finally run + ``./main.sh`` again. + + -- cgit v1.2.3 From c0e5be74b8cfbc6978c6b1fa1c7f6c6128fcde3b Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sat, 3 Feb 2024 21:10:43 +0100 Subject: fix contract terms link --- design-documents/024-age-restriction.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'design-documents') diff --git a/design-documents/024-age-restriction.rst b/design-documents/024-age-restriction.rst index 280a4f39..ee478ee1 100644 --- a/design-documents/024-age-restriction.rst +++ b/design-documents/024-age-restriction.rst @@ -600,9 +600,9 @@ The object ``ContractTerms`` is extended by an optional field ``minimum_age`` that can be any integer greater than 0. In reality this value will not be smaller than, say, 8, and not larger than, say, 21. -.. ts:def:: ContractTerms +.. ts:def:: DD24ContractTerms - interface ContractTerms { + interface DD24ContractTerms { ... // If the order requires a minimum age greater than 0, this field is set -- cgit v1.2.3 From 9aeb3617a2ea3b649c79432718aa884ba29fd4d9 Mon Sep 17 00:00:00 2001 From: Sebastian Date: Tue, 6 Feb 2024 18:30:15 -0300 Subject: clarify some requirements for merchant and wallet integration --- design-documents/035-regional-currencies.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'design-documents') diff --git a/design-documents/035-regional-currencies.rst b/design-documents/035-regional-currencies.rst index 8be7ea49..3d62dcc3 100644 --- a/design-documents/035-regional-currencies.rst +++ b/design-documents/035-regional-currencies.rst @@ -30,6 +30,11 @@ Requirements * Regional currencies should be easy to use as well * It must be easy to integrate regional/official currencies with the existing Taler auditor/exchange structure +* Wallet users should be able to see disagregated balance between global currencies + and regional currencies supported by different exchanges even if the currency + name is equal. +* Merchants should be able to accept regional and global currencies based on the + supported exchange list. Proposed Solution ================= -- cgit v1.2.3 From 7d63c95d0f779a2ade14896af9d4b304e038f826 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Thu, 8 Feb 2024 16:51:24 +0100 Subject: remove reward-related APIs and design considerations --- checklist-demo-upgrade.rst | 10 - core/api-exchange.rst | 17 +- core/api-merchant.rst | 541 +-------------------- design-documents/014-merchant-backoffice-ui.rst | 8 - .../020-backoffice-rewards-management.rst | 2 +- design-documents/023-taler-kyc.rst | 2 +- design-documents/031-invoicing.rst | 15 +- .../037-wallet-transactions-lifecycle.rst | 58 --- .../041-wallet-balance-amount-definitions.rst | 14 - design-documents/053-wallet-ui.rst | 57 +-- images/Makefile | 4 +- images/transaction-reward-states.dot | 11 - manpages/taler-wallet-cli.1.rst | 2 - manpages/taler.conf.5.rst | 7 - orphaned/taler-nfc-guide.rst | 4 +- taler-developer-manual.rst | 3 +- taler-exchange-manual.rst | 2 +- taler-merchant-api-tutorial.rst | 67 --- taler-merchant-manual.rst | 44 -- taler-wallet.rst | 1 - 20 files changed, 40 insertions(+), 829 deletions(-) delete mode 100644 images/transaction-reward-states.dot (limited to 'design-documents') diff --git a/checklist-demo-upgrade.rst b/checklist-demo-upgrade.rst index c45c1847..d8724030 100644 --- a/checklist-demo-upgrade.rst +++ b/checklist-demo-upgrade.rst @@ -136,7 +136,6 @@ Merchant SPA - |democheck| edit template to add TOTP device, set price to fixed, summary to be entered - |democheck| scan template QR code, edit summary and pay - |democheck| check displayed TOTP code matches TOTP app -- |democheck| create reserve for rewards - |democheck| do manual wire transfer in bank to establish reserve funding - |democheck| check that partially refunded order is marked as awaiting wire transfer - |democheck| check bank wired funds to merchant (if needed, wait) @@ -148,14 +147,6 @@ Merchant SPA - |democheck| check that orders are marked as completed -Survey/Rewards -^^^^^^^^^^^^^^ - -- |democheck| Visit https://survey.demo.taler.net/ and receive a reward. -- |democheck| Verify that the survey stats page (https://survey.demo.taler.net/survey-stats) is working, - and that the survey reserve has sufficient funds. - - P2P payments ^^^^^^^^^^^^ @@ -180,4 +171,3 @@ Shutdown - |democheck| enter bank account (if possible) - |democheck| wallet balance goes to zero - |democheck| specified bank account receives remaining balance - diff --git a/core/api-exchange.rst b/core/api-exchange.rst index 0e79ae6b..f7d63d0e 100644 --- a/core/api-exchange.rst +++ b/core/api-exchange.rst @@ -198,7 +198,8 @@ possibly by using HTTPS. // Set to true if this exchange allows the use // of reserves for rewards. - rewards_allowed: boolean; + // @deprecated in protocol v18. + rewards_allowed: false; // EdDSA master public key of the exchange, used to sign entries // in ``denoms`` and ``signkeys``. @@ -5071,12 +5072,12 @@ Reserve control --------------- This section describes the reserve control API which can be used to (1) -prevent a reserve from expiring (which is useful if the reserve is used for -rewards), to (2) pay an annual fee to allow a number of purses to be created -for the respective reserve without paying a purse fee each time, to (3) obtain -KYC information associated with a reserve to prove the identity of the person -sending an invoice to the payer, and to (4) close a reserve before it would -naturally expire and possibly (5) wire the funds to a designated account. +prevent a reserve from expiring, to (2) pay an annual fee to allow a number of +purses to be created for the respective reserve without paying a purse fee +each time, to (3) obtain KYC information associated with a reserve to prove +the identity of the person sending an invoice to the payer, and to (4) close a +reserve before it would naturally expire and possibly (5) wire the funds to a +designated account. .. note:: @@ -5084,7 +5085,7 @@ naturally expire and possibly (5) wire the funds to a designated account. .. http:post:: /reserves/$RESERVE_PUB/open - Request keeping a reserve open for rewards or invoicing. + Request keeping a reserve open for invoicing. **Request:** diff --git a/core/api-merchant.rst b/core/api-merchant.rst index 652c7303..46392118 100644 --- a/core/api-merchant.rst +++ b/core/api-merchant.rst @@ -199,8 +199,7 @@ This section describes (public) endpoints that wallets must be able to interact with directly (without HTTP-based authentication). These endpoints are used to process payments (claiming an order, paying for the order, checking payment/refund status and aborting payments), -process refunds (checking refund status, obtaining the refund), -and to pick up rewards. +and to process refunds (checking refund status, obtaining the refund). Claiming an order @@ -837,111 +836,6 @@ the contract. Refunds must be approved by the merchant's business logic. } -Picking up rewards ------------------- - -Rewards are a way for wallets to obtain e-cash from -a website. - -.. http:get:: [/instances/$INSTANCE]/rewards/$REWARD_ID - - Handle request from wallet to provide details about a reward. - - This endpoint typically also supports requests with the "Accept" header - requesting "text/html". In this case, an HTML response suitable for - triggering the interaction with the wallet is returned. If the backend - installation does not include the required HTML templates, a 406 status - code is returned. - - **Response:** - - :http:statuscode:`200 OK`: - A reward is being returned. The backend responds with a `RewardInformation`. - :http:statuscode:`404 Not found`: - The reward identifier is unknown. - :http:statuscode:`406 Not acceptable`: - The merchant backend could not load the template required to generate a reply in the desired format. (Likely HTML templates were not properly installed.) - :http:statuscode:`410 Gone`: - A reward has been fully claimed. The JSON reply still contains the `RewardInformation`. - - .. ts:def:: RewardInformation - - interface RewardInformation { - - // Exchange from which the reward will be withdrawn. Needed by the - // wallet to determine denominations, fees, etc. - exchange_url: string; - - // URL where to go after obtaining the reward. - next_url: string; - - // (Remaining) amount of the reward (including fees). - reward_amount: Amount; - - // Timestamp indicating when the reward is set to expire (may be in the past). - // Note that rewards that have expired MAY also result in a 404 response. - expiration: Timestamp; - } - - -.. http:post:: [/instances/$INSTANCE]/rewards/$REWARD_ID/pickup - - Handle request from wallet to pick up a reward. - - **Request:** - - The request body is a `RewardPickupRequest` object. - - **Response:** - - :http:statuscode:`200 OK`: - A reward is being returned. The backend responds with a `RewardResponse`. - :http:statuscode:`401 Unauthorized`: - The reward amount requested exceeds the reward. - :http:statuscode:`404 Not found`: - The reward identifier is unknown. - :http:statuscode:`409 Conflict`: - Some of the denomination key hashes of the request do not match those currently available from the exchange (hence there is a conflict between what the wallet requests and what the merchant believes the exchange can provide). - :http:statuscode:`410 Gone`: - The reward has expired. - - .. ts:def:: RewardPickupRequest - - interface RewardPickupRequest { - - // List of planchets the wallet wants to use for the reward. - planchets: PlanchetDetail[]; - } - - .. ts:def:: PlanchetDetail - - interface PlanchetDetail { - // Hash of the denomination's public key (hashed to reduce - // bandwidth consumption). - denom_pub_hash: HashCode; - - // Coin's blinded public key. - coin_ev: CoinEnvelope; - } - - .. ts:def:: RewardResponse - - interface RewardResponse { - - // Blind RSA signatures over the planchets. - // The order of the signatures matches the planchets list. - blind_sigs: BlindSignature[]; - } - - .. ts:def:: BlindSignature - - interface BlindSignature { - - // The (blind) RSA signature. Still needs to be unblinded. - blind_sig: BlindedRsaSignature; - } - - ------------------- Instance management ------------------- @@ -2698,439 +2592,6 @@ once we got a reply from the exchange. The transfer cannot be deleted anymore. -.. _api-rewards: - ------------------------ -Backend: Giving rewards ------------------------ - -.. note:: - - This API is deprecated as of protocol v8. - -Rewards are a way for websites to give small amounts of e-cash to visitors (for -example as a financial reward for providing information or viewing -advertisements). Rewards are non-contractual: neither merchant nor consumer -have any contractual information about the other party as a result of the -reward. - - -Create reserve --------------- - -.. note:: - - This API is deprecated as of protocol v8. - -Reserves are basically funds a merchant has provided to an exchange for a -rewards campaign. Each reserve has a limited lifetime (say 2--4 weeks). Any -funds not used to reward customers will automatically be wired back from the -exchange to the originating account. - -Before handing out rewards, a merchant must tell the backend to set up a -reserve. The backend will return a reserve public key which must be used as -the wire transfer subject when wiring the reward campaign funds to the -exchange. - -.. http:post:: [/instances/$INSTANCE]/private/reserves - - Create a reserve for rewards. - - This request is **not** idempotent. However, while repeating - it will create another reserve, that is generally pretty harmless - (assuming only one of the reserves is filled with a wire transfer). - Clients may want to eventually delete the unused reserves to - avoid clutter. - - **Request:** - - The request body is a `ReserveCreateRequest` object. - - **Response:** - - :http:statuscode:`200 OK`: - The backend is waiting for the reserve to be established. The merchant - must now perform the wire transfer indicated in the `ReserveCreateConfirmation`. - :http:statuscode:`408 Request timeout`: - The exchange did not respond on time. - :http:statuscode:`409 Conflict`: - The exchange does not support the requested wire method or does not allow rewards. - :http:statuscode:`502 Bad gateway`: - We could not obtain ``/wire`` details from the specified exchange base URL. - :http:statuscode:`504 Gateway timeout`: - The merchant's interaction with the exchange took too long. - The client might want to try again later. - - .. ts:def:: ReserveCreateRequest - - interface ReserveCreateRequest { - // Amount that the merchant promises to put into the reserve. - initial_balance: Amount; - - // Exchange the merchant intends to use for rewards. - exchange_url: string; - - // Desired wire method, for example "iban" or "x-taler-bank". - wire_method: string; - } - - .. ts:def:: ReserveCreateConfirmation - - interface ReserveCreateConfirmation { - // Public key identifying the reserve. - reserve_pub: EddsaPublicKey; - - // Wire accounts of the exchange where to transfer the funds. - accounts: WireAccount[]; - } - -.. http:get:: [/instances/$INSTANCE]/private/reserves - - Obtain list of reserves that have been created for rewards. - - **Request:** - - :query after: *Optional*. Only return reserves created after the given timestamp in milliseconds. - :query active: *Optional*. Only return active/inactive reserves depending on the boolean given. - :query failures: *Optional*. Only return reserves where we disagree with the exchange about the initial balance. - - **Response:** - - :http:statuscode:`200 OK`: - Returns a list of known reward reserves. - The body is a `RewardReserveStatus`. - - .. ts:def:: RewardReserveStatus - - interface RewardReserveStatus { - // Array of all known reserves (possibly empty!). - reserves: ReserveStatusEntry[]; - } - - .. ts:def:: ReserveStatusEntry - - interface ReserveStatusEntry { - // Public key of the reserve. - reserve_pub: EddsaPublicKey; - - // Timestamp when it was established. - creation_time: Timestamp; - - // Timestamp when it expires. - expiration_time: Timestamp; - - // Initial amount as per reserve creation call. - merchant_initial_amount: Amount; - - // Initial amount as per exchange, 0 if exchange did - // not confirm reserve creation yet. - exchange_initial_amount: Amount; - - // Amount picked up so far. - pickup_amount: Amount; - - // Amount approved for rewards that exceeds the pickup_amount. - committed_amount: Amount; - - // Is this reserve active (false if it was deleted but not purged)? - active: boolean; - } - - -Query funds remaining ---------------------- - -.. http:get:: [/instances/$INSTANCE]/private/reserves/$RESERVE_PUB - - Obtain information about a specific reserve that have been created for rewards. - - **Request:** - - :query rewards: *Optional*. If set to "yes", returns also information about all of the rewards created. - - **Response:** - - :http:statuscode:`200 OK`: - Returns the `ReserveDetail`. - :http:statuscode:`404 Not found`: - The reward reserve is not known. - :http:statuscode:`502 Bad gateway`: - We are having trouble with the request because of a problem with the exchange. - Likely returned with an "exchange_code" in addition to a "code" and - an "exchange_http_status" in addition to our own HTTP status. Also usually - includes the full exchange reply to our request under "exchange_reply". - This is only returned if there was actual trouble with the exchange, not - if the exchange merely did not respond yet or if it responded that the - reserve was not yet filled. - :http:statuscode:`504 Gateway timeout`: - The merchant's interaction with the exchange took too long. - The client might want to try again later. - - .. ts:def:: ReserveDetail - - interface ReserveDetail { - // Timestamp when it was established. - creation_time: Timestamp; - - // Timestamp when it expires. - expiration_time: Timestamp; - - // Initial amount as per reserve creation call. - merchant_initial_amount: Amount; - - // Initial amount as per exchange, 0 if exchange did - // not confirm reserve creation yet. - exchange_initial_amount: Amount; - - // Amount picked up so far. - pickup_amount: Amount; - - // Amount approved for rewards that exceeds the pickup_amount. - committed_amount: Amount; - - // Array of all rewards created by this reserves (possibly empty!). - // Only present if asked for explicitly. - rewards?: RewardStatusEntry[]; - - // Is this reserve active (false if it was deleted but not purged)? - active: boolean; - - // Array of wire accounts of the exchange that could - // be used to fill the reserve, can be NULL - // if the reserve is inactive or was already filled - accounts?: WireAccount[]; - - // URL of the exchange hosting the reserve, - // NULL if the reserve is inactive - exchange_url: string; - } - - .. ts:def:: RewardStatusEntry - - interface RewardStatusEntry { - - // Unique identifier for the reward. - reward_id: HashCode; - - // Total amount of the reward that can be withdrawn. - total_amount: Amount; - - // Human-readable reason for why the reward was granted. - reason: string; - } - - -Authorizing rewards -------------------- - -.. note:: - - This API is deprecated as of protocol v8. - -.. http:post:: [/instances/$INSTANCE]/private/reserves/$RESERVE_PUB/authorize-reward - - Authorize creation of a reward from the given reserve. - - **Request:** - - The request body is a `RewardCreateRequest` object. - - **Response:** - - :http:statuscode:`200 OK`: - A reward has been created. The backend responds with a `RewardCreateConfirmation`. - :http:statuscode:`404 Not found`: - The instance or the reserve is unknown to the backend. - :http:statuscode:`412 Precondition failed`: - The reward amount requested exceeds the available reserve balance for rewards. - - .. ts:def:: RewardCreateRequest - - interface RewardCreateRequest { - // Amount that the customer should be rewarded. - amount: Amount; - - // Justification for giving the reward. - justification: string; - - // URL that the user should be directed to after receiving the reward, - // will be included in the reward_token. - next_url: string; - } - - .. ts:def:: RewardCreateConfirmation - - interface RewardCreateConfirmation { - // Unique reward identifier for the reward that was created. - reward_id: HashCode; - - // taler://reward URI for the reward. - taler_reward_uri: string; - - // URL that will directly trigger processing - // the reward when the browser is redirected to it. - reward_status_url: string; - - // When does the reward expire? - reward_expiration: Timestamp; - } - - -.. http:post:: [/instances/$INSTANCE]/private/rewards - - Authorize creation of a reward, with - automatic selection of a working reserve of the instance by the - backend. Intentionally otherwise identical to the ``/authorize-reward`` - endpoint given above. - - **Request:** - - The request body is a `RewardCreateRequest` object. - - **Response:** - - :http:statuscode:`200 OK`: - A reward has been created. The backend responds with a `RewardCreateConfirmation`. - :http:statuscode:`404 Not found`: - The instance is unknown to the backend. - :http:statuscode:`412 Precondition failed`: - The reward amount requested exceeds the available reserve balance for rewards - in all of the reserves of the instance. - - -Deleting reserves ------------------ - -.. note:: - - This API is deprecated as of protocol v8. - -.. http:delete:: [/instances/$INSTANCE]/private/reserves/$RESERVE_PUB - - Delete information about a reserve. Fails if the reserve still has - committed to rewards that were not yet picked up and that have not yet - expired. - - **Request:** - - :query purge: *Optional*. If set to YES, the reserve and all information - about rewards it issued will be fully deleted. - Otherwise only the private key would be deleted. - - **Response:** - - :http:statuscode:`204 No content`: - The backend has successfully deleted the reserve. - :http:statuscode:`404 Not found`: - The backend does not know the instance or the reserve. - :http:statuscode:`409 Conflict`: - The backend refuses to delete the reserve (committed rewards awaiting pickup). - - -Checking reward status ----------------------- - -.. note:: - - This API is deprecated as of protocol v8. - -.. http:get:: [/instances/$INSTANCE]/private/rewards/$REWARD_ID - - Obtain information about a particular reward. - - **Request:** - - :query pickups: *Optional*. If set to "yes", returns also information about all of the pickups. - :query min_amount: *Optional*. Minimum pick-up amount the client is interested in. - :query timeout_ms=NUMBER: *Optional.* If specified, the merchant backend will - wait up to ``timeout_ms`` milliseconds for rewards of at least min_pick_up to be - picked up. A client must never rely on this behavior, as the - merchant backend may return a response immediately. - - **Response:** - - :http:statuscode:`200 OK`: - The reward is known. The backend responds with a `RewardDetails` message. - :http:statuscode:`404 Not found`: - The reward is unknown to the backend. - - .. ts:def:: RewardDetails - - interface RewardDetails { - // Amount that we authorized for this reward. - total_authorized: Amount; - - // Amount that was picked up by the user already. - total_picked_up: Amount; - - // Human-readable reason given when authorizing the reward. - reason: string; - - // Timestamp indicating when the reward is set to expire (may be in the past). - expiration: Timestamp; - - // Reserve public key from which the reward is funded. - reserve_pub: EddsaPublicKey; - - // Array showing the pickup operations of the wallet (possibly empty!). - // Only present if asked for explicitly. - pickups?: PickupDetail[]; - } - - .. ts:def:: PickupDetail - - interface PickupDetail { - // Unique identifier for the pickup operation. - pickup_id: HashCode; - - // Number of planchets involved. - num_planchets: Integer; - - // Total amount requested for this pickup_id. - requested_amount: Amount; - } - - -.. http:get:: [/instances/$INSTANCE]/private/rewards - - Return the list of all rewards. - - **Request:** - - :query include_expired: *Optional*. If set to "yes", the result includes expired rewards also. Otherwise, only active rewards are returned. - - :query limit: *Optional*. At most return the given number of results. Negative for descending in database row id, positive for ascending in database row id. - - :query offset: *Optional*. Starting ``row_id`` for an iteration. - - **Response:** - - :http:statuscode:`200 OK`: - The backend has successfully found the list of rewards. The backend responds - with a `RewardsResponse`. - - .. ts:def:: RewardsResponse - - interface RewardsResponse { - - // List of rewards that are present in the backend. - rewards: Reward[]; - } - - .. ts:def:: Reward - - interface Reward { - - // ID of the reward in the backend database. - row_id: number; - - // Unique identifier for the reward. - reward_id: HashCode; - - // (Remaining) amount of the reward (including fees). - reward_amount: Amount; - } - ----------- OTP Devices ----------- diff --git a/design-documents/014-merchant-backoffice-ui.rst b/design-documents/014-merchant-backoffice-ui.rst index eaf435a4..1f744a15 100644 --- a/design-documents/014-merchant-backoffice-ui.rst +++ b/design-documents/014-merchant-backoffice-ui.rst @@ -139,11 +139,3 @@ Story #4: Manage inventory - change product description / price / etc. - delete products from inventory - - -Story #5: Manage rewards ------------------------- - -- set up reward reserve - -- check reward reserve status diff --git a/design-documents/020-backoffice-rewards-management.rst b/design-documents/020-backoffice-rewards-management.rst index 1eef39b1..8345a3b9 100644 --- a/design-documents/020-backoffice-rewards-management.rst +++ b/design-documents/020-backoffice-rewards-management.rst @@ -1,4 +1,4 @@ -DD 20: Backoffice Rewards Management +XX 20: Backoffice Rewards Management #################################### Summary diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst index 4d8f2cbc..d34241d7 100644 --- a/design-documents/023-taler-kyc.rst +++ b/design-documents/023-taler-kyc.rst @@ -40,7 +40,7 @@ Taler needs to run KYC checks in the following circumstances: * key: IBAN (encoded as payto:// URI) -* Reserve is "opened" for invoicing or rewards. +* Reserve is "opened" for invoicing. * key: reserve (=KYC account) long term public key per wallet (encoded as payto:// URI) diff --git a/design-documents/031-invoicing.rst b/design-documents/031-invoicing.rst index cfe776ed..0fcc88fd 100644 --- a/design-documents/031-invoicing.rst +++ b/design-documents/031-invoicing.rst @@ -4,9 +4,7 @@ DD 31: Invoicing Summary ======= -This document proposes new endpoints to support invoicing, -that incidentally also address the long-standing rewards -reserve expiration problem. +This document proposes new endpoints to support invoicing. Motivation @@ -36,10 +34,7 @@ Requirements * Reasonable UX and overall design impact. * Wallets may want to pay for the reserve with coins - (reserve fresh, not created via bank transfer), while - rewarding merchants likely want to pay from the reserve - balance itself. So both styles of payment should be - supported. + (reserve fresh, not created via bank transfer). Unclear in the current proposal are: @@ -62,12 +57,10 @@ charge the ``account_fee``, bump the number of open purses threshold in the ``reserves`` table and stop auto-closing of the reserve. This will ensure that the users can withdraw the reserve balance into their wallet even after a longer time period. This helps if the invoice is paid after a significant -delay, and also addresses the unwanted reward reserve closure -problem. Introduce a way to force an immediate closure of a reserve, allowing +delay. Introduce a way to force an immediate closure of a reserve, allowing P2P reserve from invoices to be send to a bank account (this allows a wallet to be used for convenient invoicing and not strictly require the wallet to -receive the funds) and also allowing the user to recover funds from a reward -reserve after rewards are no longer issued. +receive the funds). The solution needs three new tables for: diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst index 9d749595..7a8cfacd 100644 --- a/design-documents/037-wallet-transactions-lifecycle.rst +++ b/design-documents/037-wallet-transactions-lifecycle.rst @@ -525,64 +525,6 @@ the same as if the double-spending transaction had been deleted by the user. .. image:: ../images/transaction-refresh-states.png - -Transaction Type: Reward ------------------------- - -* ``pending(user)`` - - We have downloaded the metadata for the reward. This is the initial state for a - reward transaction. The user needs to accept/refuse the reward. - - * ``[reward-expired] => expired`` - * ``[action:accept] => pending(pickup)`` - -* ``pending(pickup)`` - - We are picking up the reward. - - * ``[failure] => failed``: any type of failure, including expiration. - * ``[processed-kyc-required] => pending(kyc-required)`` - * ``[success] => done`` - * ``[action:suspend] => suspended(pickup)`` - -* ``suspended(pickup)`` - - The user suspended the operation while the reward was being picked up. - - * ``[reward-expired] => failed`` - * ``[action:resume] => pending(pickup)`` - -* ``pending(kyc)`` - - The user needs to perform a KYC check to continue. This usually should only - happen if the wallet balance exceeds some threshold. - - * ``[poll-success] => pending(pickup)`` - * ``[action:suspend] => suspended(kyc)`` - -* ``suspended(kyc)`` - - The user suspended the KYC operation. Note that we do not time out here if - the reward expires, as the wallet balance threshold KYC likely applies even - without the reward. - - * ``[action:resume] => pending(kyc)`` - -* ``done`` - - The reward operation completed. - - * ``[action:delete] => deleted`` - -* ``deleted`` - - All memory of the reward operation is lost, but of course the resulting fresh - coins are preserved. - -.. image:: ../images/transaction-reward-states.png - - Transaction Type: Deposit ------------------------- diff --git a/design-documents/041-wallet-balance-amount-definitions.rst b/design-documents/041-wallet-balance-amount-definitions.rst index 1c89d634..9943d482 100644 --- a/design-documents/041-wallet-balance-amount-definitions.rst +++ b/design-documents/041-wallet-balance-amount-definitions.rst @@ -245,20 +245,6 @@ REFUND Is there a way that the merchant can initiate a refund of purchase + refund_fee so the wallet will get the same effective_amount? -REWARD - raw amount is the amount that the merchant send as reward - - ``instructed_amount`` = reward.amount - - ``raw_amount`` = instructed_amount + withdrawal_fee - - ``effective_amount`` = instructed_amount - - .. note:: - We should not show fee for rewards in the wallet since the merchant is the one choosing - the exchange and we can assume that those rewards are paid by the merchant. - So the wallet only care about the effective. - Coin selection algorithm ------------------------ diff --git a/design-documents/053-wallet-ui.rst b/design-documents/053-wallet-ui.rst index 5891eb37..5b5ba22d 100644 --- a/design-documents/053-wallet-ui.rst +++ b/design-documents/053-wallet-ui.rst @@ -4,7 +4,7 @@ DD 53: Wallet UI Design Summary ======= -This document proposes designs wallet UI. It defines what Android, iOS and +This document proposes designs wallet UI. It defines what Android, iOS and WebExtension should follow in order to have a coherent UI between platforms. Motivation @@ -12,8 +12,8 @@ Motivation We want user to be able to help each others independent of the implementation they are using. -We want user to be able to capitalize the effort of learning how to use one -wallet and be able to use a different one without the need to learn +We want user to be able to capitalize the effort of learning how to use one +wallet and be able to use a different one without the need to learn anything new. Currently development of different platform specific implementation are independent and every developer needs to choose the layout, texts and buttons and navigation. @@ -25,7 +25,7 @@ Every screen MUST be defined in a document with the following information: * **Identifiable UI screens**: every UI should have an unique identifier that will be use for development discussion and bug reports. There should be an option - in the application to enable an active rendering of the id. + in the application to enable an active rendering of the id. * **Description**: the reason to be of the screen, should help to define what will be included into, what is going to left for other screens and when and from @@ -41,24 +41,24 @@ properties is defined in the spec the implementation must implement it. The spec should be minimal to achieve the objective in the description. * **Info**: Spec of information that the user should have access. The type of info - could be a field (id and value) or a banner (information and instructions). - The spec will help to reuse the text for i18n across apps and defined + could be a field (id and value) or a banner (information and instructions). + The spec will help to reuse the text for i18n across apps and defined * **Inputs**: Spec of information need to provide in current screen. The type of input, range of values and validation should be defined if necessary. -* **Actions**: Spec of buttons and interactable elements that will have a significant +* **Actions**: Spec of buttons and interactable elements that will have a significant change in the current state. It should also mention navigation when applicable. - + * **Layout**: Spec position of elements when needed. The spec should be "soft" in a sense - that elements should be easy to find following directions like "close to X" or + that elements should be easy to find following directions like "close to X" or "at the start/end of the screen". -Screen should be defined using the most relaxed definition that are good enough to +Screen should be defined using the most relaxed definition that are good enough to be clear for the user. Platform will use this definition and adapt to the differences on the platform taking advantange of platform API and screen sizes. -When a screen have multiple uses for the same purpose, a substate section should be +When a screen have multiple uses for the same purpose, a substate section should be included with the difference with the main definition. Part of the screens that are reused shoud also be defined in this document as screen. @@ -84,11 +84,11 @@ fee, restrictions and ETA should be clear for the user. * exchange to be used showing the URL * table of details of the operation: use the ``operation-table-details`` screen * starting currency: if the exchange has the currency conversion service enabled user should be able to the details based on the wire transfer currency - * taler URI: show copy button or QR to complete the operation with another device + * taler URI: show copy button or QR to complete the operation with another device ``Inputs``: * age restriction: allow the selection of the restriction in the age group possible by the exchange - * service provider: allow the selection of different exchange + * service provider: allow the selection of different exchange ``Actions``: * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed @@ -111,10 +111,10 @@ fee, restrictions and ETA should be clear for the user. * order summary * table of details of the operation: use the ``operation-table-details`` screen * receipt: order id - * payment deadline: absolute time before the claimed order expires - * taler URI: show copy button or QR to complete the operation with another device + * payment deadline: absolute time before the claimed order expires + * taler URI: show copy button or QR to complete the operation with another device * cant pay desc: if the user has enough balance but unable to use it - * payment status: if the + * payment status: if the ``Actions``: * confirm operation: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed @@ -156,7 +156,7 @@ fee, restrictions and ETA should be clear for the user. ``Inputs``: * subject: short description of the transaction * expiration: absolute time/date after which the invoice is not valid anymore - * service provider: allow the selection of different exchange + * service provider: allow the selection of different exchange ``Actions``: * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed @@ -225,24 +225,6 @@ fee, restrictions and ETA should be clear for the user. * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen * cancel: user will be redirected to ``balance`` -cta-reward ------------ - -``Description``: this screen is used for the confirmation of the acceptance of -a reward from a merchant. -the success of this operation will be an will decrease the balance in the wallet. -fee, restrictions and ETA should be clear for the user. - -``Info``: - * amount: effective amount to receive - * exchange: from where this money comes from - * merchant: offering the reward - -``Actions``: - * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen - * cancel: user will be redirected to ``balance`` - operation-table-details ----------------------- @@ -252,12 +234,12 @@ the initial amount and the final amount with all the items related to the operat ``labels``: initial amount of the operation, and final amount are always shown. Fee should be shown as an extra row in the table if it is non-zero. -Converted amount should be shown as an extra row if initial amount currency is not the same +Converted amount should be shown as an extra row if initial amount currency is not the same as the final amount currency. Initial amount label by operation: - * payment -> Price + * payment -> Price * deposit -> Send * peer-pull-credit -> Invoice * peer-pull-debit -> Invoice @@ -286,4 +268,3 @@ user already accepted ToS) Q / A ===== - diff --git a/images/Makefile b/images/Makefile index 3a7fdab9..ad7a695d 100644 --- a/images/Makefile +++ b/images/Makefile @@ -1,4 +1,4 @@ -diagrams: regional-arch.png arch-api.png coin.png deposit.png reserve.png transaction-common-states.png transaction-withdrawal-states.png transaction-payment-states.png transaction-refund-states.png transaction-refresh-states.png transaction-reward-states.png transaction-deposit-states.png transaction-push-debit-states.png transaction-push-credit-states.png transaction-pull-credit-states.png transaction-pull-debit-states.png challenger.png +diagrams: regional-arch.png arch-api.png coin.png deposit.png reserve.png transaction-common-states.png transaction-withdrawal-states.png transaction-payment-states.png transaction-refund-states.png transaction-refresh-states.png transaction-deposit-states.png transaction-push-debit-states.png transaction-push-credit-states.png transaction-pull-credit-states.png transaction-pull-debit-states.png challenger.png arch-api.png: arch-api.dot dot -Tpng arch-api.dot > arch-api.png @@ -16,8 +16,6 @@ transaction-refund-states.png: transaction-refund-states.dot dot -Tpng transaction-refund-states.dot > transaction-refund-states.png transaction-refresh-states.png: transaction-refresh-states.dot dot -Tpng transaction-refresh-states.dot > transaction-refresh-states.png -transaction-reward-states.png: transaction-reward-states.dot - dot -Tpng transaction-reward-states.dot > transaction-reward-states.png transaction-deposit-states.png: transaction-deposit-states.dot dot -Tpng transaction-deposit-states.dot > transaction-deposit-states.png transaction-push-debit-states.png: transaction-push-debit-states.dot diff --git a/images/transaction-reward-states.dot b/images/transaction-reward-states.dot deleted file mode 100644 index 476c8c74..00000000 --- a/images/transaction-reward-states.dot +++ /dev/null @@ -1,11 +0,0 @@ -digraph G { - initial[label="", shape="circle"]; - dialog_user[label="dialog(user)"]; - pending_pickup[label="pickup"]; - done[label="done", shape="box"]; - - initial -> dialog_user; - - dialog_user -> pending_pickup [color=blue, label="OK"]; - pending_pickup -> done [color=green]; -} diff --git a/manpages/taler-wallet-cli.1.rst b/manpages/taler-wallet-cli.1.rst index 2d35bb87..dad790f5 100644 --- a/manpages/taler-wallet-cli.1.rst +++ b/manpages/taler-wallet-cli.1.rst @@ -46,8 +46,6 @@ for testing. **withdraw-uri** URI -**reward-uri** URI - **refund-uri** URI **pay-uri** [**-y** | **--yes**] URI diff --git a/manpages/taler.conf.5.rst b/manpages/taler.conf.5.rst index 191c7e59..115dee8a 100644 --- a/manpages/taler.conf.5.rst +++ b/manpages/taler.conf.5.rst @@ -162,13 +162,6 @@ AML_THRESHOLD 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. -ENABLE_REWARDS - This option can be used to announce that an exchange does not allow - the use of the reserves for rewards. The default is YES which means - that rewards are allowed. The option merely announces that - rewards is enabled or disabled, and protocol-compliant merchant - backends will then enable or disable the feature accordingly. - STEFAN_ABS Absolte amount to add as an offset in the STEFAN fee approximation curve (see DD47). Defaults to CURRENCY:0 if not specified. diff --git a/orphaned/taler-nfc-guide.rst b/orphaned/taler-nfc-guide.rst index aa961d31..d025d347 100644 --- a/orphaned/taler-nfc-guide.rst +++ b/orphaned/taler-nfc-guide.rst @@ -231,8 +231,8 @@ to dereference the ``taler://pay`` URI from the example above: # success response with no data m<-w 9000 -(Note that this process works analogously for communication between a bank/ATM -terminal or "reward provider".) +(Note that this process works analogously for communication with a bank/ATM +terminal.) Request tunneling diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst index 184c6592..ce0e600f 100644 --- a/taler-developer-manual.rst +++ b/taler-developer-manual.rst @@ -93,8 +93,7 @@ overview: sending invoices or payments to other wallets. * taler-merchant-demos: various demonstration services operated at - 'demo.taler.net', including a simple shop, donation page and a - survey with reward functionality. + 'demo.taler.net', including a simple shop and a donation page. There are other important repositories without code, including: diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst index 79455fec..64c2a7d9 100644 --- a/taler-exchange-manual.rst +++ b/taler-exchange-manual.rst @@ -967,7 +967,7 @@ Taler permits an exchange to require KYC data under the following circumstances: * Wallet receives (via refunds) money resulting in a balance over a threshold * Wallet receives money via P2P payments over a threshold * Merchant receives money over a threshold - * Reserve is "opened" for invoicing or rewards (**planned feature**) + * Reserve is "opened" for invoicing (**planned feature**) Any of the above requests can trigger the KYC process, which can be illustrated as follows: diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst index 739cf07f..87fee9ca 100644 --- a/taler-merchant-api-tutorial.rst +++ b/taler-merchant-api-tutorial.rst @@ -63,10 +63,6 @@ If you want to look at some simple, running examples, check out these: that accepts donations for software projects and gives donation receipts. -- The - `survey `__ - that gives users who answer a question a small reward. - - The `WooCommerce plugin `__ which is a comprehensive integration into a Web shop including the refund business process. @@ -413,69 +409,6 @@ considered to identify a resource you can pay for and thus do not have to be unique. -.. _Giving-Customers-Rewards: -.. index:: rewards - -Giving Customers Rewards -======================== - -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 rewards, and -sufficient funds must be made available for rewards. See the :ref:`Taler User -Guide ` for details. - -To check if rewards are configured properly and if there are sufficient -funds available for granting rewards, query the ``/private/reserves`` endpoint: - -.. code-block:: python - - >>> import requests - >>> requests.get("https://backend.demo.taler.net/private/reserves", - ... headers={"Authorization": "Bearer secret-token:sandbox"}) - - -Check that a reserve exists where the ``merchant_initial_amount`` is below the -``committed_amount`` and that the reserve is ``active``. - -.. _authorize-reward: - -To authorize a reward, ``POST`` to ``/private/rewards``. The following fields -are recognized in the JSON request object: - -- ``amount``: Amount that should be given to the visitor as a reward. - -- ``justification``: Description of why the reward was granted. Human-readable - text not exposed to the customer, but used by the Back Office. - -- ``next_url``: The URL that the user’s browser should be redirected to by - the wallet, once the reward has been processed. - -The response from the backend contains a ``taler_reward_url``. The -customer’s browser must be redirected to this URL for the wallet to pick -up the reward. - -.. _pick-up-reward: - -This code snipped illustrates giving a reward: - -.. code-block:: python - - >>> import requests - >>> 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/private/rewards", json=reward_req, - ... headers={"Authorization": "Bearer secret-token:sandbox"}) - - - .. _Advanced-topics: Advanced topics diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst index 04aadb5d..9ed7ea3e 100644 --- a/taler-merchant-manual.rst +++ b/taler-merchant-manual.rst @@ -332,50 +332,6 @@ and the amount that was received. Given this information, the backend can detect and report any irregularities that might arise. -.. _rewards: - -Rewards -------- - -.. index:: reward -.. index:: pick up - -Taler does not only allow a Website to be paid, but also to make voluntary, -non-contractual payments to visitors, called *rewards*. Such rewards could be -granted as a reward for filling in surveys or watching advertizements. For -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 rewards, it must establish a reserve. Once a reserve has been -established, the merchant can *grant* rewards, allowing wallets to *pick up* -the reward. - -.. note:: - - 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. - -.. _merchant-reserves: - - -Reserves --------- - -.. index:: reserve -.. index:: close - -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 -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 *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. - Webhooks -------- diff --git a/taler-wallet.rst b/taler-wallet.rst index 3ea1dbea..62dca80d 100644 --- a/taler-wallet.rst +++ b/taler-wallet.rst @@ -431,7 +431,6 @@ Things we still need tests for: Or when the merchant is not reachable? Or the bank? This can be tested by temporarily killing those services. * How does the wallet deal with processing the same ``taler://(pay|withdraw)`` URI twice? -* Test rewards (accepting/refusing a reward) * Test refunds * Test for :ref:`session-based payments ` * Test case for auto-refunds -- cgit v1.2.3 From 62536c6c29e9754de5988b76883ddb04c5c529d8 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Wed, 21 Feb 2024 14:21:58 +0100 Subject: DD55 very early draft --- design-documents/055-wallet-problem-report.rst | 82 ++++++++++++++++++++++++++ design-documents/index.rst | 1 + 2 files changed, 83 insertions(+) create mode 100644 design-documents/055-wallet-problem-report.rst (limited to 'design-documents') diff --git a/design-documents/055-wallet-problem-report.rst b/design-documents/055-wallet-problem-report.rst new file mode 100644 index 00000000..18909f40 --- /dev/null +++ b/design-documents/055-wallet-problem-report.rst @@ -0,0 +1,82 @@ +DD 55: Wallet Problem Reports +############################# + +.. note:: + + **Status**: Early work in progress / DD number reservation. + +Summary +======= + +This design document specifies global error reports generated/managed by wallet-core +and rendered by the wallet UIs. + +Motivation +========== + +Sometimes the wallet encounters issues that go beyond the scope of single transaction. + +Requirements +============ + +* problem reports must have a clear lifecycle +* problem reports must have some type of identification that allows to + easily find out if a new problem report needs to be created when an + error happens or whether an existing one has been created + +Proposed Solution +================= + +Report identification +--------------------- + +The report identifier serves multiple purposes: + +1. Usage as a reference in wallet-core APIs +2. De-duplication. The report ID should allow easy identification of an already existing report for a particular problem. + +New wallet-core requests +------------------------ + +* ``listProblemReports`` +* ``acknowledgeProblemReport``: Mark a problem report as read. +* ``deleteProblemReport``: Delete the problem report. + +New wallet-core notification type +--------------------------------- + +* ``problem-report`` to notify clients about status changes or an error report + (including creation!) + + +Types of reports +---------------- + +* money lost due to the exchange stopping to offer a denomination +* money locked behind a (long) pending refresh +* money lost due to a permanently failing refresh + + +Definition of Done +================== + +TBD. + +Alternatives +============ + +TBD. + +Drawbacks +========= + +TBD. + +Discussion / Q&A +================ + +* When is a report amended vs a new report created? + + * example: Exchange stops offering denomination D1. Later, it stops offering D2. + Are two reports generated or is the first report changed? + diff --git a/design-documents/index.rst b/design-documents/index.rst index 91bfce4c..454564d0 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -66,4 +66,5 @@ Design documents that start with "XX" are considered deprecated. 052-libeufin-bank-2fa.rst 053-wallet-ui.rst 054-dynamic-form.rst + 055-wallet-problem-report.rst 999-template -- cgit v1.2.3 From 158ddc760c813082b850e876003dba2f2644a503 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Wed, 21 Feb 2024 19:30:06 +0100 Subject: DD55 --- design-documents/055-wallet-problem-report.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'design-documents') diff --git a/design-documents/055-wallet-problem-report.rst b/design-documents/055-wallet-problem-report.rst index 18909f40..0b478416 100644 --- a/design-documents/055-wallet-problem-report.rst +++ b/design-documents/055-wallet-problem-report.rst @@ -55,6 +55,7 @@ Types of reports * money lost due to the exchange stopping to offer a denomination * money locked behind a (long) pending refresh * money lost due to a permanently failing refresh +* exchange changed its master public key Definition of Done -- cgit v1.2.3 From d6a97e7a95b77e3e058ebbda25dce559c38d4de8 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Thu, 22 Feb 2024 13:34:50 +0100 Subject: dd55 --- design-documents/055-wallet-problem-report.rst | 1 + design-documents/index.rst | 1 + 2 files changed, 2 insertions(+) (limited to 'design-documents') diff --git a/design-documents/055-wallet-problem-report.rst b/design-documents/055-wallet-problem-report.rst index 0b478416..a7ae783c 100644 --- a/design-documents/055-wallet-problem-report.rst +++ b/design-documents/055-wallet-problem-report.rst @@ -56,6 +56,7 @@ Types of reports * money locked behind a (long) pending refresh * money lost due to a permanently failing refresh * exchange changed its master public key +* a denomination changed its info (expiration, fees) Definition of Done diff --git a/design-documents/index.rst b/design-documents/index.rst index 454564d0..03448acb 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -67,4 +67,5 @@ Design documents that start with "XX" are considered deprecated. 053-wallet-ui.rst 054-dynamic-form.rst 055-wallet-problem-report.rst + 056-wallet-activity-diagnostics.rst 999-template -- cgit v1.2.3 From 53970e2ee81ce97055ee0fd63430547efc39ac6a Mon Sep 17 00:00:00 2001 From: Marc Stibane Date: Sun, 25 Feb 2024 10:30:19 +0100 Subject: Screenshot of iOS Taler Wallet: empty wallet (#10) --- .../ios-wallet/VIEW_EMPTY_WALLET_10.png | Bin 0 -> 165173 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 design-documents/wallet-screenshots/ios-wallet/VIEW_EMPTY_WALLET_10.png (limited to 'design-documents') diff --git a/design-documents/wallet-screenshots/ios-wallet/VIEW_EMPTY_WALLET_10.png b/design-documents/wallet-screenshots/ios-wallet/VIEW_EMPTY_WALLET_10.png new file mode 100644 index 00000000..4f1a19ec Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/VIEW_EMPTY_WALLET_10.png differ -- cgit v1.2.3 From 9b7566cab59cfdadf9894c7c154a4c9237c7c92e Mon Sep 17 00:00:00 2001 From: Marc Stibane Date: Sun, 25 Feb 2024 12:16:46 +0100 Subject: Screenshots for iOS cta-withdraw --- .../ios-wallet/VIEW_EMPTY_WALLET_10.png | Bin 165173 -> 0 bytes .../ios-wallet/cta-withdraw-bank-confirm.png | Bin 0 -> 357675 bytes .../ios-wallet/cta-withdraw-bank-confirmed.png | Bin 0 -> 357108 bytes .../ios-wallet/cta-withdraw-bank-register.png | Bin 0 -> 338618 bytes .../ios-wallet/cta-withdraw-bank-send-money.png | Bin 0 -> 464966 bytes .../ios-wallet/cta-withdraw-bank-withdraw.png | Bin 0 -> 505046 bytes .../cta-withdraw-sheet130-withdraw-confirm.png | Bin 0 -> 202047 bytes .../ios-wallet/cta-withdraw-sheet130-withdraw.png | Bin 0 -> 246405 bytes .../ios-wallet/cta-withdraw-sheet131-tos.png | Bin 0 -> 317496 bytes .../cta-withdraw-sheet133-withdraw-confirm-bank.png | Bin 0 -> 230382 bytes .../ios-wallet/cta-withdraw-view10-empty-wallet.png | Bin 0 -> 169741 bytes .../ios-wallet/cta-withdraw-view22-balances.png | Bin 0 -> 239045 bytes 12 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 design-documents/wallet-screenshots/ios-wallet/VIEW_EMPTY_WALLET_10.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirm.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirmed.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-register.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-send-money.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-withdraw.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw-confirm.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet131-tos.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet133-withdraw-confirm-bank.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view10-empty-wallet.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view22-balances.png (limited to 'design-documents') diff --git a/design-documents/wallet-screenshots/ios-wallet/VIEW_EMPTY_WALLET_10.png b/design-documents/wallet-screenshots/ios-wallet/VIEW_EMPTY_WALLET_10.png deleted file mode 100644 index 4f1a19ec..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/VIEW_EMPTY_WALLET_10.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirm.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirm.png new file mode 100644 index 00000000..4441777a Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirm.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirmed.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirmed.png new file mode 100644 index 00000000..c356eb13 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirmed.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-register.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-register.png new file mode 100644 index 00000000..e7b7c1f9 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-register.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-send-money.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-send-money.png new file mode 100644 index 00000000..788ae7ab Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-send-money.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-withdraw.png new file mode 100644 index 00000000..74e1efff Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-withdraw.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw-confirm.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw-confirm.png new file mode 100644 index 00000000..22c57d66 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw-confirm.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw.png new file mode 100644 index 00000000..4f893fd4 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet131-tos.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet131-tos.png new file mode 100644 index 00000000..1aafc03e Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet131-tos.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet133-withdraw-confirm-bank.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet133-withdraw-confirm-bank.png new file mode 100644 index 00000000..94ad63b1 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet133-withdraw-confirm-bank.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view10-empty-wallet.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view10-empty-wallet.png new file mode 100644 index 00000000..a6737b9f Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view10-empty-wallet.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view22-balances.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view22-balances.png new file mode 100644 index 00000000..bd83cb8f Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view22-balances.png differ -- cgit v1.2.3 From b4b7cc5cb0d5a609e63711100520f577ba3bee57 Mon Sep 17 00:00:00 2001 From: Marc Stibane Date: Sun, 25 Feb 2024 12:18:11 +0100 Subject: Screenshots for iOS cta-withdraw, with CHF instead of KUDOS --- .../CHF/cta-withdraw-sheet130-withdraw-confirm.png | Bin 0 -> 193455 bytes .../ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png | Bin 0 -> 237544 bytes .../cta-withdraw-sheet133-withdraw-confirm-bank.png | Bin 0 -> 231969 bytes .../ios-wallet/CHF/cta-withdraw-view22-balances.png | Bin 0 -> 234937 bytes 4 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw-confirm.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-view22-balances.png (limited to 'design-documents') diff --git a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw-confirm.png b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw-confirm.png new file mode 100644 index 00000000..11dd9db0 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw-confirm.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png new file mode 100644 index 00000000..d46f0e5c Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png new file mode 100644 index 00000000..5d7dd8cd Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-view22-balances.png b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-view22-balances.png new file mode 100644 index 00000000..473621e8 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-view22-balances.png differ -- cgit v1.2.3 From 530c17e2085125758c89795533a60d153c66e144 Mon Sep 17 00:00:00 2001 From: Marc Stibane Date: Sun, 25 Feb 2024 15:17:13 +0100 Subject: Move screenshots into withdraw-bankIntegrated --- .../CHF/cta-withdraw-sheet130-withdraw-confirm.png | Bin 193455 -> 0 bytes .../ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png | Bin 237544 -> 0 bytes .../cta-withdraw-sheet133-withdraw-confirm-bank.png | Bin 231969 -> 0 bytes .../ios-wallet/CHF/cta-withdraw-view22-balances.png | Bin 234937 -> 0 bytes .../ios-wallet/cta-withdraw-bank-confirm.png | Bin 357675 -> 0 bytes .../ios-wallet/cta-withdraw-bank-confirmed.png | Bin 357108 -> 0 bytes .../ios-wallet/cta-withdraw-bank-register.png | Bin 338618 -> 0 bytes .../ios-wallet/cta-withdraw-bank-send-money.png | Bin 464966 -> 0 bytes .../ios-wallet/cta-withdraw-bank-withdraw.png | Bin 505046 -> 0 bytes .../cta-withdraw-sheet130-withdraw-confirm.png | Bin 202047 -> 0 bytes .../ios-wallet/cta-withdraw-sheet130-withdraw.png | Bin 246405 -> 0 bytes .../ios-wallet/cta-withdraw-sheet131-tos.png | Bin 317496 -> 0 bytes .../cta-withdraw-sheet133-withdraw-confirm-bank.png | Bin 230382 -> 0 bytes .../ios-wallet/cta-withdraw-view10-empty-wallet.png | Bin 169741 -> 0 bytes .../ios-wallet/cta-withdraw-view22-balances.png | Bin 239045 -> 0 bytes .../CHF/cta-withdraw-sheet130-withdraw-confirm.png | Bin 0 -> 193455 bytes .../CHF/cta-withdraw-sheet130-withdraw.png | Bin 0 -> 237544 bytes .../cta-withdraw-sheet133-withdraw-confirm-bank.png | Bin 0 -> 231969 bytes .../CHF/cta-withdraw-view22-balances.png | Bin 0 -> 234937 bytes .../cta-withdraw-bank-confirm.png | Bin 0 -> 357675 bytes .../cta-withdraw-bank-confirmed.png | Bin 0 -> 357108 bytes .../cta-withdraw-bank-register.png | Bin 0 -> 338618 bytes .../cta-withdraw-bank-send-money.png | Bin 0 -> 464966 bytes .../cta-withdraw-bank-withdraw.png | Bin 0 -> 505046 bytes .../cta-withdraw-sheet130-withdraw-confirm.png | Bin 0 -> 202047 bytes .../cta-withdraw-sheet130-withdraw.png | Bin 0 -> 246405 bytes .../cta-withdraw-sheet131-tos.png | Bin 0 -> 317496 bytes .../cta-withdraw-sheet133-withdraw-confirm-bank.png | Bin 0 -> 230382 bytes .../cta-withdraw-view10-empty-wallet.png | Bin 0 -> 169741 bytes .../cta-withdraw-view22-balances.png | Bin 0 -> 239045 bytes 30 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw-confirm.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-view22-balances.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirm.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirmed.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-register.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-send-money.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-withdraw.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw-confirm.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet131-tos.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet133-withdraw-confirm-bank.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view10-empty-wallet.png delete mode 100644 design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view22-balances.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw-confirm.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-view22-balances.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirm.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirmed.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-register.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-send-money.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-withdraw.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw-confirm.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet131-tos.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet133-withdraw-confirm-bank.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view10-empty-wallet.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view22-balances.png (limited to 'design-documents') diff --git a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw-confirm.png b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw-confirm.png deleted file mode 100644 index 11dd9db0..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw-confirm.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png deleted file mode 100644 index d46f0e5c..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet130-withdraw.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png deleted file mode 100644 index 5d7dd8cd..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-view22-balances.png b/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-view22-balances.png deleted file mode 100644 index 473621e8..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/CHF/cta-withdraw-view22-balances.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirm.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirm.png deleted file mode 100644 index 4441777a..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirm.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirmed.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirmed.png deleted file mode 100644 index c356eb13..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-confirmed.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-register.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-register.png deleted file mode 100644 index e7b7c1f9..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-register.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-send-money.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-send-money.png deleted file mode 100644 index 788ae7ab..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-send-money.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-withdraw.png deleted file mode 100644 index 74e1efff..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-bank-withdraw.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw-confirm.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw-confirm.png deleted file mode 100644 index 22c57d66..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw-confirm.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw.png deleted file mode 100644 index 4f893fd4..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet130-withdraw.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet131-tos.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet131-tos.png deleted file mode 100644 index 1aafc03e..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet131-tos.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet133-withdraw-confirm-bank.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet133-withdraw-confirm-bank.png deleted file mode 100644 index 94ad63b1..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-sheet133-withdraw-confirm-bank.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view10-empty-wallet.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view10-empty-wallet.png deleted file mode 100644 index a6737b9f..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view10-empty-wallet.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view22-balances.png b/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view22-balances.png deleted file mode 100644 index bd83cb8f..00000000 Binary files a/design-documents/wallet-screenshots/ios-wallet/cta-withdraw-view22-balances.png and /dev/null differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw-confirm.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw-confirm.png new file mode 100644 index 00000000..11dd9db0 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw-confirm.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw.png new file mode 100644 index 00000000..d46f0e5c Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png new file mode 100644 index 00000000..5d7dd8cd Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-view22-balances.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-view22-balances.png new file mode 100644 index 00000000..473621e8 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-view22-balances.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirm.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirm.png new file mode 100644 index 00000000..4441777a Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirm.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirmed.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirmed.png new file mode 100644 index 00000000..c356eb13 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirmed.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-register.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-register.png new file mode 100644 index 00000000..e7b7c1f9 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-register.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-send-money.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-send-money.png new file mode 100644 index 00000000..788ae7ab Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-send-money.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-withdraw.png new file mode 100644 index 00000000..74e1efff Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-withdraw.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw-confirm.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw-confirm.png new file mode 100644 index 00000000..22c57d66 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw-confirm.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw.png new file mode 100644 index 00000000..4f893fd4 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet131-tos.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet131-tos.png new file mode 100644 index 00000000..1aafc03e Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet131-tos.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet133-withdraw-confirm-bank.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet133-withdraw-confirm-bank.png new file mode 100644 index 00000000..94ad63b1 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet133-withdraw-confirm-bank.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view10-empty-wallet.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view10-empty-wallet.png new file mode 100644 index 00000000..a6737b9f Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view10-empty-wallet.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view22-balances.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view22-balances.png new file mode 100644 index 00000000..bd83cb8f Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view22-balances.png differ -- cgit v1.2.3 From 0b6e0a4e3f7331d0e026f7722a6572f4cce3aa90 Mon Sep 17 00:00:00 2001 From: Marc Stibane Date: Sun, 25 Feb 2024 15:19:07 +0100 Subject: Screenshots for iOS withdraw-exchange, with NETZBON and CHF --- .../cta-withdrawExchange-sheet-amount.png | Bin 0 -> 173529 bytes .../cta-withdrawExchange-sheet-wireTransfer-CHF-1.png | Bin 0 -> 292949 bytes .../cta-withdrawExchange-sheet-wireTransfer-CHF-2.png | Bin 0 -> 407510 bytes .../cta-withdrawExchange-sheet-wireTransfer-CHF-3.png | Bin 0 -> 331196 bytes .../cta-withdrawExchange-sheet135-amount.png | Bin 0 -> 215793 bytes .../cta-withdrawExchange-sheet135-amount2.png | Bin 0 -> 214738 bytes .../cta-withdrawExchange-sheet135-tos.png | Bin 0 -> 116707 bytes .../cta-withdrawExchange-sheet135-wireTransfer-CHF.png | Bin 0 -> 304402 bytes ...cta-withdrawExchange-sheet135-wireTransfer-CHF2.png | Bin 0 -> 420238 bytes ...cta-withdrawExchange-sheet135-wireTransfer-NETZ.png | Bin 0 -> 309949 bytes ...ta-withdrawExchange-sheet135-wireTransfer-NETZ2.png | Bin 0 -> 413992 bytes .../cta-withdrawExchange-sheet135-withdraw-tos.png | Bin 0 -> 170387 bytes 12 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-amount.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-1.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-2.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-3.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount2.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-tos.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF2.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ2.png create mode 100644 design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-withdraw-tos.png (limited to 'design-documents') diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-amount.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-amount.png new file mode 100644 index 00000000..9a51cb78 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-amount.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-1.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-1.png new file mode 100644 index 00000000..1d9fdbfd Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-1.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-2.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-2.png new file mode 100644 index 00000000..3ea5b9ca Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-2.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-3.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-3.png new file mode 100644 index 00000000..c15f9a5e Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-3.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount.png new file mode 100644 index 00000000..4db97e7c Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount2.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount2.png new file mode 100644 index 00000000..8c0d7f2a Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount2.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-tos.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-tos.png new file mode 100644 index 00000000..b71d7dcf Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-tos.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF.png new file mode 100644 index 00000000..8a467161 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF2.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF2.png new file mode 100644 index 00000000..24bb4881 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF2.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ.png new file mode 100644 index 00000000..7423411a Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ2.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ2.png new file mode 100644 index 00000000..80843838 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ2.png differ diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-withdraw-tos.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-withdraw-tos.png new file mode 100644 index 00000000..21056f08 Binary files /dev/null and b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-withdraw-tos.png differ -- cgit v1.2.3 From 4af379f314b87b77261044cad2b38f94aae713c8 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 25 Feb 2024 16:30:52 +0100 Subject: add screenshots --- design-documents/053-wallet-ui.rst | 77 ++++++++++++++++++++++- screenshots/cta-payment-firefox-0.png | Bin 0 -> 43899 bytes screenshots/cta-payment-firefox-latest.png | 1 + screenshots/cta-payment-paid-firefox-0.png | Bin 0 -> 36529 bytes screenshots/cta-payment-paid-firefox-latest.png | 1 + screenshots/cta-url-entry-firefox-0.png | Bin 0 -> 37619 bytes screenshots/cta-url-entry-firefox-latest.png | 1 + screenshots/cta-wire-transfer-firefox-0.png | Bin 0 -> 75735 bytes screenshots/cta-wire-transfer-firefox-latest.png | 1 + screenshots/cta-withdraw-done-firefox-0.png | Bin 0 -> 30061 bytes screenshots/cta-withdraw-done-firefox-latest.png | 1 + screenshots/cta-withdraw-firefox-0.png | Bin 0 -> 35550 bytes screenshots/cta-withdraw-firefox-latest.png | 1 + 13 files changed, 81 insertions(+), 2 deletions(-) create mode 100644 screenshots/cta-payment-firefox-0.png create mode 120000 screenshots/cta-payment-firefox-latest.png create mode 100644 screenshots/cta-payment-paid-firefox-0.png create mode 120000 screenshots/cta-payment-paid-firefox-latest.png create mode 100644 screenshots/cta-url-entry-firefox-0.png create mode 120000 screenshots/cta-url-entry-firefox-latest.png create mode 100644 screenshots/cta-wire-transfer-firefox-0.png create mode 120000 screenshots/cta-wire-transfer-firefox-latest.png create mode 100644 screenshots/cta-withdraw-done-firefox-0.png create mode 120000 screenshots/cta-withdraw-done-firefox-latest.png create mode 100644 screenshots/cta-withdraw-firefox-0.png create mode 120000 screenshots/cta-withdraw-firefox-latest.png (limited to 'design-documents') diff --git a/design-documents/053-wallet-ui.rst b/design-documents/053-wallet-ui.rst index 5b5ba22d..5c3ccb9e 100644 --- a/design-documents/053-wallet-ui.rst +++ b/design-documents/053-wallet-ui.rst @@ -70,7 +70,7 @@ Common definition: Proposed Solutions ================== -List of dall screens with the defined properties +List of all screens with the defined properties. cta-withdraw ------------ @@ -98,8 +98,62 @@ fee, restrictions and ETA should be clear for the user. .. attention:: User should be able to play with the amount, not possible in the current design +cta-wire-transfer +----------------- + +``Description``: this screen is used to show the user the information for +the wire transfer to complete a manual withdrawal operation. + +``Info``: + * wire transfer subject to be used (first, most important) + * target bank account to transfer funds to (e.g. IBAN) + * total amount to transfer in the wire transfer currency + * button to copy ``payto://`` URI with the information to clipboard + +``Actions``: + * abort: aborts the withdrawal operation + * menu: go back to the main balances list (operation continues in background) + * automatic: screen changes to "cta-withdraw-done" upon completion + +cta-withdraw-done +----------------- + +``Description``: this screen is used to show the user the information for +a completed withdraw operation (bank-integrated or manual) + +``Info``: + * amount wired (hidden if no fees) + * fees paid (hidden if no fees) + * total amount withdrawn into wallet (effective balance change) + * exchange base URL + * date + +``Actions``: + * delete: deletes information about the withdrawal operation + + +cta-url-entry +------------- + +``Description``: this screen allows the user to scan a QR code, scan an NFC +tag, or enter a taler://-URL. Its implementation may differ significantly +between platforms. For example, scanning NFC tags may be fully automated, +scanning QR codes may involve some system applications, and maybe the dialog +only allows the URL entry *or* the camera but not both at the same time, +depending on implementation specifics. + +``Info``: + * camera with current image to enable user to focus on QR code + * current URL, with information if it is not well-formed for GNU Taler + * possibly status information on NFC reader (if available) + +``Actions``: + * open: if entered manually, open URL as-entered (otherwise open is automatic) + * back: return to previous view + + cta-payment ------------- +----------- ``Description``: this screen is used for the confirmation of a payment to a merchant. the success of this operation will be an decrease of the balance in the wallet @@ -121,6 +175,25 @@ fee, restrictions and ETA should be clear for the user. * get more cash: if there is not enough balance, it will be redirected to ``cta-witddraw`` * cancel: user will be redirected to ``balance`` + +cta-payment-paid +---------------- + +``Description``: this screen is used to show information with details +about a historic payment. + +``Info``: + * merchant offering the order showing the URL + * order summary + * table of details of the operation: use the ``operation-table-details`` screen + * receipt: order id + * payment status: if the order was refunded + +``Actions``: + * delete: delete information about the transaction + * back: user will be redirected to ``balance`` + + cta-deposit ------------ diff --git a/screenshots/cta-payment-firefox-0.png b/screenshots/cta-payment-firefox-0.png new file mode 100644 index 00000000..c9d01380 Binary files /dev/null and b/screenshots/cta-payment-firefox-0.png differ diff --git a/screenshots/cta-payment-firefox-latest.png b/screenshots/cta-payment-firefox-latest.png new file mode 120000 index 00000000..26b0f16e --- /dev/null +++ b/screenshots/cta-payment-firefox-latest.png @@ -0,0 +1 @@ +cta-payment-firefox-0.png \ No newline at end of file diff --git a/screenshots/cta-payment-paid-firefox-0.png b/screenshots/cta-payment-paid-firefox-0.png new file mode 100644 index 00000000..f67e2af3 Binary files /dev/null and b/screenshots/cta-payment-paid-firefox-0.png differ diff --git a/screenshots/cta-payment-paid-firefox-latest.png b/screenshots/cta-payment-paid-firefox-latest.png new file mode 120000 index 00000000..22dd4530 --- /dev/null +++ b/screenshots/cta-payment-paid-firefox-latest.png @@ -0,0 +1 @@ +cta-payment-paid-firefox-0.png \ No newline at end of file diff --git a/screenshots/cta-url-entry-firefox-0.png b/screenshots/cta-url-entry-firefox-0.png new file mode 100644 index 00000000..ba98a8e4 Binary files /dev/null and b/screenshots/cta-url-entry-firefox-0.png differ diff --git a/screenshots/cta-url-entry-firefox-latest.png b/screenshots/cta-url-entry-firefox-latest.png new file mode 120000 index 00000000..f24b6cb8 --- /dev/null +++ b/screenshots/cta-url-entry-firefox-latest.png @@ -0,0 +1 @@ +cta-url-entry-firefox-0.png \ No newline at end of file diff --git a/screenshots/cta-wire-transfer-firefox-0.png b/screenshots/cta-wire-transfer-firefox-0.png new file mode 100644 index 00000000..7301cedc Binary files /dev/null and b/screenshots/cta-wire-transfer-firefox-0.png differ diff --git a/screenshots/cta-wire-transfer-firefox-latest.png b/screenshots/cta-wire-transfer-firefox-latest.png new file mode 120000 index 00000000..202edda1 --- /dev/null +++ b/screenshots/cta-wire-transfer-firefox-latest.png @@ -0,0 +1 @@ +cta-wire-transfer-firefox-0.png \ No newline at end of file diff --git a/screenshots/cta-withdraw-done-firefox-0.png b/screenshots/cta-withdraw-done-firefox-0.png new file mode 100644 index 00000000..3a3fc2f6 Binary files /dev/null and b/screenshots/cta-withdraw-done-firefox-0.png differ diff --git a/screenshots/cta-withdraw-done-firefox-latest.png b/screenshots/cta-withdraw-done-firefox-latest.png new file mode 120000 index 00000000..f707ff77 --- /dev/null +++ b/screenshots/cta-withdraw-done-firefox-latest.png @@ -0,0 +1 @@ +cta-withdraw-done-firefox-0.png \ No newline at end of file diff --git a/screenshots/cta-withdraw-firefox-0.png b/screenshots/cta-withdraw-firefox-0.png new file mode 100644 index 00000000..e75fb875 Binary files /dev/null and b/screenshots/cta-withdraw-firefox-0.png differ diff --git a/screenshots/cta-withdraw-firefox-latest.png b/screenshots/cta-withdraw-firefox-latest.png new file mode 120000 index 00000000..4ed704c3 --- /dev/null +++ b/screenshots/cta-withdraw-firefox-latest.png @@ -0,0 +1 @@ +cta-withdraw-firefox-0.png \ No newline at end of file -- cgit v1.2.3 From 7454c419dba44ce25165ca372856f4d37e7c06df Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 25 Feb 2024 17:01:16 +0100 Subject: add image links to DD53 --- design-documents/053-wallet-ui.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'design-documents') diff --git a/design-documents/053-wallet-ui.rst b/design-documents/053-wallet-ui.rst index 5c3ccb9e..c36d4759 100644 --- a/design-documents/053-wallet-ui.rst +++ b/design-documents/053-wallet-ui.rst @@ -115,6 +115,8 @@ the wire transfer to complete a manual withdrawal operation. * menu: go back to the main balances list (operation continues in background) * automatic: screen changes to "cta-withdraw-done" upon completion +.. image:: ../screenshots/cta-wire-transfer-firefox-latest.png + cta-withdraw-done ----------------- @@ -131,6 +133,8 @@ a completed withdraw operation (bank-integrated or manual) ``Actions``: * delete: deletes information about the withdrawal operation +.. image:: ../screenshots/cta-withdraw-done-firefox-latest.png + cta-url-entry ------------- @@ -151,6 +155,8 @@ depending on implementation specifics. * open: if entered manually, open URL as-entered (otherwise open is automatic) * back: return to previous view +.. image:: ../screenshots/cta-url-entry-firefox-latest.png + cta-payment ----------- @@ -175,6 +181,7 @@ fee, restrictions and ETA should be clear for the user. * get more cash: if there is not enough balance, it will be redirected to ``cta-witddraw`` * cancel: user will be redirected to ``balance`` +.. image:: ../screenshots/cta-payment-firefox-latest.png cta-payment-paid ---------------- @@ -193,6 +200,7 @@ about a historic payment. * delete: delete information about the transaction * back: user will be redirected to ``balance`` +.. image:: ../screenshots/cta-payment-paid-firefox-latest.png cta-deposit ------------ @@ -213,6 +221,7 @@ fee, restrictions and ETA should be clear for the user. .. attention:: User should be able to play with the amount, not possible in the current design + cta-peer-pull-initiate ---------------------- @@ -339,5 +348,8 @@ user already accepted ToS) * accept tos: will mark this version as accepted in wallet core and redirect the user to the screen from where it was invoked * save/print tos: will save the ToS outside of the wallet +.. image:: ../screenshots/cta-accept-tos-firefox-latest.png + + Q / A ===== -- cgit v1.2.3 From 6611af24895160a72aa2fdd69f54cd2cbff8f2bb Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Fri, 1 Mar 2024 00:49:55 +0100 Subject: dd55 --- design-documents/055-wallet-problem-report.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'design-documents') diff --git a/design-documents/055-wallet-problem-report.rst b/design-documents/055-wallet-problem-report.rst index a7ae783c..84c6159a 100644 --- a/design-documents/055-wallet-problem-report.rst +++ b/design-documents/055-wallet-problem-report.rst @@ -55,6 +55,7 @@ Types of reports * money lost due to the exchange stopping to offer a denomination * money locked behind a (long) pending refresh * money lost due to a permanently failing refresh +* money lost due to expired denominations (auto-refresh wasn't done fast enough) * exchange changed its master public key * a denomination changed its info (expiration, fees) -- cgit v1.2.3 From fde91a6d7c780ff2310567b7a3abcf97282fbbb1 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sat, 2 Mar 2024 22:05:35 +0100 Subject: misc fixes --- core/api-challenger.rst | 1 + core/api-common.rst | 2 ++ core/api-mailbox.rst | 3 +++ core/api-sync.rst | 1 + core/api-taldir.rst | 2 ++ core/index.rst | 2 +- design-documents/046-mumimo-contracts.rst | 15 +++++---------- index.rst | 2 +- taler-auditor-manual.rst | 1 + taler-challenger-manual.rst | 5 +++++ taler-exchange-manual.rst | 3 ++- taler-merchant-api-tutorial.rst | 1 + taler-merchant-manual.rst | 3 ++- taler-merchant-pos-terminal.rst | 1 + taler-user-guide.rst | 1 + taler-wallet.rst | 4 ++++ 16 files changed, 33 insertions(+), 14 deletions(-) (limited to 'design-documents') diff --git a/core/api-challenger.rst b/core/api-challenger.rst index 45fc5df8..914d8d01 100644 --- a/core/api-challenger.rst +++ b/core/api-challenger.rst @@ -88,6 +88,7 @@ Using the ``/info`` endpoint the client can then finally obtain the (now) verified address of the user. .. contents:: Table of Contents + :local: .. include:: tos.rst diff --git a/core/api-common.rst b/core/api-common.rst index bdf3ad81..51f2ab9f 100644 --- a/core/api-common.rst +++ b/core/api-common.rst @@ -24,6 +24,8 @@ Conventions for Taler RESTful APIs ================================== +.. contents:: Table of Contents + :local: ------------------------- HTTP Request and Response diff --git a/core/api-mailbox.rst b/core/api-mailbox.rst index 33db482d..34d27ded 100644 --- a/core/api-mailbox.rst +++ b/core/api-mailbox.rst @@ -29,6 +29,9 @@ for all details not specified in the individual requests. The `glossary `_ defines all specific terms used in this section. +.. contents:: Table of Contents + :local: + .. include:: tos.rst ------------------------- diff --git a/core/api-sync.rst b/core/api-sync.rst index 51d2b674..c2c86c23 100644 --- a/core/api-sync.rst +++ b/core/api-sync.rst @@ -103,6 +103,7 @@ user's location profiles by linking client IP addresses and client keys. .. contents:: Table of Contents + :local: .. include:: tos.rst diff --git a/core/api-taldir.rst b/core/api-taldir.rst index 1639e36d..4da9bb02 100644 --- a/core/api-taldir.rst +++ b/core/api-taldir.rst @@ -34,6 +34,8 @@ for all details not specified in the individual requests. The `glossary `_ defines all specific terms used in this section. +.. contents:: Table of Contents + :local: .. include:: tos.rst diff --git a/core/index.rst b/core/index.rst index d6a20244..8a764c10 100644 --- a/core/index.rst +++ b/core/index.rst @@ -32,7 +32,7 @@ protocols using JSON. .. toctree:: - :maxdepth: 2 + :maxdepth: 1 api-overview api-common diff --git a/design-documents/046-mumimo-contracts.rst b/design-documents/046-mumimo-contracts.rst index 5bc3d25a..fcb7f2b1 100644 --- a/design-documents/046-mumimo-contracts.rst +++ b/design-documents/046-mumimo-contracts.rst @@ -472,10 +472,7 @@ consumes an available discount token, that contract should be moved up in the list. Which specific alternative contract was chosen by the user is indicated in the -subcontract index field of the :ref:`TALER_DepositRequestPS`. - -FIXME-DOLD: Should we also sign over this in the -:ref:`TALER_DepositConfirmationPS`? +subcontract index field of the :ref:`TALER_DepositRequestPS `. Output Commitments @@ -483,8 +480,9 @@ Output Commitments When a contract has outputs, the wallet must send an array of blinded tokens, coins or tax receipts together with the payment request. The order in the -array must match the order in the outputs field of the contract. For currency outputs, one array element must include all of the required planchets for a batch withdrawal, -but of course not the reserve signature. +array must match the order in the outputs field of the contract. For currency +outputs, one array element must include all of the required planchets for a +batch withdrawal, but of course not the reserve signature. .. note:: @@ -492,10 +490,7 @@ but of course not the reserve signature. batch-withdraw API to only use a single reserve signature. This array of blinded values is hashed to create the output commitment hash -(``h_outputs``) in the :ref:`TALER_DepositRequestPS`. - -FIXME-DOLD: Should we also sign over this in the -:ref:`TALER_DepositConfirmationPS`? +(``h_outputs``) in the :ref:`TALER_DepositRequestPS `. diff --git a/index.rst b/index.rst index e97fe2b9..bd3b30d6 100644 --- a/index.rst +++ b/index.rst @@ -50,7 +50,7 @@ Documentation Overview .. toctree:: :numbered: - :maxdepth: 2 + :maxdepth: 1 core/index taler-user-guide diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst index cbc2aeff..94e86a8d 100644 --- a/taler-auditor-manual.rst +++ b/taler-auditor-manual.rst @@ -22,6 +22,7 @@ Auditor Operator Manual .. contents:: Table of Contents :depth: 1 + :local: Introduction diff --git a/taler-challenger-manual.rst b/taler-challenger-manual.rst index 3e4871cb..a7a7169f 100644 --- a/taler-challenger-manual.rst +++ b/taler-challenger-manual.rst @@ -20,6 +20,11 @@ Challenger Operator Manual ########################## +.. contents:: Table of Contents + :depth: 2 + :local: + + Introduction ============ diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst index dcbdba2c..57db7095 100644 --- a/taler-exchange-manual.rst +++ b/taler-exchange-manual.rst @@ -21,7 +21,8 @@ Exchange Operator Manual ######################## .. contents:: Table of Contents - :depth: 2 + :depth: 1 + :local: Introduction diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst index 02062464..15e21e21 100644 --- a/taler-merchant-api-tutorial.rst +++ b/taler-merchant-api-tutorial.rst @@ -24,6 +24,7 @@ Merchant API Tutorial .. contents:: Table of Contents :depth: 2 + :local: Introduction ============ diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst index 9925df0e..48605a55 100644 --- a/taler-merchant-manual.rst +++ b/taler-merchant-manual.rst @@ -22,7 +22,8 @@ Merchant Backend Operator Manual ################################ .. contents:: Table of Contents - :depth: 2 + :depth: 1 + :local: Introduction diff --git a/taler-merchant-pos-terminal.rst b/taler-merchant-pos-terminal.rst index 3077b63f..efc487cb 100644 --- a/taler-merchant-pos-terminal.rst +++ b/taler-merchant-pos-terminal.rst @@ -28,6 +28,7 @@ The GNU Taler merchant point of sale (POS) App allows sellers to .. contents:: Table of Contents :depth: 1 + :local: Android App diff --git a/taler-user-guide.rst b/taler-user-guide.rst index a74eae22..127218fb 100644 --- a/taler-user-guide.rst +++ b/taler-user-guide.rst @@ -21,6 +21,7 @@ User Guide .. contents:: Table of Contents :depth: 1 + :local: Introduction ============ diff --git a/taler-wallet.rst b/taler-wallet.rst index 5a10adc0..1d1a3991 100644 --- a/taler-wallet.rst +++ b/taler-wallet.rst @@ -19,6 +19,10 @@ Wallet Manual The GNU Taler wallet allows customers to withdraw and spend digital cash. +.. contents:: Table of Contents + :depth: 1 + :local: + WebExtension Wallet =================== -- cgit v1.2.3 From a57cdcc3e645276f1df4c232de82ad00a9c4cf4e Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Tue, 5 Mar 2024 11:24:58 +0100 Subject: delete DD --- design-documents/index.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'design-documents') diff --git a/design-documents/index.rst b/design-documents/index.rst index 03448acb..454564d0 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -67,5 +67,4 @@ Design documents that start with "XX" are considered deprecated. 053-wallet-ui.rst 054-dynamic-form.rst 055-wallet-problem-report.rst - 056-wallet-activity-diagnostics.rst 999-template -- cgit v1.2.3