View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0010960Talermerchant backoffice SPApublic2026-01-31 21:042026-02-05 15:46
ReporterChristian Grothoff Assigned Tosebasjm  
PriorityhighSeveritytextReproducibilityalways
Status resolvedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Version1.5 
Summary0010960: "Verified" tab for Wire transfers shows "verified: no"
DescriptionWhen looking at the "Wire transfers" in the "verified" tab, after explicitly *confirming* a wire transfer, the transfer shows as "Verified: no", which is wild.

Additional InformationHTTP responses from the backend were:
incoming:
{
  "incoming": [
    {
      "expected_credit_amount": "TESTKUDOS:1",
      "wtid": "31HP8RQHEGD9AV3G5NKY6XZ6CFC3N3B3P2TJ7EXR92EY94APX17G",
      "payto_uri": "payto://x-taler-bank/localhost/fortythree?receiver-name=fortythree",
      "exchange_url": "http://localhost:8081/",
      "expected_transfer_serial_id": 1,
      "execution_time": {
        "t_s": 1769888804
      },
      "validated": true,
      "confirmed": true,
      "last_http_status": 200,
      "last_ec": 0
    }
  ]
}

transfers:
{
  "transfers": [
    {
      "credit_amount": "TESTKUDOS:1",
      "wtid": "31HP8RQHEGD9AV3G5NKY6XZ6CFC3N3B3P2TJ7EXR92EY94APX17G",
      "payto_uri": "payto://x-taler-bank/localhost/fortythree?receiver-name=fortythree",
      "exchange_url": "http://localhost:8081/",
      "transfer_serial_id": 1,
      "verified": false, -- deprecated, ignore!
      "confirmed": true, -- deprecated, ignore!
      "expected": true,
      "execution_time": {
        "t_s": 1769889615
      }
    }
  ]
}
TagsNo tags attached.

Activities

Christian Grothoff

2026-01-31 21:15

manager   ~0027510

Ok, looking over the protocol again, we first of all MUST ignore the now "deprecated" fields (marked in the snippets above).

So for the "/transfers" endpoint, that only leaves *expected* as the boolean to render, which makes sense. This is currently shown as the "Verified" tab, which I suggest we rename to "Confirmed": /transfers only ever shows wire transfers that have been confirmed as having hit our bank account. The list then shows WTID, amount, and whether the transfer was *expected*, plus the execution date. Now, the order is weird, I would expect it to be "Date" (shorter than "Execution Date"), "Amount" (instead of "Expected credit" -- this is *confirmed* wire transfers, not expectations), "ID" (or "Subject", debatable), and finally "Expected" (almost always 'yes', most boring data). That shows data in a more canonical order (Date first) and then by importance (amount is very important), and with simpler titles. The overall caption "Incoming wire transfers" is fine, could also be "Confirmed wire transfers into bank account" -- we have the space, and might be super-clear.

Christian Grothoff

2026-01-31 21:27

manager   ~0027511

Now for the "/incoming" endpoint, I think we first of all should expose the filters "verified" and "confirmed", which both have 3 states: YES/NO/ALL. Default for both filters should probably be "ALL". Note that confusingly the "verified" filter matches the "validated" field in the response. We SHOULD fix that in the next iteration of the API... Anyway, let's first fix the GUI so we know what we're talking about here. "Confirmed" means that this exact wire transfer exists in the "Confirmed" tab. So I think we can just leave that. "Validated" is the interesting bit, it means that the amount matches the total the merchant backend expected to be settled (sum of all orders minus fees). We also need to note that the "expected credit" could be missing if we do not yet know the amount. We probably should show it as to be determined (TBD) if it is not yet known instead of leaving the table entry empty. I would again switch the column order: "Date" (anticipated or executed, we don't know, depends on "Confirmed", so just "Date" is best!), "Amount" (again, may be expected, or confirmed, or TBD!), "ID", "Confirmed", "Validated").

Christian Grothoff

2026-01-31 21:29

manager   ~0027512

Finally, I've only tested this with a single transfer. We should probably allow the user to specify how many transfers they want to see on one page (default: 20 or 50?). Please also confirm that the page supports pagination.

sebasjm

2026-02-05 12:18

developer   ~0027586

Last edited: 2026-02-05 12:31

 > "Confirmed" means that this exact wire transfer exists in the "Confirmed" tab. So I think we can just leave that.

Duplicated info, let's just return only unconfirmed wire transfer (By definition they are "new" which were not yet checked) on the /incoming endpoint. After confirmation it will automatically be returned on the other endpoint. I can't filter on the UI because of pagination.

> "verified" and "confirmed", which both have 3 states: YES/NO/ALL

I'm going to remove "confirmed" from /incoming, is duplicated info. Also, all request will be with "confirmed": NO (maybe you want to remove it from the protocol). In this way the "incoming" table will only have "new wire transfer that needs to be checked against you bank transfer" very important to be prominent. If empty it disappears.

I prefer only show a "verified" and "expected" filter which only show with YES/NO/ALL to filter both lists.

If "verified" : false this is an error, something needs to be fixed between merchant and exchange. A bug maybe? Is there a reason that is not a bug?

The "verified" filter should work in both request /incoming and /transfer, merchant can still confirm a wire transfer even if is not verified. Right?

> Please also confirm that the page supports pagination.

Yes, it does.

Regarding the expected. I could hide this column and only show it if the filter is "ALL". Should the merchant be able to POST wire transfer ? Right now there is no form for that (it was removed) so I don't see how this could be present.

Christian Grothoff

2026-02-05 14:21

manager   ~0027590

It is not duplicated info, because the "Confirmed" tab would show completely different data. These are NOT two different views of the same list! (There is a reason why you have two different endpoints!)

And yes, the "confirmed" is deprecated (as I indicated above), and once it wouldn't break clients, I do intend to remove the field from the protocol entirely. Same for "verified". They are both there right now just to ensure clients that rely on them do not crash, but they are already NOT meaningful anymore!

And no, the "verified" filter makes no sense on the "transfers" list.

sebasjm

2026-02-05 15:46

developer   ~0027595

d8c0ea2ca..1d3ca6ef6

Issue History

Date Modified Username Field Change
2026-01-31 21:04 Christian Grothoff New Issue
2026-01-31 21:04 Christian Grothoff Status new => assigned
2026-01-31 21:04 Christian Grothoff Assigned To => sebasjm
2026-01-31 21:06 Christian Grothoff Additional Information Updated
2026-01-31 21:09 Christian Grothoff Additional Information Updated
2026-01-31 21:10 Christian Grothoff Description Updated
2026-01-31 21:15 Christian Grothoff Note Added: 0027510
2026-01-31 21:27 Christian Grothoff Note Added: 0027511
2026-01-31 21:29 Christian Grothoff Note Added: 0027512
2026-02-05 12:18 sebasjm Note Added: 0027586
2026-02-05 12:31 sebasjm Note Edited: 0027586
2026-02-05 14:21 Christian Grothoff Note Added: 0027590
2026-02-05 15:46 sebasjm Status assigned => resolved
2026-02-05 15:46 sebasjm Resolution open => fixed
2026-02-05 15:46 sebasjm Note Added: 0027595