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

[Florian Dold]

On 01/24/2016 08:42 PM, Christian Grothoff wrote:
> 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.

Yes.  The merchant must always detect whether the user may access the
"real" fulfillment page.  I don't see why this does not work with the
simplification.

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

That was the main point of my original message, that this distinction
would be confusing.

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

The merchant *has* to support what you call bookmarking for the
execution page (to allow the WebEx wallet to re-play) anyways.  My
suggestion just streamlines the spec, by combining the fulfillment page
and execution page into one.

Maybe we're not agreeing on terminology.  You could just say that the
execution page shows a link to the fulfillment page if the payment
succeeds, that is equivalent to my suggestion (but keeps your definition
/ semantics for the fulfillment page).

Again, either we're disagreeing just about terminology, or your
suggestion wouldn't support replay (if I'm not missing something else ...).

- Florian

signature.asc
Description: OpenPGP digital signature