View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009670 | Taler | wallet (all platforms) | public | 2025-03-29 18:06 | 2025-05-08 21:58 |
| Reporter | Antoine A | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | confirmed | Resolution | open | ||
| Target Version | post-1.0 | ||||
| Summary | 0009670: More reactive payment flows flows | ||||
| Description | Wallets 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. | ||||
| Tags | ux | ||||
| has duplicate | 0009789 | closed | MarcS | Unfinished transactions in history should lead to respective flows |
| related to | 0009683 | closed | Florian 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)` |
|
|
Florian told me that wallet-core should already notify this to the user interface, so it should be possible with the current logic. |
|
|
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. |
|
|
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. |
|
|
@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. |
|
|
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). |
|
|
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. |
|
|
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! |
| 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 |
| 2025-05-07 12:41 | MarcS | Relationship added | has duplicate 0009789 |
| 2025-05-08 21:58 | Christian Grothoff | Target Version | 1.0 stretch goals => post-1.0 |
