View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010710 | Taler | merchant backend | public | 2025-12-03 13:30 | 2026-02-04 19:00 |
| Reporter | sebasjm | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | not fixable | ||
| Product Version | git (master) | ||||
| Target Version | 1.4 | Fixed in Version | 1.4 | ||
| Summary | 0010710: incoming wire transfer not shown | ||||
| Description | after i paid an order i expect to see the incoming wire transfer just after the exchange confirmed the payment i my case it showed up after some time (maybe after wire delay passed) | ||||
| Tags | No tags attached. | ||||
| They can only appear after the wire deadline, as before then the exchange doesn't not the subject and the merchant also doesn't ask the exchange about the transfer. | |
| ACK then "incoming" in the sense of the time it takes from the banking system to move the money from the exchange bank account to the merchant bank account. I would say that "incoming" includes after the payment is taler-confirmed by the exchange. After the wallet payment to the wire delay, the total money is not shown anywhere. This endpoint was not made for that but I think that also be information expected by the merchant. | |
| I guess the confusion is that what from the exchange/technical perspective is called "wired" is for you "incoming". But "incoming" is IMO too board as a term here: paid orders are also kind of "incoming" (unless refunded before...). "wired" just means the exchange sent the money, not that the recipient got it (that's verified, if the amount matches, that is...). | |
| In the QC meeting, we commented on this confusion but IRC we found a consensus that the explanation to merchant users has to be much clearer in their wording and terminology. So, suggestions were like verified --> successful payment (the revenue was successfully credited to your bank account) confirmed --> wire transfer pending (the revenue has been wired to the bank account and is still subject to be confirmed by you) incoming --> amount wired (dito) Let's find clear language here. I'm open to further suggestions. | |
| I agree that we can find a better term. Regarding of that I think the backend should allow asking for this special state so the merchant has a feedback of the order for which it are wired but should verify them 0010744 | |
| In any case, we need to communicate more clearly to retailers and app translators what we really mean. Please be more specific; we have enough space in the tooltips. Those are my suggestions, so far: From a retailer's perspective, I always want to see the following orders in the backoffice 1. “Paid by customer” (paid) 2. “Paid, but not yet transferred to my bank account” (i.e., they are pending settlement by aggregate wire transfer after the transfer deadline has expired - with a clear date!) 3. “Successfully transferred to my bank account” (i.e., they are final) 4. “Partially refunded” with the refunded amount and the amount still awaiting settlement to my bank account 5. “Confirmed by me as final in my bank account” (i.e., everything is fine, I have seen the amount in my bank account and am now forwarding this information to the merchant back office) and in future iterations: 6. “Automatically confirmed as final in my bank account” | |
| 0010960 makes some suggestions to clean up the "Wire transfers" dialog with *somewhat* clearer names. | |
| I think 0010744 and 0010775 will make the rest clear(er). The incoming wire transfer data is unavailable before the wire transfer deadline set by the merchant (and that deadline and the amount can totally change until then, too!), so there is really nothing we can reasonably show at this point. But we can probably clean up a bit what we show under orders (0010744). Beyond that, there is really nothing we _can_ fix here, especially not in the *Backend*. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-03 13:30 | sebasjm | New Issue | |
| 2025-12-03 13:32 | Christian Grothoff | Note Added: 0026712 | |
| 2025-12-03 13:44 | sebasjm | Note Added: 0026714 | |
| 2025-12-04 08:37 | Christian Grothoff | Note Added: 0026732 | |
| 2025-12-04 08:37 | Christian Grothoff | Status | new => acknowledged |
| 2025-12-04 08:37 | Christian Grothoff | Relationship added | related to 0010714 |
| 2025-12-04 08:51 | Stefan | Note Added: 0026735 | |
| 2025-12-07 09:45 | Christian Grothoff | Target Version | => 1.5 |
| 2025-12-08 18:52 | sebasjm | Note Added: 0026827 | |
| 2025-12-08 20:18 | Stefan | Note Added: 0026830 | |
| 2025-12-15 16:28 | sebasjm | Relationship added | related to 0010775 |
| 2026-01-26 05:55 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2026-01-26 05:55 | Christian Grothoff | Status | acknowledged => assigned |
| 2026-01-26 06:06 | Christian Grothoff | Priority | normal => high |
| 2026-01-26 06:44 | Christian Grothoff | Relationship added | related to 0010744 |
| 2026-01-31 20:36 | Christian Grothoff | Note Added: 0027513 | |
| 2026-01-31 20:40 | Christian Grothoff | Note Added: 0027514 | |
| 2026-01-31 20:40 | Christian Grothoff | Status | assigned => informing |
| 2026-01-31 20:40 | Christian Grothoff | Resolution | open => not fixable |
| 2026-01-31 20:40 | Christian Grothoff | Fixed in Version | => 1.4 |
| 2026-01-31 20:40 | Christian Grothoff | Product Version | => git (master) |
| 2026-01-31 20:40 | Christian Grothoff | Target Version | 1.5 => 1.4 |
| 2026-02-04 19:00 | Christian Grothoff | Status | informing => closed |