View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007691 | Taler | wallet-core | public | 2023-02-13 19:52 | 2023-09-23 13:09 |
| Reporter | sebasjm | Assigned To | Florian Dold | 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 | major | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.3 | Fixed in Version | 0.9.3 | ||
| Summary | 0007691: getting refund in the demo frontend get refund = 0 | ||||
| Description | This may be due to the coins that the user had in the wallet. Step to reproduce: 1- withdraw some coins 2- pay some articles 3- try to get some refunds Refund fee will apply, given the low value of the article and relative high fee the total refund will equals to 0 Worse, the total refund may not be always the same (even if the article is the same price) since the coins may be small with relative high refund fee. Exchange configuration: # curl https://exchange.demo.taler.net/keys | jq '.denominations[] | {fee_withdraw, fee_deposit, fee_refresh, value}' { "fee_withdraw": "KUDOS:0.01", "fee_deposit": "KUDOS:0.01", "fee_refresh": "KUDOS:0.01", "value": "KUDOS:0.1" } { "fee_withdraw": "KUDOS:0.01", "fee_deposit": "KUDOS:0.01", "fee_refresh": "KUDOS:0.01", "value": "KUDOS:2" } { "fee_withdraw": "KUDOS:0.01", "fee_deposit": "KUDOS:0.01", "fee_refresh": "KUDOS:0.01", "value": "KUDOS:10" } { "fee_withdraw": "KUDOS:0.01", "fee_deposit": "KUDOS:0.01", "fee_refresh": "KUDOS:0.01", "value": "KUDOS:1" } { "fee_withdraw": "KUDOS:0.01", "fee_deposit": "KUDOS:0.01", "fee_refresh": "KUDOS:0.01", "value": "KUDOS:5" } Here if what is remaining in the wallet is just KUDOS:0.01 then the refund is always be 0 !!! Maybe the wallet should do a refresh? | ||||
| Tags | No tags attached. | ||||
| related to | 0007858 | acknowledged | consider protocol extensions to shift around fees from customer to merchant |
| This seems to be about the denomination structure of the exchange. I'm not sure what wallet-core should do differently here or how refreshing would help. | |
| Agree that this may be more related to the exchange fee structure, but the experience is bad for the user since is unexpected. Trying to get a refund and the effective amount of the transaction is 0, not a refund. Bad exchange and wallet should handle it. Maybe this can also be solved by with the help for the merchant => with the feature of the merchant being able to pay the refund fee. Regarding the refresh operation, the situation in my mind was: * the contract was paid with a coin with high refund fee because coin-selection doesn't not optimize by refund_fee when doing a payment. * if the denomination to be refund is not the best, maybe it can be changed/refreshed before refund so it will pay less fee This situation is possible: 1 start a wallet with high amount 2 create an order of low amount 3 pay a refund 4 go to 2 At the beginning, refund of the order will be X and after a while refund will be less (and maybe 0) even if the order is the same. What change here are the coins being used to pay, smaller coins with higher relative refund fee. Here, a refresh operation could make the refund stable? in terms of fees | |
| I don't see how this works in a generic settings. There'll always be cases where the effective refund amount is zero. Also consider that refreshing only makes coins smaller and thus the fees become worse. In the future, we might address this class of issue with 0007858. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-02-13 19:52 | sebasjm | New Issue | |
| 2023-02-13 19:52 | sebasjm | Status | new => assigned |
| 2023-02-13 19:52 | sebasjm | Assigned To | => Florian Dold |
| 2023-04-05 16:27 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-04-05 16:27 | Florian Dold | Status | assigned => feedback |
| 2023-04-05 16:27 | Florian Dold | Note Added: 0020031 | |
| 2023-04-10 13:36 | sebasjm | Note Added: 0020049 | |
| 2023-04-10 13:36 | sebasjm | Assigned To | sebasjm => Florian Dold |
| 2023-04-13 18:36 | Florian Dold | Category | wallet (TS core) => wallet-core |
| 2023-06-05 12:07 | Florian Dold | Status | feedback => informing |
| 2023-06-05 12:07 | Florian Dold | Resolution | open => won't fix |
| 2023-06-05 12:07 | Florian Dold | Note Added: 0020261 | |
| 2023-06-05 12:30 | sebasjm | Relationship added | related to 0007858 |
| 2023-09-23 13:07 | Christian Grothoff | Fixed in Version | => 0.9.3 |
| 2023-09-23 13:09 | Christian Grothoff | Status | informing => closed |