View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010695 | Taler | merchant backoffice SPA | public | 2025-12-01 19:29 | 2025-12-15 11:46 |
| Reporter | htgoebel | Assigned To | sebasjm | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.0 | ||||
| Target Version | 1.3 | Fixed in Version | 1.3 | ||
| Summary | 0010695: Can create refund for wired order | ||||
| Description | Using the API one can create refunds for orders that have been wired already, see screenshot. Expected: To get Gone or another error message. | ||||
| Steps To Reproduce | - In the SPA create a payment with short deadlines and pay it. - Wait for the wire transfer deadline to be reached. - Use curl or another tools to create a refund for this order using the API. ==> This will return 200 and a MerchantRefundResponse - Go to the SPA, reload and view thise order's details ==> A "refund" will be shown | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
|
|
The BIG issue here is that the merchant backend SPA fails to render the "refund_pending" field of the backend response: https://docs.taler.net/core/api-merchant.html#inspecting-orders As a result, the viewer cannot distinguish refunds that were *approved* from those that *succeeded*. We can argue that refunds after the wire deadline should not be approved anymore (easy to implement), but more importantly the SPA needs to distinguish clearly between refunds that did happen (wallet got the money) and those that were approved but the wallet did NOT get the money (for whatever reason). |
|
|
Merchant adjusted to 410 past wire deadline in b9c64ba7..4f8b3cf9 |
|
|
refund that did happen are shown as "refund taken" and refund that was approved by the merchant is shown as "refunded amount" also pending refund "pending" vs "taken" are shown green vs red In this screenshot you can see both with the fix of 0010725 where the refund URI is not there anymore after wire deadline happened. If you think that still confusing i can add a banner that says "the rest of the refund $ (refunded - taken)" |
|
|
i think the spa is clear |
|
|
Let's see if vlada comes up with an idea for how to make it clearer! |
|
|
Refund created -> Confirmed by consumer -> Refund completed / Refund failed (on hover in timeline description why failed) Can we get all these states from the backend and show in the timeline? Badges: "Refund in progress", "Refunded" if refund completed |
|
|
Refund created: is the red icon. I will change the text from "refund to "refund created" confirmed by the consumer: I don't this makes any sense, what are you expecting? QR code scanned but not claimed? this is much details not needed, and I think merchant doesn't bring this info. Refund completed: is the green icon. I will change the text from "refund" to "refund completed" Refund failed: the backend doesn't inform this state but we can define one here. If the refund is not completed after the wire transfer detail. I will change the text and add a (i) icon with the description of why is impossible to complete the refund. |
|
|
Sounds good to me. re. "confirmed by the consumer": I agree that this is not relevant for the merchant. For the merchant it is relevant whether he/she self has the coins or the customer has them. |
|
|
7032a2da0..50f768fa6 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-01 19:29 | htgoebel | New Issue | |
| 2025-12-01 19:29 | htgoebel | File Added: Screenshot_20251201_192837.png | |
| 2025-12-02 11:14 | Stefan | Relationship added | related to 0010630 |
| 2025-12-02 23:00 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2025-12-02 23:00 | Christian Grothoff | Status | new => assigned |
| 2025-12-03 14:49 | vecirex | Relationship deleted | related to 0010630 |
| 2025-12-04 21:59 | Christian Grothoff | Priority | normal => high |
| 2025-12-04 21:59 | Christian Grothoff | Product Version | => 1.0 |
| 2025-12-04 21:59 | Christian Grothoff | Target Version | => 1.3 |
| 2025-12-04 22:16 | Christian Grothoff | Note Added: 0026743 | |
| 2025-12-04 22:17 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2025-12-04 22:17 | Christian Grothoff | Severity | minor => major |
| 2025-12-04 22:17 | Christian Grothoff | Category | merchant backend => merchant backoffice SPA |
| 2025-12-04 22:30 | Christian Grothoff | Note Added: 0026744 | |
| 2025-12-04 22:37 | Christian Grothoff | Relationship added | related to 0010726 |
| 2025-12-04 22:40 | Christian Grothoff | Relationship added | related to 0010724 |
| 2025-12-04 22:41 | Christian Grothoff | Relationship added | related to 0010725 |
| 2025-12-05 14:37 | sebasjm | Note Added: 0026780 | |
| 2025-12-05 14:37 | sebasjm | File Added: image.png | |
| 2025-12-05 14:37 | sebasjm | File Added: image-2.png | |
| 2025-12-05 14:38 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2025-12-05 14:38 | sebasjm | Status | assigned => feedback |
| 2025-12-05 14:38 | sebasjm | Note Added: 0026781 | |
| 2025-12-05 20:52 | Christian Grothoff | Assigned To | Christian Grothoff => vlada.svirsh |
| 2025-12-05 20:53 | Christian Grothoff | Note Added: 0026796 | |
| 2025-12-05 20:53 | Christian Grothoff | Status | feedback => assigned |
| 2025-12-05 20:53 | Christian Grothoff | Target Version | 1.3 => 1.5 |
| 2025-12-14 12:48 | vlada.svirsh | Note Added: 0026960 | |
| 2025-12-14 12:49 | vlada.svirsh | Assigned To | vlada.svirsh => sebasjm |
| 2025-12-14 12:58 | vlada.svirsh | Note Edited: 0026960 | |
| 2025-12-14 13:07 | vlada.svirsh | Note Edited: 0026960 | |
| 2025-12-14 14:09 | sebasjm | Note Added: 0026964 | |
| 2025-12-14 15:27 | htgoebel | Note Added: 0026970 | |
| 2025-12-14 20:58 | sebasjm | Status | assigned => resolved |
| 2025-12-14 20:58 | sebasjm | Resolution | open => fixed |
| 2025-12-14 20:58 | sebasjm | Note Added: 0026975 | |
| 2025-12-15 11:45 | Christian Grothoff | Target Version | 1.5 => 1.3 |
| 2025-12-15 11:46 | Christian Grothoff | Fixed in Version | => 1.3 |