View Issue Details

IDProjectCategoryView StatusLast Update
0007473Talerwallet (Android App)public2023-11-29 01:30
Reportersebasjm Assigned ToChristian Grothoff  
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.3Fixed in Version0.9.3 
Summary0007473: The app should navigate to the article after payment: (I need manually go back)
DescriptionCurrent behavior:
1.- open on mobile browser
2.- go to an article
3.- pay it with wallet

expected: the user wanted to see the article
behavior: the user is redirected to the transaction list

 * redirect the user to the article (which webex does but controversial)
 * show the the transaction details with a clear indication of the fulfillment url (it should be obvious that this is the next step that the user need to take)

worth mention that this issues was reported by email and there is a video that explain the situation
TagsNo tags attached.



2022-11-17 18:33

developer   ~0019435

I am not sure I understand. The quoted text says "we shouldn't auto-navigate here at all", but you want to auto-navigate after payment?


2022-11-17 20:03

developer   ~0019438

The comment is describing a scenario when the QR code is scanned from the android wallet but the article is going to be read in the desktop.

So, from the desktop:
 - go the shop
 - try to read an article
 - the qr code is shown
 - pay it with the mobile wallet
 - after being paid the wallet should show the tx is completed
 - the shop in the desktop browser should detect that the order has been pay and render the article

Here the article is not shown in the mobile browser.

Alternative scenario is when the article is being accessed from the mobile browser, pay and the the wallet should redirect again to the article.


2022-11-17 20:41

developer   ~0019440

So you want after all payments that the Android wallet opens the fullfillment Uri without asking?


2022-11-18 16:37

developer   ~0019443

You mean like "you are going to be redirected to" type of question?

Maybe, I'm not sure. In the first scenario (when the redirect needs to be made, reading from mobile and paying with the same device) the user is coming FROM the article to the wallet to pay. It sounds reasonable that the user will want to go back to the article and the fulfillment url will redirect the user to that.


2023-01-05 21:27

developer   ~0019583

OK, but how do we reliably detect that the user is coming from an article they want to go back to? On Android, we don't get informed by the browser where the user is coming from, so we only see the taler:// Uri. Maybe there's something in that Uri that indicates the desire to auto-go-back to fulfillment?

Btw. a feature like this could have security implications as you can force the user to visit a certain site.

Christian Grothoff

2023-01-06 14:58

manager   ~0019593

I see. Yes, I guess we should add an argument to the taler://-URI that tells the mobile phone that it scanned a QR code on an 'external' system and thus should not navigate back itself. Something like "?nav=yes" would do, right? The QR code is where we need things to be compact, so there I would leave it out. I think the merchant can easily be modified to append such an argument when offering a link for clicking.

All agree?


2023-01-07 14:59

developer   ~0019605

I prefer not to add an extra parameter in QR more, there should be a default behavior that cover both use cases in a good enough experience.

My suggestion:
 * after payment is done we add a successful payment screen with
  -- "ok" button (go back to the wallet)
  -- "close" (close the wallet)
  -- "continue to" (follow the fulfillment url)

That I think solve what grote raise as security issue (we are not redirecting without user consent)
Also, in the use-desktop-pay-with-mobile scenario the user will see the successful screen, the browser will reload showing the article, and can use the "close" button (since the wallet is just being summoned for the payment)
If the scenario is navigating-with-mobile-and-payment, the "continue to" button or link will redirect to the article using the fulfillment url

The "ok" button there if the user want to check balance before closing.

What about that? (main idea: convention over configuration)

Christian Grothoff

2023-01-07 17:24

manager   ~0019606

Not good, as 'continue to' would be shown but would NOT work! The payment is session bound, so the browser would open but shown an error. So telling the wallet that the payment is for an article on another device (media-break) is an important hint to drive the right UX.

I'm not sure the redirecting without user consent is an issue. The user consented to actually spend money already. If I can get you to do that, it's probably OK if I can ask you to open a web page ;-).

Now, the really funky case is where the user opened in a browser, paid by mobile, and then _later_ wants to go back to the article on the mobile. Here, we'll need to open the browser, the browser will trigger the wallet, and then the wallet's repurchase detection has to change the payment in the merchant backend to the new session on the mobile and go back to the browser.

Still, with my extra taler://-URI argument, all of this is possible and we don't show the user 'strange' paths that don't work.


2023-01-07 22:35

developer   ~0019607

> Not good, as 'continue to' would be shown but would NOT work! The payment is session bound, so the browser would open but shown an error.
Well, this is bad.
AFAIK the merchant front-office has a volatile session that is used to bound the payment with the article, if that session is lost the user will need to pay again?

If I ever payed for an article I would like to go back again even if I lost the session, isn't? That would mean that fulfillment URL should work in any setup. Like carrying the orderId and a prove of ownership in the request params (session-less)

> Now, the really funky case is where the user opened in a browser, paid by mobile, and then _later_ wants to go back to the article on the mobile.
This seems equal to the "continue to" plus a delay before clicking.

> I'm not sure the redirecting without user consent is an issue. The user consented to actually spend money already. If I can get you to do that, it's probably OK if I can ask you to open a web page ;-)

Sending a user to another app or external site (other than the wallet) should be warned.
Merchant input should be considered untrusted from the wallet perspective and this lead to open-redirect issues

> repurchase detection has to change the payment in the merchant backend to the new session on the mobile and go back to the browser
I don't have very clear how the repurchase work. Is this some missing feature what you are describing?

Christian Grothoff

2023-01-07 23:01

manager   ~0019608

