View Issue Details

IDProjectCategoryView StatusLast Update
0006590Talerdocumentationpublic2023-01-26 22:53
ReporterFlorian Dold Assigned ToFlorian Dold  
PrioritynormalSeveritytextReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.1Fixed in Version0.9.1 
Summary0006590: clarify UX for (partially) failed payments
DescriptionFor partially failed payments, the user should be given the option to abort, which then issues an "abort with refund".

If that succeeds, everything is fine. But what if it doesn't? Should the user be given some "abort with potential losses" option that tries to refresh as much as possible? Should the wallet "forever" try to get refunds from the merchant for money we didn't recover via refresh?

We need to clarify this, and ideally document it.
TagsNo tags attached.


related to 0007568 closedsebasjm implement the new semantic of aborting/cancel/forgetting/resuming a tx 


Christian Grothoff

2020-09-10 01:13

manager   ~0016956

Well, we first of all clearly will refresh as much as possible for the coins that succeed. Now, if for some it does _not_ work, I'd say we show this in the transaction history for the (failed) purchase with:
- amount lost
- reason (as human readable as possible, i.e. 'too late for refund', or 'merchant protocol violation'
- offer to export proof as JSON
For 0.9 there is lots of "export proof as JSON" to be added for all kinds of bad behaviors (basically any merchant or exchange protocol violation) as well as at least one 'normal' one: proof of purchase.

So my opinion: for all protocol violations (or even just "tough luck" situations like too-late-for-refund), we should have a way to export a JSON proof in the transaction history view.

Christian Grothoff

2020-09-10 01:13

manager   ~0016957

Bumping to 0.9, as proof exports is 0.9.x.


2020-09-28 19:50

developer   ~0016984

> partially failed payments, the user should be given the option to abort

Apart from protocol violations, what are other reasons for payment to only fail partially? Is there any reason why we can't automatically try to recover as many funds as possible in these situations?

Florian Dold

2023-01-10 18:50

manager   ~0019628

Discussed on Mumble: The UI should show an "abort" button while the payment is pending. Only when the transaction is aborted or finished, the forget button should show.

Florian Dold

2023-01-11 17:28

manager   ~0019630

The wallet now supports aborting transactions and force-aborting transactions that are in the "aborting" state.

The UI should only allow forgetting transactions that are finished/aborted/failed and show the "abort" as "cancel" when the transaction is aborting, and warn the user that this might result in lost coins.

Issue History

Date Modified Username Field Change
2020-09-08 22:20 Florian Dold New Issue
2020-09-08 22:20 Florian Dold Status new => assigned
2020-09-08 22:20 Florian Dold Assigned To => Christian Grothoff
2020-09-10 01:13 Christian Grothoff Note Added: 0016956
2020-09-10 01:13 Christian Grothoff Target Version 0.8.1 => 0.9
2020-09-10 01:13 Christian Grothoff Note Added: 0016957
2020-09-10 01:13 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2020-09-11 22:56 Christian Grothoff Severity minor => text
2020-09-28 19:50 grote Note Added: 0016984
2020-10-11 21:14 Christian Grothoff Category other => documentation
2022-10-20 11:20 Christian Grothoff Target Version 0.9 => 0.9.1
2023-01-10 18:50 Florian Dold Note Added: 0019628
2023-01-11 17:28 Florian Dold Status assigned => resolved
2023-01-11 17:28 Florian Dold Resolution open => fixed
2023-01-11 17:28 Florian Dold Note Added: 0019630
2023-01-12 16:30 sebasjm Relationship added related to 0007568
2023-01-23 22:25 Christian Grothoff Fixed in Version => 0.9.1
2023-01-26 22:53 Christian Grothoff Status resolved => closed