taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] transaction history UX and fulfillment URL semantics


From: Christian Grothoff
Subject: Re: [Taler] transaction history UX and fulfillment URL semantics
Date: Sun, 24 Jan 2016 20:42:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

This does not work, at least in terms of giving the desired
simplification.  (Sure, supporting this by the merchant will
give the user the ability to bookmark the fulfillment page, but that's
not the main point of your argument).

Let me explain why the simplification for replay from the transaction
history does not work: One of the key reasons for replay from
transaction history is that the network (or either endpoint) may fail
during a transaction. So suppose the wallet issued /pay, but the
merchant didn't get it (or at least failed to commit to disk). In this
case, the merchant must not enable the fulfillment page, as payment has
not yet happened.

The point of the replay from transaction history is now that the user
can replay the payment, thereby *possibly* completing or replaying it it
(remember: we just don't know when the network/merchant/client died).
Having two different mechanisms (replay vs. direct fulfillment) would be
confusing, so the GUI should only have one link.

We could of course streamline this and replace the 'replay' link with a
direct link to the fulfillment page if we ever got the fulfillment page
for this transaction before (thus know that the transaction did
complete) -- if we also know that the merchant supported the
bookmarking.  Still, that's an _optimization_ which would make the
wallet more complicated, not simpler, as the replay from transaction
history must support full replay of the payment in any case.

My conclusion: let's implement the simplest version first (reply payment
always).

I'm open to requiring the merchant to make the fulfillment page
bookmark-able, thereby enabling us to implement the optimization in the
future ("2.0")

On 01/24/2016 08:33 PM, Florian Dold wrote:
> Just to be clear, note that this does not imply that there can't be any
> "digital deliverables" that are part of the contract that do rely on
> session information.
> 
> But it does mean that merchants have to provide a "landing page" for
> contracts that can be bookmarked, and that will do the right thing when
> the session state is wrong or the contract with that UUID wasn't purchased.
> 
> It would also simplify URL handling quite a bit, since we'd basically
> *just* need the fulfillment URL (no payment and no execution URL), and
> the merchant will give us the other stuff if necessary (you know,
> RESTfulness ...)
> 
> - Florian
> 
> On 01/24/2016 08:14 PM, Florian Dold wrote:
>> Hi,
>>
>> I'm wondering what's the best way to go back to completed purchases that
>> show up in the transaction history.
>>
>> One way would be to *always* do replay, and never rely on the cached
>> fulfillment URL.  The user is free to remember or bookmark the
>> fulfillment URL, but the wallet will never remember it.
>>
>> I guess this is currently the "correct" way to do it, since we can never
>> know whether the user agent still has the necessary state to view the
>> fulfillment URL, and we can't really detect if going to the fulfillment
>> URL in the browser fails and offer re-playing the purchase.
>>
>> The alternative would be to require the merchant-internal contract
>> identifier to be also added to the *fulfillment* URL.
>>
>> This way the merchant's fulfillment page can detect that the session
>> state is missing, and redirect the user agent to the execution page,
>> where the payment will be replayed.  If the contract can't be replayed
>> (because it's missing in the wallet), the user agent will be redirected
>> to a checkout page.
>>
>> The second approach requires changes to the merchant, but I like it
>> better for these reasons:
>>
>> * The user can bookmark fulfillment URLs, and they will always work as
>> long as the contract is in the user agent's wallet.
>> * The wallet does not have to implement any special logic and user
>> interface for contract replay.  It's just a link to the fulfillment page
>> (that contains the UUID).
>>
>> Again, this would restrict the merchant a bit, but for the user there's
>> much less magic going on, and common things (like bookmarking or sending
>> URLs to a friend) just works.
>>
>> Alternatively, strange things will happen:  I bookmark the fulfillment
>> page for a donation I made (maybe because I want to print it later), but
>> then I make another donation and suddenly my bookmarked page is gone,
>> but it *does* work when I click the "replay" button from the wallet ...
>> this doesn't sound right from the user's perspective.
>>
>> Thoughts?
>>
>> - Florian
>>
> 

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]