Re: [Taler] replay and merchant backend/frontend protocol

[Christian Grothoff]

On 01/26/2016 12:02 PM, Hartmut Goebel wrote:
> Am 26.01.2016 um 11:19 schrieb Christian Grothoff:
>> The trade-off question was about _when_ the merchant stores it:
>> only when the contract is successful (paid), or already when it is
>> being generated (proposed by the merchant).  Depending on the type
>> of application (i.e. serving data vs. shipping goods), being lazy
>> and only storing 'paid' contracts can reduce database transaction
>> volume.
> 
> IC. But in both cases the merchant will have some kind of "shopping 
> card", wouldn't he?

Not a real cart, not for single-article purchases.

> Even for a single, immediately downloaded item
> the merchant needs to keep track of her offering - simply because
> there are different VAT rates in the EU. [1] So she already needs to
> store the data anywhere in his own shop.

Only *after* the purchase.  The fact that some prospective customer
visits the site and requests a proposal for a contract doesn't have to
be persisted.  And that's the crux: we want to be able to largely avoid
having to do any database operations *unless* payments are involved.
Once the customer pays, sure, then we persist the coins, the payment
confirmations, and of course the contract.  But, after long in-person
discussions today, we think we found a reasonable solution for avoiding
merchants having to DB-persist reasonably trivial shopping carts and
otherwise do everything we want: simply encode the cart data in the URI
if it is very simple (i.e. an article identifier).  That way, the wallet
doesn't have to upload the "long" contract, and the merchant doesn't
have to persist it either.

0xE29FC3CC.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature