MantisBT - Issues

0011484: Notify merchants of relevant changes to the instance (like IBAN no.)

Sat, 06 Jun 2026 04:08:27 +0200

Regardless of who did the changes, alterations of relevant information like the IBAN(s) used (where paid orders go to, by settlements) should be accompanied by notifications to the tan channels defined, like sms and email.

0011483: Adding another IBAN requires MFA, but can be circumvented

Sat, 06 Jun 2026 04:08:27 +0200

Adding ticket via and confirmed by fd during yesterday's QC session:

Being logged in, adding an additional IBAN acc. requires one additional factor (sms or email, given taler-merchant has tan methods activated by config; like for mytops).

This makes sense because an actor (like employee or just any attacker with access to the the open screen) could try to redirect money to his very own account, by just adding another IBAN. By a tan method being required, most attackers would be prevented from doing so.

However, it's possible to just delete the first IBAN added and replace it by the "second" one, or: the security model is broken, because in this case no tan method is required.

0011482: Android wallet should support prepared transfers for withdrawals and KYC auth via transferOptions

Fri, 05 Jun 2026 16:38:23 +0200

The exchange now supports wire transfers (for withdrawals and KYC auth) that include a shorter subject instead of the full reserve public key.

This short subject may need to be included in specific fields (such as the QR Reference for Switzerland) of the payment.

Wallet-core now supports generating appropriate QR codes for the new transfer options. They are exposed in the transaction details via:
* withdrawalDetails.transferOptions for withdrawals
* kycAuthTransferOptions for KYC auth transfers

0011481: WebExtension wallet should support prepared transfers for withdrawals and KYC auth via transferOptions

Fri, 05 Jun 2026 16:38:23 +0200

0011480: iOS wallet should support prepared transfers for withdrawals and KYC auth via transferOptions

Fri, 05 Jun 2026 16:38:10 +0200

0011479: wallet-core does not support prepared transfers for KYC auth transfers

Fri, 05 Jun 2026 16:29:21 +0200

It only supports it for withdrawals, but we also require it for KYC auth transfers

0011478: Apps should automatically adopt amount from Template Link for xOTP / MDB devices

Fri, 05 Jun 2026 15:51:43 +0200

To support further work with xOTP/MDB devices, it would be beneficial if the mobile applications (iOS and Android) could directly take over and process the amount specified in the template link.

Example Link:
taler://pay-template/backend.demo.taler.net/instances/sandbox/xOTP_MDB?amount=KUDOS:0.1&nfc=1

Currently, this feature is not implemented in the backend/apps, meaning the 'amount' parameter is ignored and the default value from the backend is displayed instead.

Expected Behavior:
1. When a template link containing an amount parameter (e.g., ?amount=KUDOS:0.1) is opened, the app should automatically parse and pre-fill that amount for the transaction.
2. The pre-filled amount must be locked and NOT changeable by the user.
3. Immediately after reading the link and parsing the data, the app should skip any intermediate steps and open the confirmation screen directly.

0011477: Implement NFC Confirmation Code Transmission with NFC

Fri, 05 Jun 2026 15:51:31 +0200

To achieve feature parity with the iOS application, the Android app needs to support sending received confirmation codes to the xOTP Generator/MDB via NFC.
Technical Specifications:
- Format: NDEF (Text format)
- Encoding: Raw 4-byte values
- Identifier Value: 0x42 ('B') as first byte
- Payload Size: 21 bytes expected
- Order: Big-endian / MSB first

0011476: taler-pkg should generate debian changelog and support dev versions

Fri, 05 Jun 2026 13:23:49 +0200

We want to address two issues with this:
* Right now every component needs to bump their debian changelog whenever there's a release or even dev release. That's tedious and not helpful.
* Even for testing minor changes in our staging environment, we need to do a full patch tag, which doesn't lend itself well to testing experimental changes

The taler-pkg tooling should support `.dev-$n` versions and also just generate the changelog file.

0010153: list all the ui screens that require support for multi-currency

Thu, 04 Jun 2026 22:52:38 +0200

this is a parent issue

we need 2 list of ui screens:
1) where multi-currency affects the information show
2) where the mult-currency affects the behavior (new validations, checks, options)

a third list of ui screens will be interesting considering what happen if the show element (order, template, product, wiretransfer, supported exchange, bank accounts) does any of this screen requires additional warning / behavior when the element doesn't have the supported currency?

0011454: eddsa helper process shuts down unexpectedly

Thu, 04 Jun 2026 22:51:14 +0200

In one particular harness test, the eddsa helper process shuts down unsolicitedly while the test is still running and uses the exchange.

0011405: cannot delete locked products

Thu, 04 Jun 2026 22:23:51 +0200

While a product is locked (used in an order), it cannot be deleted in the SPA.
(1) the error message shown is just about a generic 'conflict', while the backend gives a better EC-based hint. Returning an error message that the product is locked / part of an unpaid order would be helpful.
(2) if the backend gets the 409, it should offer the user the option to force delete (?force=yes) the product anyway.

