View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0011446Talerdeployment and operationspublic2026-05-27 19:342026-06-10 18:43
Reportervecirex Assigned Tovecirex  
PriorityurgentSeverityblockReproducibilityhave not tried
Status resolvedResolutionfixed 
Summary0011446: Test KYC Auth reset via SQL [further testing: wip]
DescriptionDirectly related to 0011428, trying on TOPS/Stage if this works, i.e., doesn't create additional issues or even ends up w/ dysfunctional instances.

Three types of merchants shall be considered:

* kycauth_1_pending: merchant which entered an IBAN, but did not yet pay
* kycauth_2_kyc_ok: as above, but transfer fulfilled; exchange acceptance gotten
* kycauth_3_kyc_ok_and_withdraw: dito as w/ kycauth_2*, but additionally the merchant also acts as wallet user and withdrew money from the exchange he verified against as merchant, and doing so to the *very same IBAN* which was used as merchant (for IBAN settlements from paid orders)
TagsNo tags attached.

Relationships

related to 0011467 closedvecirex taler-merchant v1.6.0 seems to work, still do more tests 
related to 0011493 closedvecirex Test taler-merchant v1.6.2 (w/ taler-merchant-webui v1.6.4) 

Activities

vecirex

2026-05-29 19:08

manager   ~0028733

