View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006453 | Taler | specification | public | 2020-07-31 19:40 | 2021-08-24 16:23 |
| Reporter | Florian Dold | Assigned To | Florian Dold | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0006453: come to consensus on /orders/{order_id} page and semantics of refunds | ||||
| Description | Related e-mail discussion: On 7/31/20 2:09 PM, Florian Dold wrote: In my understanding, refunds can be partial and incremental. That means the fulfillment page will *always* still be shown, but it might be "degraded". So it might just show some text "You've bought this video but have gotten a refund. Click here to buy access again". Or "You can't download the high-res version of this picture, as you've gotten a refund. Here's the low-res thumbnail.". Thus I always thought we should indeed go to the fulfillment page even after a refund. Where else should we go? Smuggling in some other URL is not really clean. The shop should handle showing refunded fulfillment pages nicely anyway, because the fulfillment URL might be bookmarked. My main problem with your suggestion (pay/paid/refund below) is that is does not map well at all to the intention of the end user. Generally, the end user will want to use the wallet with three different intentions when currently interacting with a merchant: 1. Giving money to the merchant, because the merchant is offering to give them something for it. That's the initial "taler://pay" entry point. Here, I completely object to making the user manually click the fulfillment URL. What if they click it too early? They'll confusingly will land on the same page again, giving a "something's not working correctly" feel to the whole experience. It should really auto-redirect, let's not make users click when there is no need to. 2. Navigating to some page on the merchant's Website (article, video, purchase receipt) that the user wants to view, because they have paid for it. Your "paid" doesn't map naturally to this use case, since the merchant *might not know* that the user's wallet already paid for it! As a user, I don't really care at this point if there's a refund, I just want to view the fulfillment page (even if it might then tell me I can't view it anymore) 3. The user interacted with the merchant, and obtained a refund. They now want to make sure that they actually received the refund. It is IMHO natural to go to the fulfillment page after the refund was applied. But here the "taler://refund" URI has a problem: The browser might have a fresh session ID for the shop page, and thus the fulfillment page will prompt payment again. So it is IMHO natural that the wallet *also* proves payment under the current session ID during/after a refund. Now, I can live with having a separate "taler://refund" to make (3) more visually distinct, but I think it should really just be an alias for "taler://pay", maybe with the tiny difference that "taler://refund" can't be used to trigger the *initial* payment. So in summary, my suggestion is: * keep both taler://pay and taler://refund URIs * make *almost* be aliases for one another * allow the shop to navigate the user to the "order HTML page" in either the "payment" mode or the "refund" mode (via /orders/{id}?refund=<0,1>). * the payment mode will have a taler://pay URI * the payment mode will auto-redirect * the refund mode will have a taler://refund URI and slightly different text * the refund mode won't auto-redirect, but only show a button/link "view product page" that is *only* visible after the paid session ID matches the browser's session ID ---------------------------- On 7/31/20 11:45 AM, Christian Grothoff wrote: > On 7/30/20 11:24 PM, Florian Dold wrote: >> Okay, I think I can work with a variation of that! >> >> But unless we use JS or put two QR codes next to each other (let's never >> do this!), we still need some flag that tells the backend what to show >> after the "entry point". > > Eh, I'm confused. I agree we should never show two QR codes. But > _either_ the contract is paid, *or* there is a refund. It can never be > both (no refunds for unpaid contracts), so I don't see the problem. > >> A link to the fulfillment page is not enough, as if you don't have the >> cookie, going to the fulfillment URL will just bring you back to the >> order HTML page > > Well, that just sounds like a(nother) good reason for not automatically > redirecting to the fulfillment URL . > > We could: > - unpaid: show taler://pay/ URI > - paid: show a NEW taler://paid/ URI which includes the _current_ > session ID of the visitor and triggers the repurchase logic if scanned > by a mobile wallet > - refunded: show taler://refund/ URI | ||||
| Tags | No tags attached. | ||||
|
|
(We might want to discuss this outside the bug tracker, just putting it here so it doesn't get lost) |
|
|
I think the consensus is described in 0006457. Also, we keep both taler://pay and taler://refund/ URIs. |
|
|
I've implemented my understanding of the consensus now - modulo nice HTML. Florian: Please check the code in taler-merchant-httpd_get-orders-ID.c to see if this is OK with you. Then resolve this one. I'll keep 0006457 open until the HTML output is "nice". |
|
|
We've agreed by now on how it should work. There's also an integration test covering it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-07-31 19:40 | Florian Dold | New Issue | |
| 2020-07-31 19:40 | Florian Dold | Status | new => assigned |
| 2020-07-31 19:40 | Florian Dold | Assigned To | => Marcello Stanisci |
| 2020-07-31 19:41 | Florian Dold | Assigned To | Marcello Stanisci => Christian Grothoff |
| 2020-07-31 19:41 | Florian Dold | Status | assigned => feedback |
| 2020-07-31 19:41 | Florian Dold | Note Added: 0016538 | |
| 2020-08-02 23:29 | Christian Grothoff | Note Added: 0016542 | |
| 2020-08-02 23:32 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2020-08-03 13:54 | Christian Grothoff | Note Added: 0016554 | |
| 2020-08-20 14:13 | Florian Dold | Status | feedback => resolved |
| 2020-08-20 14:13 | Florian Dold | Resolution | open => fixed |
| 2020-08-20 14:13 | Florian Dold | Note Added: 0016678 | |
| 2020-09-11 22:24 | Christian Grothoff | Fixed in Version | => 0.8 |
| 2020-09-11 22:24 | Christian Grothoff | Target Version | => 0.8 |
| 2021-08-24 16:23 | Christian Grothoff | Status | resolved => closed |
| 2024-01-12 14:02 | Christian Grothoff | Category | merchant backend API (HTTP specification) => specification |