0011467: taler-merchant v1.6.0 seems to work, still do more tests

Thu, 04 Jun 2026 19:34:30 +0200

Current taler-merchant/testing is v1.6.0: while it seems to work fine for existing instances, check also if new instances incl. KYC Auth works properly, which fits to other testing work ongoing.

0011446: Test KYC Auth reset via SQL [further testing: wip]

Thu, 04 Jun 2026 19:34:30 +0200

Directly 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)

0011474: show a loading spinner while challenge is being sent

Thu, 04 Jun 2026 18:26:37 +0200

so user knows that the app is waiting for a response

0011415: outofstock response makes no sense [2h]

Thu, 04 Jun 2026 17:44:58 +0200

create product with stock 10
create an order with 1 item, i didnt pay it
create a new order with 10 items

expected: outofstock with available_quantity 9
got available_quantity 10

the response 410 is ok but the content is not right

curl 'https://merchant.taler/private/orders' \
-H 'Authorization: Bearer secret-token:K7CA85NRKN38NKT2DNSGG0SVEQVKP29H4B3D29G81EQY54QTMPW0' \
--data-raw '{"order":{"version":0,"amount":"CHF:10","summary":"sd","products":[],"pay_deadline":{"t_s":1779104124},"refund_deadline":{"t_s":1779104184},"wire_transfer_deadline":{"t_s":1779104244}},"inventory_products":[{"product_id":"we","quantity":10}],"create_token":true}'

{
"product_id": "we",
"requested_quantity": 10,
"unit_requested_quantity": "10",
"available_quantity": 10,
"unit_available_quantity": "10"
}

0011473: taler-merchant v1.6.0 might show a taler-merchant-dbinit-gc.service systemd unit failure

Thu, 04 Jun 2026 17:05:08 +0200

Error looking like this:

systemctl --failed
  UNIT                             LOAD   ACTIVE SUB    DESCRIPTION                                                            >
● taler-merchant-dbinit-gc.service loaded failed failed Job to remove stale data from the taler-merchant database (run as a tim>

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

1 loaded units listed.

0011472: In DE (at least): Confusing text at phone no. field when creating instance

Thu, 04 Jun 2026 16:48:29 +0200

The text is confusing, because this number is supposed to be a mobile phone number and not just any generic number.

0011470: regression: taler-merchant v1.6.0 shows "admin" user in the "creation" auth codes sent by email

Thu, 04 Jun 2026 15:52:35 +0200

We had this already in the past, now it came up again in newest taler-merchant.

0011400: WebExtension "abort" without reaction

Wed, 03 Jun 2026 22:33:05 +0200

Seen while trying to receive a p2p payment from an iOS device, which was shown in the browser's Talet wallet as "pending to complete".

0011367: double-spending fun with pending transactions

Wed, 03 Jun 2026 22:25:59 +0200

Torsten on iphone managed the following:

- Balance: 5 CHF
- p2p send: 4.5 CHF -- transaction: pending (receiver did not yet accept)
- p2p send AGAIN: 4.5 CHF *allowed* -- failed to generate QR code (but did NOT say insufficient balance)

Main screen then shows 9 CHF outgoing pending transactions with 5 CHF balance.
Abort 1st transaction -- hangs in cancellation.
Abort 2st transaction -- also hangs in cancellation.

AFAIK full balance is not inaccessible to the user.

0011465: remove prospective coin selection feature from the wallet

Wed, 03 Jun 2026 22:25:43 +0200

In the current version of the wallet (1.5.x) it is possible to confirm payments even when the required funds are locked behind a pending refresh.

However, in practice this feature has resulted in lots of complexity and bad error reporting.

The wallet also does not track how much of the respective balance has been used up, thus allowing to create an arbitrary number of prospective transactions as long as there are pending refreshes exceeding the required amount. Tracking this "prospectively used balance" to limit this would require even more complexity.

Thus we're removing this feature.

0010955: refund "succeeds" after 180s [2h]

Wed, 03 Jun 2026 22:18:47 +0200

I made some changes to the (disabled) test test_merchant_order_refund.sh, which now show that the refund logic of the taler wallet CLI somehow takes a VERY long time. I'm not even sure if it actually succeeded, only that it returned with a successful status code. Please investigate the test.

0011134: support short wire transfer subjects via new QR code generation endpoint

Wed, 03 Jun 2026 19:37:12 +0200

wallet-core will need to interact with libeufin-nexus to get the QR code instead of merely computing it locally.

0011450: wallet-core handles expiration of proposed v1 contracts with choices badly

Wed, 03 Jun 2026 19:36:40 +0200

Steps:
* Scan payment QR code on https://shop.test.taler.net/
* Wait until payment deadline expires
* Scan again
* => wallet throws exception about choiceIndex instead of reporting expired transaction

The problem seems to be that we treat expired payments as already confirmed and try to repurchase.

```
case PurchaseStatus.Expired:
return handleConfirmed();
```