Repurchase detection is exactly the feature you are looking for, and is implemented. Basically, if you did already pay for an article, but in a different session, you are first asked to pay again. But once you try, the wallet detects that you did already pay before, and simply proves to the merchant that you paid before, and asks the merchant to change the session ID on the purchase to the current session. BUT what this means is that if the user switches devices, they will get asked to pay again first, and have to scan the QR code with the wallet (or see some jumping around if the browser can auto-trigger the wallet) to allow the wallet to see the repurchase and rebind the session.

Florian Dold

2023-04-05 17:35

manager   ~0020025

I don't think that Christian's approach can work. How would the merchant decide whether it is a "media break" or not?
When I click on an article in the blog demo, the merchant doesn't know whether I'm gonna pay with the browser wallet or the phone wallet.

I'm proposing a different user experience: When going to the fulfillment URL, the merchant checks if there is a session mismatch.
If the session matches, the article is rendered.
On a mismatch, it offers to instead view the article in this browser. It then shows the QR code page.

That's one more step, but it IMHO makes the user experience much clearer.

And maybe the wallet can also add additional information to the fulfillment URL to make clear that this is a repurchase.

IMHO we need to go back to the drawing board for the blog shop article, because it's currently both horribly complicated *and* not fully working.


2023-07-05 15:17

developer   ~0020339

I have updated the description and since the original video was reported to android, I moving this issue to android but it should also be considered for iOS


2023-07-08 13:28

developer   ~0020346

iOS has the same problem as Android: it cannot detect whether the user tapped on a link in Mobile Safari (on the phone) or used the built-in camera app (not its own Scan QR Dialog) to scan the QR code and pass the decoded link to the app. In both cases, the app only gets a taler:// URI to open.
Only if the user taps the app's own Scan QR button it is clear that the user is scanning another device, and wouldn't want to open the fullfillment URI on the iPhone after payment.

However, if the user tapped the link on the phone to switch from Safari to our app, then iOS itself shows a very small button in the top left corner reading "Safari", which brings the user right back to the web page where the link was tapped. And every iOS user knows this...

Thus, this is a non-issue for iOS. Either the fullfillment is on another device, or the user can tap the small "Safari" button in the top left corner to go back to the merchant website where the payment link originated.


2023-07-08 13:39

developer   ~0020347

I had my 15year old nephew here last week to try the iOS app for the very first time. He had absolutely no problems switching between
a) bank and wallet app after having solved the math puzzle on the bank website
and b) wallet app and shop after payment finished. He saw that the payment sheet vanished and the balance updated, and immediately switched to the shop to notice he could now read the paid article.

So I won't show a fulfillment button on iOS - it's not necessary. Users know how to switch back to the browser where they started the payment process.

Christian Grothoff

2023-11-22 15:56

manager   ~0020656

I just tested the current situation on Android, and it works OK. If Marc is happy enough on iOS (and it does work nicely in browsers already), I think we can consider this done.

Issue History

Date Modified Username Field Change
2022-11-17 18:20 sebasjm New Issue
2022-11-17 18:20 sebasjm Status new => assigned
2022-11-17 18:20 sebasjm Assigned To => grote
2022-11-17 18:33 grote Note Added: 0019435
2022-11-17 20:03 sebasjm Note Added: 0019438
2022-11-17 20:23 sebasjm Target Version git (master) => 0.9.1
2022-11-17 20:41 grote Note Added: 0019440
2022-11-18 16:37 sebasjm Note Added: 0019443
2022-12-20 18:26 Christian Grothoff Target Version 0.9.1 => 0.9.2
2023-01-05 21:27 grote Note Added: 0019583
2023-01-05 21:27 grote Assigned To grote => Christian Grothoff
2023-01-05 21:27 grote Status assigned => feedback
2023-01-06 14:58 Christian Grothoff Note Added: 0019593
2023-01-06 14:59 Christian Grothoff Assigned To Christian Grothoff => sebasjm
2023-01-06 14:59 Christian Grothoff Assigned To sebasjm => Florian Dold
2023-01-07 14:59 sebasjm Note Added: 0019605
2023-01-07 14:59 sebasjm Status feedback => assigned
2023-01-07 17:24 Christian Grothoff Note Added: 0019606
2023-01-07 22:35 sebasjm Note Added: 0019607
2023-01-07 23:01 Christian Grothoff Note Added: 0019608
2023-02-19 14:27 Florian Dold Target Version 0.9.2 => 0.9.3
2023-04-05 17:35 Florian Dold Assigned To Florian Dold => sebasjm
2023-04-05 17:35 Florian Dold Status assigned => feedback
2023-04-05 17:35 Florian Dold Note Added: 0020025
2023-07-05 15:16 sebasjm Description Updated
2023-07-05 15:16 sebasjm Assigned To sebasjm => grote
2023-07-05 15:17 sebasjm Note Added: 0020339
2023-07-05 15:17 sebasjm Status feedback => assigned
2023-07-08 13:28 MarcS Note Added: 0020346
2023-07-08 13:39 MarcS Note Added: 0020347
2023-07-26 18:27 Christian Grothoff Assigned To grote => Christian Grothoff
2023-09-23 15:00 Christian Grothoff Priority normal => high
2023-09-23 15:00 Christian Grothoff Target Version 0.9.3 => 0.9.4
2023-11-22 15:56 Christian Grothoff Status assigned => resolved
2023-11-22 15:56 Christian Grothoff Resolution open => fixed
2023-11-22 15:56 Christian Grothoff Fixed in Version => 0.9.4
2023-11-22 15:56 Christian Grothoff Note Added: 0020656
2023-11-29 01:28 Christian Grothoff Target Version 0.9.4 => 0.9.3
2023-11-29 01:29 Christian Grothoff Fixed in Version 0.9.4 => 0.9.3
2023-11-29 01:30 Christian Grothoff Status resolved => closed