View Issue Details

IDProjectCategoryView StatusLast Update
0009670Talerwallet (all platforms)public2025-04-20 10:12
ReporterAntoine A Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status confirmedResolutionopen 
Target Version1.0 stretch goals 
Summary0009670: More reactive payment flows flows
DescriptionWallets should eagerly check whether a payment (P2P or withdrawal) has reached a final state without the user having to click on anything:
- opening the URI of a settled payment (confirmed, abandoned or expired) should redirect to a status page (success or failure) on any wallet
- the settlement of a payment should trigger a redirection in other wallets
    - aborting a payment should trigger a redirection to a failure page on other wallets
    - expiry of a payment should trigger a redirection to a failure page on all portfolios.
Tagsux

Relationships

related to 0009683 resolvedFlorian Dold Opening an already completed withdrawal and confirming it produce an error 
related to 0008866 confirmed consider garbage-collecting expired merchant payment transactions in state `dialog(proposed)` 

Activities

Antoine A

2025-03-31 13:44

developer   ~0024351

Florian told me that wallet-core should already notify this to the user interface, so it should be possible with the current logic.

Antoine A

2025-04-11 10:19

developer   ~0024508

As soon as a P2P payment is prepared the wallet should start long polling to detect if it's aborted or expired, right now this only happens after confirmation.

Antoine A

2025-04-15 09:17

developer   ~0024546

Every time we scan a payment URI, we should store the payment in the database, this is currently the case for P2P payments but not for withdrawals. As soon as a payment is stored, even if the user hasn't requested completion of the payment, the wallet should start retrieving the status of the payment to react to a potential abortion, which means having a *process* function for DialogProposed status.

MarcS

2025-04-15 10:18

developer   ~0024547

@Antoine: A withdrawal is not a payment...
But I guess, you wanted to `save` *all* scanned QR codes, to be able to execute the transaction later, right?

Proposal: Add a "Save for later" button to the UI of scanned QR codes, or tapped talerURIs (mail, messenger, website, 3rd-party-app...), or scanned NFC TAGs.
   (at least on iOS, we cannot differentiate the method HOW we got the talerURI anyway - iOS calls us with openURL...)
Then the user can decide, whether they want to
a) execute the operation right now
b) get rid of of that proposal (by just swiping down the sheet), and forget the talerURI
or c) save the transaction in the DB, which means wallet-core can monitor whether it is still possible to execute it or whether it was aborted, or timed out, or executed by another wallet...

Of course a) and b) are already implemented, but c) would be new.

Antoine A

2025-04-15 10:51

developer   ~0024548

Yes, I'm looking for consistent behaviour with all types of scanned QR codes that lead to the execution of a transaction and I am looking for the most user friendly flow possible.

I think we should always store scanned QR code in the database and use the existing logic to check if it has already been completed/aborted/expired and also react to status changes. As the user has not explicitly accepted yet it’s ok delete the transaction without warning the user (this can be a simple swipe or a close button). The good thing about this is that if the app is closed while we where proposing a payment the user can easily accept it later by opening the app again without scanning the QR code again (happened to me while testing and a bit frustrating).

We could even go as far as showing pending transaction proposal when the app is started (this would need to be discussed).

MarcS

2025-04-15 12:56

developer   ~0024551

But the user may *intentionally* swipe down the sheet (on iOS we always show a sheet on openURL) to dismiss this transaction.
They would be annoyed if the tx would still be active, forcing them to "open" the tx and then "abort" / "delete" it.
Swiping down already means "I don't want to do that", and should be honored.

I really thought a "Save for later" button would be the best UI... Don't automatically collect & save stuff which users must manually delete...

However, what we could do is to save the last talerURI which the user dismissed (swiped down), and make that available in the Actions sheet (above the "Send" and "Request" buttons) in case the user accidentally swiped down and didn't really want to dismiss the tx.
(We could even add a disclosure triangle to open a list of dismissed talerURIs...).
And yes, if we keep such dismissed tx, then wallet-core could as well monitor them so we could show the user the state (available/completed/aborted/expired).

OK, you got me. We indeed should automatically keep dismissed talerURIs - just don't show them in the main view, but only in the Actions sheet. So if the user looks for available actions, they will find these automatically saved (dismissed) tx and can choose to execute them now.

And we need a "settings item" where the holding time could be set - after that time the tx would automatically be forgotten:
   Keep scanned QR codes: (Never, 1 hour, 1 day, 1 week, 1 month) default is 1 day.

Antoine A

2025-04-15 14:27

developer   ~0024554

Yes, a drag down should delete the transaction as this mean the user is not interesting in this transaction, that's what I advocate in my previous note. If the app is closed without the user having made a decision (discarding the proposal or accepting it) I think we should keep it in the database, this is really an edge case I encountered while testing.

We could add a “Save for later” action but I aim to reduce the number of a user interactions to reach what he wants/expects. This can be discussed but this would be another feature.

Displaying them in the action sheet sounds good!

Issue History

Date Modified Username Field Change
2025-03-29 18:06 Antoine A New Issue
2025-03-29 18:06 Antoine A Assigned To => Florian Dold
2025-03-29 18:06 Antoine A Status new => assigned
2025-03-29 20:15 Christian Grothoff Target Version => 1.0 stretch goals
2025-03-31 13:44 Antoine A Note Added: 0024351
2025-04-11 10:19 Antoine A Note Added: 0024508
2025-04-15 09:03 Antoine A Relationship added related to 0009683
2025-04-15 09:12 Antoine A Summary More reactive P2P flows => More reactive payment flows flows
2025-04-15 09:12 Antoine A Description Updated
2025-04-15 09:17 Antoine A Note Added: 0024546
2025-04-15 10:18 MarcS Note Added: 0024547
2025-04-15 10:51 Antoine A Note Added: 0024548
2025-04-15 12:56 MarcS Note Added: 0024551
2025-04-15 14:27 Antoine A Note Added: 0024554
2025-04-18 00:26 Christian Grothoff Tag Attached: ux
2025-04-18 00:26 Christian Grothoff Assigned To Florian Dold =>
2025-04-18 00:26 Christian Grothoff Status assigned => confirmed
2025-04-20 10:12 MarcS Relationship added related to 0008866