View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010775 | Taler | merchant backoffice SPA | public | 2025-12-15 00:40 | 2026-02-01 17:57 |
| 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. |
|
|
@stefan: Didn't you observe something similar for talersticker in TEST/CHF prod? If yes, that's directly related and we need a test case. |
|
|
if I understood correctly the tree states are wired-pending: * The wire transfer has been notified by the payment service provider. wired-confirmed: * This wire transfer has been notified manually or by the banking system wired-overdue: * The wire transfer should have been made but no notification has arrived, contact the payment service provider. Check if the text is good, I'm going to add that as tool-tips |
|
|
how do i find that there are still wire overdue? should the SPA calculate the absent ? |
|
|
My suggestions: wired-pending: This wire transfer has been reported as pending by the payment service provider. wired-confirmed: This wire transfer was confirmed manually by the recipient or by the banking system. wired-overdue: This wire transfer should have been made, but no notification has been received. Please contact the payment service provider. |
|
|
Well, not sure about **3** states. First, we have just "paid" before wire deadline. So here we'd show when the contract was paid, possibly partial refunds, and the *anticipated* time of the wire, namely the "wire transfer deadline" as per contract. So that's like a 0th state, "awaiting settlement" + DATE. Then, once that date has been reached, we kind of go into "wire overdue", which should more or less instantly convert to "wire-pending". Now, we could also go into "wire-pending" *before* the wire deadline if the exchange wires the funds early due to aggregation with another order. So transitions are both awaiting->pending->confirmed and awaiting->overdue->pending->confirmed. The pending->confirmed happens when the user manually confirms the wire transfer happened in the wire transfer list. The link to the wire transfer list exists both in pending and confirmed states. As for the hints: awaiting-settlement: The settlement deadline configured for this order is still in the future. wired-pending: The payment service provider initiated the wire transfer to settle the obligation. It may take some time to arrive in your bank account. If you did not setup access to your bank account for the merchant backend, you need to <a>manually confirm</a> receiving the money. -- link to the transaction list with the "confirm" button. wired-confirmed: The payment was settled by the payment service provider and the money is now in your bank account. wired-overdue: This wire transfer should have been made, but no settlement details are available. Please check that your merchant backend and especially the taler-merchant-depositcheck, taler-merchant-reconciliation and taler-merchant-kyccheck services are operating correctly before contacting the payment service provider. ALTERNATIVE, if KYC obligations are pending: This wire transfer should have been made, but no settlement details are available. This is likely because you did not yet satisfy some <a>legitimization requirements</a>. Please address those before contacting the payment service provider. -- with link to KYC status page with pending request |
| 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 |
| 2026-02-01 11:17 | vecirex | Note Added: 0027523 | |
| 2026-02-01 14:08 | sebasjm | Note Added: 0027529 | |
| 2026-02-01 14:24 | sebasjm | Note Added: 0027530 | |
| 2026-02-01 16:27 | Stefan | Note Added: 0027532 | |
| 2026-02-01 17:57 | Christian Grothoff | Note Added: 0027533 |
