[Top][All Lists]

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

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

From: Florian Dold
Subject: Re: [Taler] transaction history UX and fulfillment URL semantics
Date: Sun, 24 Jan 2016 20:33:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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

reply via email to

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