diff options
| -rw-r--r-- | example-essay-store.rst | 48 | ||||
| -rw-r--r-- | integration-merchant.rst | 20 |
2 files changed, 68 insertions, 0 deletions
diff --git a/example-essay-store.rst b/example-essay-store.rst index 2271fa39..5a1539a7 100644 --- a/example-essay-store.rst +++ b/example-essay-store.rst @@ -61,3 +61,51 @@ In step 2, the `taler-execute-contract` event has the following parameters: Note that we assume that all essays cost the same (otherwise the amount would have to be included in the restoration information in the /essay fulfillment URL). The refund deadline is computed by adding the merchant-specific constant `REFUND_DELTA` to the contract's timestamp. + +.. + Describing implementation of the above scenario + +The essay store, available at https://blog.demo.taler.net, is such that its homepage +is basically a list to buyable articles and each list item is a reference to an `offering +URL` (see :ref:`offer`). In particular, this offering URL has the following format: + + `/essay_fulfillment.php?article=articleId` + +It is worth noting that in our implementation the `offering` and the `fulfillment` URLs +differ only respect to the given parameters to the path `/essay_fulfillment.php`. Namely, +it acts as a fulfillment URL when the user adds the parameters needed to reconstruct the +contract, which are `tid` (transaction id) and `timestamp` (see :ref:`tsref-type-Contract`, +and :ref:`ffil`). For the sake of completeness, + + + `/essay_fulfillment.php?article=articleId&tid=3489×tamp=8374738` + +would be a fulfillment URL. + +Once the user visits the offering URL by clicking on some article's title, the merchant + +1. checks if the state associated to this article corresponds to "payed". If this is the + case, it goes to point `x`, which is what happens when point 0 of :ref:`offer` + is true. + +2. checks if the user gave additional parameters to the URL above, actually making it a + fulfillment URL. If so, jump to point `y`. + +3. returns a page which can detect if a Taler wallet is installed in the user's browser and, + if so, automatically downloads the contract from the merchant; if not, displays a paywall + for credit card payment. Note that the contract's request is entirely managed by the page's + JavaScript and not by the wallet (FIXME explain reason). The wallet gets involved once the + contract arrives and the JavaScript fires a `taler-confirmation-event` containing the contract, + see point 1. of :ref:`offer`. + +4. the wallet then visits the fulfillment URL associated with this purchase (the fulfillment + URL's path is indicated in the contract, so the wallet has to just add `tid` and `timestamp` + to it). + +5. the same script as in point 1. gets executed but this time it detects that the user is visiting + fulfillment URL. FIXME FINISH + + + + +x. Display article `articleId` diff --git a/integration-merchant.rst b/integration-merchant.rst index 289b9ce5..f2f2fc02 100644 --- a/integration-merchant.rst +++ b/integration-merchant.rst @@ -1,3 +1,17 @@ +.. + This file is part of GNU TALER. + Copyright (C) 2014, 2015, 2016 INRIA + TALER is free software; you can redistribute it and/or modify it under the + terms of the GNU General Public License as published by the Free Software + Foundation; either version 2.1, or (at your option) any later version. + TALER is distributed in the hope that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR + A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. + You should have received a copy of the GNU Lesser General Public License along with + TALER; see the file COPYING. If not, see <http://www.gnu.org/licenses/> + + @author Marcello Stanisci + ================================== Interaction with merchant websites ================================== @@ -28,10 +42,14 @@ a physical good on his screen, the user will receive it by mail. IIG triggers different flows according to the user visiting an offering or a fulfillment URL. For clarity, below are listed the steps taken when the user visits an offering URL. +.. _offer: + --------------------- IIG by `offering` URL --------------------- +0. If the state associated to the resource requested is `payed`, go to 7. + 1. The merchant sends the following object embedded in a `taler-confirm-contract` event .. code-block:: tsref @@ -96,6 +114,8 @@ IIG by `fulfillment` URL We stress again that the fulfillment URL contains all the information a merchant needs to reconstruct a contract. +0. If the state associated to the resource requested is `payed`, go to point 7 above. + 1. The user visits a fulfillment URL 2. The merchant replies with the same data structure shown in point 4 above |