[Top][All Lists]

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

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

From: Christian Grothoff
Subject: Re: [Taler] replay and merchant backend/frontend protocol
Date: Tue, 26 Jan 2016 14:00:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

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.

Attachment: 0xE29FC3CC.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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