View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010617 | Taler | merchant backend | public | 2025-11-15 19:39 | 2025-11-15 21:50 |
| Reporter | htgoebel | 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 | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 1.0 | ||||
| Target Version | 1.2 | Fixed in Version | 1.2 | ||
| Summary | 0010617: 200 response even if refund was not done | ||||
| Description | In the SPA, successive refunds are added, thus I did the same using the API: refunding 5 KUDOS and then 3 KUDOS. The result code of both was 200 and a MerchantRefundResponse was returned Anyhow, the second refund did not show up. | ||||
| Steps To Reproduce | 1) Create an order (either using the SPA or the API), choose some KUDOS to have room for two refunds. 2) Create an refund (either using the SPA or the API) 3) Create an refund with an amount below the amount of the first refund using the API. ==> Statuscode 200 and MerchantRefundResponse 4) Inspect the order (either using the SPA or the API) ==> the second refund will not show up. | ||||
| Additional Information | a) I'm fine with the SPA and API behaving different. Anyhow, no. 3 above should return some error, since the value was not changed b) The documentation for POST [/instances/$INSTANCE]/private/orders/$ORDER_ID/refund says "Increase the refund …". This should be clarified, esp. since the API behaves different than the SPA. Taler Backoffice 1.1.1-dev.2 (22:0:10) | ||||
| Tags | No tags attached. | ||||
| The value not changing is fine, requests are supposed to be idempotent. And if you lower the refund amount from a previous refund, we just assume that there is some concurrency going on. So IMO 200 OK is correct, even if there is no change. | |
| So this is per design, refunds cannot be lowered, but requests are idempotent and the semantic basically is: if the refund is at or above the specified level, we consider your request successful. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-11-15 19:39 | htgoebel | New Issue | |
| 2025-11-15 21:49 | Christian Grothoff | Note Added: 0026476 | |
| 2025-11-15 21:50 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2025-11-15 21:50 | Christian Grothoff | Status | new => closed |
| 2025-11-15 21:50 | Christian Grothoff | Resolution | open => no change required |
| 2025-11-15 21:50 | Christian Grothoff | Fixed in Version | => 1.2 |
| 2025-11-15 21:50 | Christian Grothoff | Note Added: 0026477 | |
| 2025-11-15 21:50 | Christian Grothoff | Product Version | => 1.0 |
| 2025-11-15 21:50 | Christian Grothoff | Target Version | => 1.2 |