Last edited: 2026-05-29 19:09

 Following situation was created on TOPS/CHF stage (cf. https://docs.taler.net/deployments/tops-stage-devtesting.html):

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest,                                      
    k.access_token                                  
FROM merchant_kyc k                                              
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id ILIKE 'kyc%'
ORDER BY mi.merchant_id;
" 2>&1 | cat
SET
          merchant_id           |   business_name    | kyc_ok |   timestamp_cest    |                            access_token                            
--------------------------------+--------------------+--------+---------------------+--------------------------------------------------------------------
 kycauth_1_pending              | KYC Auth 1 Pending | f      | 2026-05-29 18:43:58 | 
 kycauth_1_pending              | KYC Auth 1 Pending | f      | 2026-05-29 18:43:58 | 
 kycauth_2_kyc_ok               | KYC Auth 2 KYC OK  | t      | 2026-05-29 18:47:22 | \xb0e861480d1aac501c2dccee4a8e4a24961434230017bc133f2ee30100b1fa87
 kycauth_2_kyc_ok               | KYC Auth 2 KYC OK  | f      | 2026-05-29 18:43:58 | 
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester       | t      | 2026-05-29 18:55:00 | \x036cbe036d4937c0f963ce76b98b72d93bf00cd47f9fff7a41b8e695ffd6463f
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester       | f      | 2026-05-29 18:52:28 | 
(6 rows)

vecirex

2026-05-29 19:45

manager   ~0028734

Last edited: 2026-05-29 20:27

 0. Backup DB, even if it's "only" stage

sudo -u postgres pg_dumpall > /root/backups/postgres-backup-$EPOCHSECONDS.sql
sudo -u taler-merchant-httpd pg_dump taler-merchant > /root/backups/taler-merchant-backup-$EPOCHSECONDS.sql


1. Test for kycauth_1_pending

1a. DB situation w/ relevant KYC fields found:

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    k.kyc_timestamp,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest, 
    k.access_token,
    k.exchange_url,
    k.exchange_http_status,
    k.exchange_ec_code,
    k.next_kyc_poll,
    k.kyc_backoff
FROM merchant_kyc k
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id = 'kycauth_1_pending';
" 2>&1 | cat
SET
    merchant_id    |   business_name    | kyc_ok |  kyc_timestamp   |   timestamp_cest    | access_token |             exchange_url             | exchange_http_status | exchange_ec_code |  next_kyc_poll   | kyc_backoff 
-------------------+--------------------+--------+------------------+---------------------+--------------+--------------------------------------+----------------------+------------------+------------------+-------------
 kycauth_1_pending | KYC Auth 1 Pending | f      | 1780073038000000 | 2026-05-29 18:43:58 |              | https://exchange.stage.taler-ops.ch/ |                    0 |               10 | 1780074838551502 |  1800000000
 kycauth_1_pending | KYC Auth 1 Pending | f      | 1780073038000000 | 2026-05-29 18:43:58 |              | https://exchange.taler-ops.ch/       |                    0 |               10 | 1780074838550415 |  1800000000
(2 rows)


1b. Tentative KYC Reset

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
BEGIN;

UPDATE merchant_kyc
SET 
    access_token = NULL,
    kyc_ok = FALSE,
    kyc_timestamp = 0,
    exchange_http_status = 0,
    exchange_ec_code = 0,
    next_kyc_poll = 0,
    kyc_backoff = 0
WHERE account_serial IN (
    SELECT ma.account_serial 
    FROM merchant_accounts ma
    JOIN merchant_instances mi USING (merchant_serial)
    WHERE mi.merchant_id = 'kycauth_1_pending'
);

COMMIT;

SELECT 'KYC reset completed for instance:' AS status, 'kycauth_1_pending' AS instance" 2>&1 | cat
SET
BEGIN
UPDATE 2
COMMIT
              status               |     instance      
-----------------------------------+-------------------
 KYC reset completed for instance: | kycauth_1_pending
(1 row)


1c. Restart of taler-merchant-httpd, and check if it's running:

systemctl restart taler-merchant-httpd
systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.


1d. Check DB entries

Looks fine, most notably time is changed, that is, including next KYC poll attempt, shown in Zurich / CEST time:

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    k.kyc_timestamp,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest,
    k.access_token,
    k.exchange_url,
    k.exchange_http_status,
    k.exchange_ec_code,
    to_timestamp(k.next_kyc_poll / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_kyc_poll_cest, 
    k.kyc_backoff
FROM merchant_kyc k                                              
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id = 'kycauth_1_pending';
" 2>&1 | cat
SET
    merchant_id    |   business_name    | kyc_ok |  kyc_timestamp   |   timestamp_cest    | access_token |             exchange_url             | exchange_http_status | exchange_ec_code | timestamp_kyc_poll_cest | kyc_backoff 
-------------------+--------------------+--------+------------------+---------------------+--------------+--------------------------------------+----------------------+------------------+-------------------------+-------------
 kycauth_1_pending | KYC Auth 1 Pending | f      | 1780076639000000 | 2026-05-29 19:43:59 |              | https://exchange.stage.taler-ops.ch/ |                    0 |               10 | 2026-05-29 19:46:23     |  1800000000
 kycauth_1_pending | KYC Auth 1 Pending | f      | 1780076639000000 | 2026-05-29 19:43:59 |              | https://exchange.taler-ops.ch/       |                    0 |               10 | 2026-05-29 19:46:23     |  1800000000
(2 rows)


1e. Check merchant portal

Nothing specially noted, KYC still shown as pending, also KYC:* string w/ public key for wire transfer remains stable.

vecirex

2026-05-29 20:00

manager   ~0028735

Last edited: 2026-05-29 20:27

 2. Test for kycauth_2_kyc_ok

2a. DB situation w/ relevant KYC fields found

Note that for the exchange case where KYC is done, there's no real next KYC poll time in the near future; both timestamps are equal:

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    k.kyc_timestamp,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest,
    k.access_token,
    k.exchange_url,
    k.exchange_http_status,
    k.exchange_ec_code,
    to_timestamp(k.next_kyc_poll / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_kyc_poll_cest,
    k.kyc_backoff
FROM merchant_kyc k                                              
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id = 'kycauth_2_kyc_ok';
" 2>&1 | cat
SET
   merchant_id    |   business_name   | kyc_ok |  kyc_timestamp   |   timestamp_cest    |                            access_token                            |             exchange_url             | exchange_http_status | exchange_ec_code | timestamp_kyc_poll_cest | kyc_backoff 
------------------+-------------------+--------+------------------+---------------------+--------------------------------------------------------------------+--------------------------------------+----------------------+------------------+-------------------------+-------------
 kycauth_2_kyc_ok | KYC Auth 2 KYC OK | t      | 1780076785000000 | 2026-05-29 19:46:25 | \xb0e861480d1aac501c2dccee4a8e4a24961434230017bc133f2ee30100b1fa87 | https://exchange.stage.taler-ops.ch/ |                  200 |                0 | 2026-05-29 19:46:25     |    60000000
 kycauth_2_kyc_ok | KYC Auth 2 KYC OK | f      | 1780076639000000 | 2026-05-29 19:43:59 |                                                                    | https://exchange.taler-ops.ch/       |                    0 |               10 | 2026-05-29 19:49:48     |   348885239
(2 rows)


2b. Tentative KYC Reset

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
BEGIN;

UPDATE merchant_kyc
SET 
    access_token = NULL,
    kyc_ok = FALSE,
    kyc_timestamp = 0,
    exchange_http_status = 0,
    exchange_ec_code = 0,
    next_kyc_poll = 0,
    kyc_backoff = 0
WHERE account_serial IN (
    SELECT ma.account_serial 
    FROM merchant_accounts ma
    JOIN merchant_instances mi USING (merchant_serial)
    WHERE mi.merchant_id = 'kycauth_2_kyc_ok'
);

COMMIT;

SELECT 'KYC reset completed for instance:' AS status, 'kycauth_2_kyc_ok' AS instance" 2>&1 | cat
SET
BEGIN
UPDATE 2
COMMIT
              status               |     instance     
-----------------------------------+------------------
 KYC reset completed for instance: | kycauth_2_kyc_ok
(1 row)


2c. Restart of taler-merchant-httpd, and check if it's running

Looks fine:

systemctl restart taler-merchant-httpd
systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.


2d. Check DB entries

At first, doesn't look very promising, w/ timestamps equally everywhere at UNIX time zero:

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    k.kyc_timestamp,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest,
    k.access_token,
    k.exchange_url,
    k.exchange_http_status,
    k.exchange_ec_code,
    to_timestamp(k.next_kyc_poll / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_kyc_poll_cest,
    k.kyc_backoff
FROM merchant_kyc k
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id = 'kycauth_2_kyc_ok';
" 2>&1 | cat
SET
   merchant_id    |   business_name   | kyc_ok | kyc_timestamp |   timestamp_cest    | access_token |             exchange_url             | exchange_http_status | exchange_ec_code | timestamp_kyc_poll_cest | kyc_backoff 
------------------+-------------------+--------+---------------+---------------------+--------------+--------------------------------------+----------------------+------------------+-------------------------+-------------
 kycauth_2_kyc_ok | KYC Auth 2 KYC OK | f      |             0 | 1970-01-01 01:00:00 |              | https://exchange.stage.taler-ops.ch/ |                    0 |                0 | 1970-01-01 01:00:00     |           0
 kycauth_2_kyc_ok | KYC Auth 2 KYC OK | f      |             0 | 1970-01-01 01:00:00 |              | https://exchange.taler-ops.ch/       |                    0 |                0 | 1970-01-01 01:00:00     |           0
(2 rows)


In about a minute after, however, situation stabilizes and KYC OK status is indeed reflected again:

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    k.kyc_timestamp,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest,
    k.access_token,
    k.exchange_url,
    k.exchange_http_status,
    k.exchange_ec_code,
    to_timestamp(k.next_kyc_poll / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_kyc_poll_cest,
    k.kyc_backoff
FROM merchant_kyc k
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id = 'kycauth_2_kyc_ok';
" 2>&1 | cat
SET
   merchant_id    |   business_name   | kyc_ok |  kyc_timestamp   |   timestamp_cest    |                            access_token                            |             exchange_url             | exchange_http_status | exchange_ec_code | timestamp_kyc_poll_cest | kyc_backoff 
------------------+-------------------+--------+------------------+---------------------+--------------------------------------------------------------------+--------------------------------------+----------------------+------------------+-------------------------+-------------
 kycauth_2_kyc_ok | KYC Auth 2 KYC OK | t      | 1780078443000000 | 2026-05-29 20:14:03 | \xb0e861480d1aac501c2dccee4a8e4a24961434230017bc133f2ee30100b1fa87 | https://exchange.stage.taler-ops.ch/ |                  200 |                0 | 2026-05-29 20:16:24     |    60000000
 kycauth_2_kyc_ok | KYC Auth 2 KYC OK | f      |                0 | 1970-01-01 01:00:00 |                                                                    | https://exchange.taler-ops.ch/       |                    0 |                0 | 2026-05-29 20:16:24     |           0
(2 rows)


From a cosmetic perspective or to keep more up w/ reality, first timestamp could be set to current time instead of going towards "year zero":

2e. Check merchant portal

KYC situation looks fine / the same as before.

vecirex

2026-05-29 22:43

manager   ~0028739

Last edited: 2026-05-29 23:15

 3. Test for kycauth_3_kyc_ok_with_withdraw

3a. DB situation w/ relevant KYC fields found

Similar foundings as for 2a. above, while not equivalent as what concerns timestamps:

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    k.kyc_timestamp,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest,
    k.access_token,
    k.exchange_url,
    k.exchange_http_status,
    k.exchange_ec_code,
    to_timestamp(k.next_kyc_poll / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_kyc_poll_cest,
    k.kyc_backoff
FROM merchant_kyc k                                              
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id = 'kycauth_3_kyc_ok_with_withdraw';
" 2>&1 | cat
SET
          merchant_id           | business_name | kyc_ok |  kyc_timestamp   |   timestamp_cest    | access_token |             exchange_url             | exchange_http_status | exchange_ec_code | timestamp_kyc_poll_cest | kyc_backoff 
--------------------------------+---------------+--------+------------------+---------------------+--------------+--------------------------------------+----------------------+------------------+-------------------------+-------------
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester  | t      | 1780087444000000 | 2026-05-29 22:44:04 |              | https://exchange.stage.taler-ops.ch/ |                    0 |               10 | 2026-05-29 22:46:20     |   136560000
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester  | f      | 1780087444000000 | 2026-05-29 22:44:04 |              | https://exchange.taler-ops.ch/       |                    0 |               10 | 2026-05-29 23:09:29     |  1525162030
(2 rows)


3b. Tentative KYC Reset

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
BEGIN;

UPDATE merchant_kyc
SET 
    access_token = NULL,
    kyc_ok = FALSE,
    kyc_timestamp = 0,
    exchange_http_status = 0,
    exchange_ec_code = 0,
    next_kyc_poll = 0,
    kyc_backoff = 0
WHERE account_serial IN (
    SELECT ma.account_serial 
    FROM merchant_accounts ma
    JOIN merchant_instances mi USING (merchant_serial)
    WHERE mi.merchant_id = 'kycauth_3_kyc_ok_with_withdraw'
);

COMMIT;

SELECT 'KYC reset completed for instance:' AS status, 'kycauth_3_kyc_ok_with_withdraw' AS instance" 2>&1 | cat
SET
BEGIN
UPDATE 2
COMMIT
              status               |            instance            
-----------------------------------+--------------------------------
 KYC reset completed for instance: | kycauth_3_kyc_ok_with_withdraw
(1 row)


3c. Restart of taler-merchant-httpd, and check if it's running

Fine:

systemctl restart taler-merchant-httpd
systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.


3d. Check DB entries

First, like for 2d. above:

 sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    k.kyc_timestamp,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest,
    k.access_token,
    k.exchange_url,
    k.exchange_http_status,
    k.exchange_ec_code,
    to_timestamp(k.next_kyc_poll / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_kyc_poll_cest,
    k.kyc_backoff
FROM merchant_kyc k                                              
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id = 'kycauth_3_kyc_ok_with_withdraw';
" 2>&1 | cat
SET
          merchant_id           | business_name | kyc_ok | kyc_timestamp |   timestamp_cest    | access_token |             exchange_url             | exchange_http_status | exchange_ec_code | timestamp_kyc_poll_cest | kyc_backoff 
--------------------------------+---------------+--------+---------------+---------------------+--------------+--------------------------------------+----------------------+------------------+-------------------------+-------------
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester  | f      |             0 | 1970-01-01 01:00:00 |              | https://exchange.stage.taler-ops.ch/ |                    0 |                0 | 1970-01-01 01:00:00     |           0
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester  | f      |             0 | 1970-01-01 01:00:00 |              | https://exchange.taler-ops.ch/       |                    0 |                0 | 1970-01-01 01:00:00     |           0
(2 rows)


No quick change as in 2d., however: when logging in, a timestamp change can be observed, but no change in showing that KYC is already OK towards the stage exchange:

sudo -u taler-merchant-httpd psql taler-merchant -c "
SET search_path TO merchant;
SELECT 
    mi.merchant_id,
    mi.merchant_name AS business_name,
    k.kyc_ok,
    k.kyc_timestamp,
    to_timestamp(k.kyc_timestamp / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_cest,
    k.access_token,
    k.exchange_url,
    k.exchange_http_status,
    k.exchange_ec_code,
    to_timestamp(k.next_kyc_poll / 1000000) AT TIME ZONE 'Europe/Zurich' AS timestamp_kyc_poll_cest,
    k.kyc_backoff
FROM merchant_kyc k                                              
JOIN merchant_accounts ma ON k.account_serial = ma.account_serial
JOIN merchant_instances mi USING (merchant_serial)
WHERE mi.merchant_id = 'kycauth_3_kyc_ok_with_withdraw';
" 2>&1 | cat
SET
          merchant_id           | business_name | kyc_ok | kyc_timestamp |   timestamp_cest    | access_token |             exchange_url             | exchange_http_status | exchange_ec_code | timestamp_kyc_poll_cest | kyc_backoff 
--------------------------------+---------------+--------+---------------+---------------------+--------------+--------------------------------------+----------------------+------------------+-------------------------+-------------
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester  | f      |             0 | 1970-01-01 01:00:00 |              | https://exchange.stage.taler-ops.ch/ |                    0 |                0 | 2026-05-29 22:52:54     |           0
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester  | f      |             0 | 1970-01-01 01:00:00 |              | https://exchange.taler-ops.ch/       |                    0 |                0 | 2026-05-29 22:52:54     |           0
(2 rows)


3e. Check merchant portal

After about 10mins of taler-merchant-httpd being active, there's still no recovery of the situation for this third instance: indeed, KYC is being offered again.

3f. Check taler-merchant-httpd logs

It's reflected in the logs, indeed, that instance 3 used for withdraw and for being a merchant from and to the same exchange using the very same IBAN (no real account, used in stage), doesn't get its actual KYC status recovered:

[...]
May 29 22:58:38 betel taler-merchant-httpd[17959]: (HBXE7KS1NKCX7YWWMPQ8P4SDVW) INFO Handling request (GET) for URL '/instances/kycauth_3_kyc_ok_with_withdraw/private/accounts'
May 29 22:58:38 betel taler-merchant-httpd[17959]: (HBXE7KS1NKCX7YWWMPQ8P4SDVW) INFO Request for `/instances/kycauth_3_kyc_ok_with_withdraw/private/accounts' completed with HTTP status 200 (0)
May 29 22:58:38 betel taler-merchant-httpd[17959]: (C84QP2NJJ57ZSWSBM3E0JWFQ7R) INFO Handling request (GET) for URL '/instances/kycauth_3_kyc_ok_with_withdraw/config'
May 29 22:58:38 betel taler-merchant-httpd[17959]: (C84QP2NJJ57ZSWSBM3E0JWFQ7R) INFO Request for `/instances/kycauth_3_kyc_ok_with_withdraw/config' completed with HTTP status 200 (0)
May 29 22:58:38 betel taler-merchant-httpd[17959]: (8X53Y4MF2BAA7E0ZPWAN9ZBYFG) INFO Handling request (GET) for URL '/instances/kycauth_3_kyc_ok_with_withdraw/private/kyc'
May 29 22:58:38 betel taler-merchant-httpd[17959]: (8X53Y4MF2BAA7E0ZPWAN9ZBYFG) INFO KYC status requested for format application/json
May 29 22:58:38 betel taler-merchant-httpd[17959]: (8X53Y4MF2BAA7E0ZPWAN9ZBYFG) INFO Checking KYC status for kycauth_3_kyc_ok_with_withdraw (0/(null))
May 29 22:58:38 betel taler-merchant-httpd[17959]: (8X53Y4MF2BAA7E0ZPWAN9ZBYFG) INFO Got 2 KYC records
May 29 22:58:38 betel taler-merchant-httpd[17959]: (8X53Y4MF2BAA7E0ZPWAN9ZBYFG) INFO KYC status for `payto://iban/CH6690986631600451656?receiver-name=Tammy%20Tester' at `https://exchange.stage.taler-ops.ch/' is 0/KYC NEEDED/NO AML REVIEW/CUSTOM LIMITS
May 29 22:58:38 betel taler-merchant-httpd[17959]: (8X53Y4MF2BAA7E0ZPWAN9ZBYFG) INFO KYC status for `payto://iban/CH6690986631600451656?receiver-name=Tammy%20Tester' at `https://exchange.taler-ops.ch/' is 0/KYC NEEDED/NO AML REVIEW/DEFAULT LIMITS
[...]

Christian Grothoff

2026-05-30 07:55

manager   ~0028741

Eh, but in situation #3 we WANT the user to be offered KYC (finally) as they never could have done the KYC Auth before and must do it!

vecirex

2026-06-04 19:33

manager   ~0028785

Continue tests under taler-merchant v1.6.0+, now relevant: rel ticket accordingly.

vecirex

2026-06-10 14:42

manager   ~0028836

After changed DB scheme w/ more recent versions of taler-merchant v1.6.x (here: v1.6.2), kycauth_2_kyc_ok account (only one of the three w/ KYC OK status) still shows up w/ verified account: good!
Bildschirmfoto 2026-06-10 um 14.39.54.png (242,099 bytes)   
Bildschirmfoto 2026-06-10 um 14.39.54.png (242,099 bytes)   

vecirex

2026-06-10 15:22

manager   ~0028838

Last edited: 2026-06-10 18:42

 Oh, apparently kycauth_3_kyc_ok_with_withdraw also appears w/ KYC OK.

This is also reflected in the new DB scheme; first of all identifying the new schemes for the three instances:

### root@betel:~# sudo -u taler-merchant-httpd psql taler-merchant -c "
WITH kyc1 AS (
SELECT k, kyc_timestamp, access_token 
  mi.merchant_id,                                                                
  mi.merchant_name,
),'merchant_instance_' || mi.merchant_serial AS schema_name
FROM merchant.merchant_instances mi
WHERE mi.merchant_id ILIKE 'kyc%'
ORDER BY mi.merchant_id;
"
          merchant_id           |   merchant_name    |     schema_name      
--------------------------------+--------------------+----------------------
 kycauth_1_pending              | KYC Auth 1 Pending | merchant_instance_23
 kycauth_2_kyc_ok               | KYC Auth 2 KYC OK  | merchant_instance_24
 kycauth_3_kyc_ok_with_withdraw | Tammy Tester       | merchant_instance_25
(3 rows)

### root@betel:~#


Then, this is shown -- and also in the UI it's reflected correctly now!

### root@betel:~# sudo -u taler-merchant-httpd psql taler-merchant -c "
WITH all_kyc AS (
  SELECT 
    'kycauth_1_pending' as merchant_id,
    kyc_ok,
    kyc_timestamp,
    access_token,
    kyc_serial_id
  FROM merchant_instance_23.merchant_kyc
  UNION ALL
  SELECT 
    'kycauth_2_kyc_ok',
    kyc_ok,
    kyc_timestamp,
    access_token,
    kyc_serial_id
  FROM merchant_instance_24.merchant_kyc
  UNION ALL
  SELECT 
    'kycauth_3_kyc_ok_with_withdraw',
    kyc_ok,
    kyc_timestamp,
    access_token,
    kyc_serial_id
  FROM merchant_instance_25.merchant_kyc
)
" 2>&1 | cat
          merchant_id           | kyc_ok |   timestamp_cest    |            access_token             
--------------------------------+--------+---------------------+-------------------------------------
 kycauth_1_pending              | f      | 2026-06-10 13:58:09 | 
 kycauth_1_pending              | f      | 2026-06-10 12:58:07 | 
 kycauth_2_kyc_ok               | f      | 2026-06-10 04:01:37 | 
 kycauth_2_kyc_ok               | t      | 2026-06-05 15:49:56 | b0e861480d1aac501c2dccee4a8e4a24...
 kycauth_3_kyc_ok_with_withdraw | f      | 2026-06-10 04:01:37 | 
 kycauth_3_kyc_ok_with_withdraw | t      | 2026-06-05 15:49:56 | 036cbe036d4937c0f963ce76b98b72d9...
(6 rows)

### root@betel:~#
Bildschirmfoto 2026-06-10 um 15.17.24.png (266,260 bytes)

vecirex

2026-06-10 18:41

manager   ~0028846

Test case w/ kycauth_3* account having two IBAN numbers w/ KYC OK.

Deleting the values in merchant_instance_25.merchant_kyc values, effectively does the KYC reset:

### root@betel:~# sudo -u taler-merchant-httpd psql taler-merchant -c "
DELETE FROM merchant_instance_25.merchant_kyc;"
DELETE 4
### root@betel:~#


For a short period of time, exchanges show unavailable (screenshot 1), but then the system recovers, either in within some minutes showing the already KYCed accounts as ready again (screenshot 2), or, if it shall be immediate, go for this:

### root@betel:~# sudo -u taler-merchant-httpd -s /bin/bash
taler-merchant-httpd@betel:/root$ taler-merchant-kyccheck -t
taler-merchant-httpd@betel:/root$
Bildschirmfoto 2026-06-10 um 18.36.07.png (248,611 bytes)   
Bildschirmfoto 2026-06-10 um 18.36.07.png (248,611 bytes)   
Bildschirmfoto 2026-06-10 um 18.41.12.png (213,443 bytes)   
Bildschirmfoto 2026-06-10 um 18.41.12.png (213,443 bytes)   

Issue History

Date Modified Username Field Change
2026-05-27 19:34 vecirex New Issue
2026-05-27 19:34 vecirex Description Updated
2026-05-27 19:35 vecirex Assigned To => vecirex
2026-05-27 19:35 vecirex Status new => assigned
2026-05-27 19:38 vecirex Description Updated
2026-05-27 19:38 vecirex Description Updated
2026-05-29 19:08 vecirex Note Added: 0028733
2026-05-29 19:09 vecirex Note Edited: 0028733
2026-05-29 19:10 vecirex Steps to Reproduce Updated
2026-05-29 19:10 vecirex Additional Information Updated
2026-05-29 19:45 vecirex Note Added: 0028734
2026-05-29 19:56 vecirex Note Edited: 0028734
2026-05-29 19:57 vecirex Note Edited: 0028734
2026-05-29 19:57 vecirex Status assigned => feedback
2026-05-29 20:00 vecirex Note Added: 0028735
2026-05-29 20:00 vecirex Note Edited: 0028735
2026-05-29 20:00 vecirex Note Edited: 0028734
2026-05-29 20:08 vecirex Note Edited: 0028735
2026-05-29 20:12 vecirex Note Edited: 0028735
2026-05-29 20:22 vecirex Note Edited: 0028735
2026-05-29 20:27 vecirex Note Edited: 0028735
2026-05-29 20:27 vecirex Note Edited: 0028734
2026-05-29 22:43 vecirex Note Added: 0028739
2026-05-29 22:44 vecirex Note Edited: 0028739
2026-05-29 22:57 vecirex Note Edited: 0028739
2026-05-29 22:57 vecirex Note Edited: 0028739
2026-05-29 23:01 vecirex Note Edited: 0028739
2026-05-29 23:15 vecirex Note Edited: 0028739
2026-05-30 07:55 Christian Grothoff Note Added: 0028741
2026-06-03 13:34 vecirex Summary Test KYC Auth reset via SQL => Test KYC Auth reset via SQL [further testing: wip]
2026-06-04 10:31 vecirex Relationship added related to 0011467
2026-06-04 19:33 vecirex Note Added: 0028785
2026-06-04 19:33 vecirex Relationship replaced child of 0011467
2026-06-04 19:34 vecirex Relationship replaced related to 0011467
2026-06-10 14:42 vecirex Note Added: 0028836
2026-06-10 14:42 vecirex File Added: Bildschirmfoto 2026-06-10 um 14.39.54.png
2026-06-10 14:50 vecirex Relationship added related to 0011493
2026-06-10 15:22 vecirex Note Added: 0028838
2026-06-10 15:22 vecirex File Added: Bildschirmfoto 2026-06-10 um 15.17.24.png
2026-06-10 18:40 vecirex File Deleted: Bildschirmfoto 2026-06-10 um 18.36.07-2.png
2026-06-10 18:40 vecirex File Deleted: Bildschirmfoto 2026-06-10 um 18.36.07.png
2026-06-10 18:41 vecirex Note Added: 0028846
2026-06-10 18:41 vecirex File Added: Bildschirmfoto 2026-06-10 um 18.36.07.png
2026-06-10 18:41 vecirex File Added: Bildschirmfoto 2026-06-10 um 18.41.12.png
2026-06-10 18:42 vecirex Note Edited: 0028838
2026-06-10 18:43 vecirex Status feedback => resolved
2026-06-10 18:43 vecirex Resolution open => fixed