View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010775 | Taler | merchant backoffice SPA | public | 2025-12-15 00:40 | 2026-01-31 23:13 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Target Version | 1.5 | ||||
| Summary | 0010775: wire transfer not shown and no information given by the backend | ||||
| Description | On my local setup I created an order, made the payment and after the wire deadline nothing happen. No incoming, no information found if there was a problem on the backend or exchange. It seems that there was no problem since the wire transfer is now in the incoming list. Seeing this as a merchant it's very annoying that i don't have information: 1) that i should have a wire transfer incoming or being prepared to be sent (i would like to know which exchange owes me what?) 2) the wire transfer should have been reported by the exchange but it didn't (the exchange that should have already inform an incoming wire transfer didn't ) Otherwise it feels like the money is in a limbo. Also no error or warning logs | ||||
| Tags | ux | ||||
| related to | 0010710 | resolved | Christian Grothoff | incoming wire transfer not shown |
|
|
just to be clear, this is not the same as 0010710 in 0010710 I thought that "incoming" meant "after wallet payment" but it was clarified that it was "after wire deadline" in this case I knew that the incoming will not be shown before the deadline, but not shown and no error. |
|
|
I didn't have a way to check if there was a problems in the merchant or in the exchange, who to blame. I expected more information from the backend to know for example 1) the backend contacted the exchange and the exchange as lazy 2) the backend didn't contact the exchange and didn't know |
|
|
I just happen to see this again and I took times. The refund deadline was at 1765824820 The backend didn't know when asking at 1765824911 Then reported that the wire transfer was indeed on time 1765824645 IMO these times can be higher if there are issues between exchange and merchant channel. Merchant should inform when was the last time it asked the exchange and what was the last response. And be able to trigger the request to the exchange to know what is the latest status of the wire transfer. $ curl 'http://merchant.taler.test/instances/ee/private/orders/2025.349-03T730V8Z6W42' { "deposit_total": "KUDOS:0", "contract_terms": { ... "order_id": "2025.349-03T730V8Z6W42", "exchanges": [ { "url": "http://exchange.taler.test/", "priority": 1024, "master_pub": "XKP6K4W4KFQYWR1ZHGAXJWW1TA3KNTA37M12GKM56VM74DMQB440", "max_contribution": "KUDOS:1" } ], "timestamp": { "t_s": 1765824640 }, ... "pay_deadline": { "t_s": 1765824700 }, "refund_deadline": { "t_s": 1765824760 }, "wire_transfer_deadline": { "t_s": 1765824820 } }, "last_payment": { "t_s": 1765824645 }, ... "order_status_url": "http://merchant.taler.test/instances/ee/orders/2025.349-03T730V8Z6W42?token=ZNGP49ADK4SS6K6V496778MQAW" } $ date +%s 1765824911 $ curl 'http://merchant.taler.test/instances/ee/private/orders/2025.349-03T730V8Z6W42' { "deposit_total": "KUDOS:1.11", "contract_terms": { "order_id": "2025.349-03T730V8Z6W42", "exchanges": [ { "url": "http://exchange.taler.test/", "priority": 1024, "master_pub": "XKP6K4W4KFQYWR1ZHGAXJWW1TA3KNTA37M12GKM56VM74DMQB440", "max_contribution": "KUDOS:1" } ], "timestamp": { "t_s": 1765824640 }, "pay_deadline": { "t_s": 1765824700 }, "refund_deadline": { "t_s": 1765824760 }, "merchant_base_url": "http://merchant.taler.test/instances/ee/", "wire_transfer_deadline": { "t_s": 1765824820 } }, "order_status": "paid", "last_payment": { "t_s": 1765824645 }, "wire_details": [ { "wtid": "91JY4KCWF26ZHF7142ZKNM0RGSR2S79MBQYHPK1P5VZS74Q83P50", "exchange_url": "http://exchange.taler.test/", "amount": "KUDOS:1.1", "execution_time": { "t_s": 1765824645 }, "confirmed": false } ], "order_status_url": "http://merchant.taler.test/instances/ee/orders/2025.349-03T730V8Z6W42?token=ZNGP49ADK4SS6K6V496778MQAW" } $ date +%s 1765824919 |
|
|
"" The refund deadline was at 1765824820 The backend didn't know when asking at 1765824911 Then reported that the wire transfer was indeed on time 1765824645 "" Makes no sense, since your last time is *before* your first timestamp. Anyway, there is some inherent lag, as when we ask the exchange the second the transfer is due, the exchange most likely has simply not gotten around to it. So we do an exponential back-off and retry. But this is *per order* (not per wire transfer, we don't know the wire transfer yet!). So at best we could return with the order when we last checked the wire transfer status (and when we'll check next). |
|
|
> Makes no sense, since your last time is *before* your first timestamp Exactly my point. Everything worked perfectly but it looks like it didn't. This is a sign that more information is required on the SPA and in consequence more information should be recorded/provided by the backend. The information of the last check will help, definitely. I would say that also the response of the exchange will help, like we do with the KYC info. |
|
|
Well, the SPA does have (and is currently not using): "wire_details": [ { "wtid": "91JY4KCWF26ZHF7142ZKNM0RGSR2S79MBQYHPK1P5VZS74Q83P50", "exchange_url": "http://exchange.taler.test/", "amount": "KUDOS:1.1", "execution_time": { "t_s": 1765824645 }, "confirmed": false }] I suggest we do two things: (1) expand the "wire_details" with one more field, namely the "expected_transfer_serial_id" for the "offset" of the /private/incoming endpoint. Then, we can make the "wired" state (once wired) be a *deep link* directly into the "Wire transfers" list for this specific offset. Basically, clicking on "wired" (in the Timeline) would take you to the very wire transfer where this specific order was settled. If it was settled multiple times (because it was paid via multiple exchanges!), there should be *multiple* dates and so the "Timeline" would simply contain a list of "wired" entries with links to the different wire transfers responsible for the settlement. The "confirmed" bit could be used to toggle the text "wired" between "incoming" and "confirmed" (or if people strongly prefer: "wired" could stay instead of "incoming", I mostly think it should match the terminology used under "Wire transfers"). So with this small change, one could easily find all wire transfers that settle this order. Oh, and if the wire deadline is *past* and we do NOT yet have an "incoming" wire transfer ID, then we should show something like "overdue" with the wire deadline to indicate that something is indeed wrong. |
|
|
Spec updated in: 3c4c2ceb..039d38a2 |
|
|
Merchant also updated => SPA changes are left. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-15 00:40 | sebasjm | New Issue | |
| 2025-12-15 17:28 | sebasjm | Relationship added | related to 0010710 |
| 2025-12-15 17:30 | sebasjm | Note Added: 0026991 | |
| 2025-12-15 17:42 | sebasjm | Note Added: 0026992 | |
| 2025-12-15 20:11 | sebasjm | Note Added: 0026996 | |
| 2025-12-15 20:37 | Christian Grothoff | Note Added: 0026999 | |
| 2025-12-15 20:37 | Christian Grothoff | Status | new => acknowledged |
| 2025-12-15 20:37 | Christian Grothoff | Target Version | => post-1.0 |
| 2025-12-15 20:37 | Christian Grothoff | Tag Attached: ux | |
| 2025-12-16 14:02 | sebasjm | Note Added: 0027012 | |
| 2026-01-26 07:43 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2026-01-26 07:43 | Christian Grothoff | Status | acknowledged => assigned |
| 2026-01-26 07:43 | Christian Grothoff | Status | assigned => confirmed |
| 2026-01-28 15:09 | Christian Grothoff | Status | confirmed => assigned |
| 2026-01-28 15:10 | Christian Grothoff | Target Version | post-1.0 => 1.5 |
| 2026-01-31 22:16 | Christian Grothoff | Note Added: 0027517 | |
| 2026-01-31 22:22 | Christian Grothoff | Note Added: 0027518 | |
| 2026-01-31 23:13 | Christian Grothoff | Note Added: 0027519 | |
| 2026-01-31 23:13 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2026-01-31 23:13 | Christian Grothoff | Category | merchant backend => merchant backoffice SPA |
