View Issue Details

IDProjectCategoryView StatusLast Update
0007691Talerwallet-corepublic2023-09-23 15:09
Reportersebasjm Assigned ToFlorian Dold  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionwon't fix 
Product Versiongit (master) 
Target Version0.9.3Fixed in Version0.9.3 
Summary0007691: getting refund in the demo frontend get refund = 0
DescriptionThis 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?
TagsNo tags attached.

Relationships

related to 0007858 new consider protocol extensions to shift around fees from customer to merchant 

Activities

Florian Dold

2023-04-05 18:27

manager   ~0020031

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.

sebasjm

2023-04-10 15:36

developer   ~0020049

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

Florian Dold

2023-06-05 14:07

manager   ~0020261

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.

Issue History

Date Modified Username Field Change
2023-02-13 20:52 sebasjm New Issue
2023-02-13 20:52 sebasjm Status new => assigned
2023-02-13 20:52 sebasjm Assigned To => Florian Dold
2023-04-05 18:27 Florian Dold Assigned To Florian Dold => sebasjm
2023-04-05 18:27 Florian Dold Status assigned => feedback
2023-04-05 18:27 Florian Dold Note Added: 0020031
2023-04-10 15:36 sebasjm Note Added: 0020049
2023-04-10 15:36 sebasjm Assigned To sebasjm => Florian Dold
2023-04-13 20:36 Florian Dold Category wallet (TS core) => wallet-core
2023-06-05 14:07 Florian Dold Status feedback => resolved
2023-06-05 14:07 Florian Dold Resolution open => won't fix
2023-06-05 14:07 Florian Dold Note Added: 0020261
2023-06-05 14:30 sebasjm Relationship added related to 0007858
2023-09-23 15:07 Christian Grothoff Fixed in Version => 0.9.3
2023-09-23 15:09 Christian Grothoff Status resolved => closed