View Issue Details

IDProjectCategoryView StatusLast Update
0006453Talermerchant backend API (HTTP specification)public2021-08-24 16:23
ReporterFlorian Dold Assigned ToFlorian Dold  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version0.8Fixed in Version0.8 
Summary0006453: come to consensus on /orders/{order_id} page and semantics of refunds
DescriptionRelated 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

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

TagsNo tags attached.


Florian Dold

2020-07-31 19:41

manager   ~0016538

(We might want to discuss this outside the bug tracker, just putting it here so it doesn't get lost)

Christian Grothoff

2020-08-02 23:29

manager   ~0016542

I think the consensus is described in 0006457. Also, we keep both taler://pay and taler://refund/ URIs.

Christian Grothoff

2020-08-03 13:54

manager   ~0016554

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".

Florian Dold

2020-08-20 14:13

manager   ~0016678

We've agreed by now on how it should work. There's also an integration test covering it.

Issue History

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