[GNUnet-SVN] [taler-merchant] branch master updated: document tipping

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository merchant.

The following commit(s) were added to refs/heads/master by this push:
     new 70caa1b  document tipping
70caa1b is described below

commit 70caa1ba3a47fa8e400ae3e7112ca581d0902118
Author: Christian Grothoff <address@hidden>
AuthorDate: Sat Nov 11 18:29:42 2017 +0100

    document tipping
---
 doc/manual.texi | 190 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 190 insertions(+)

diff --git a/doc/manual.texi b/doc/manual.texi
index 0893b8e..5ebdb7e 100644
--- a/doc/manual.texi
+++ b/doc/manual.texi
@@ -853,6 +853,7 @@ $ taler-merchant-dbinit -r
 * Using taler-config::      Introduction to the taler-config tool
 * Key management::          Managing the merchant's cryptographic keys
 * SEPA configuration::      Configuring a SEPA bank account
+* Tipping visitors::        Giving money to Web site visitors with Taler
 @end menu
 
 @node Configuration in Taler
@@ -1030,6 +1031,195 @@ we expect future versions of the Taler backend to ship 
with
 pre-configured exchanges and auditors for common denominations.
 
 
+
address@hidden Tipping visitors
address@hidden Tipping visitors
address@hidden tipping
+
+Taler can also be used to tip Web site visitors.  For example, you may
+be running an online survey, and you want to reward those people that have
+dutifully completed the survey.  If they have installed a Taler wallet,
+you can provide them with a tip for their deeds.  This section describes
+how to setup the Taler merchant backend for tipping.
+
+There are four basic steps that must happen to tip a visitor.
+
address@hidden Configure a reserve and exchange for tipping
address@hidden gnunet-ecc
address@hidden reserve key
+
address@hidden TODO: We should probably create a tool that automates the
address@hidden configuration process and simply outputs the wire transfer
address@hidden subject of the reserve.
+
+To tip users, you first need to create a reserve.  A reserve is a pool
+of money held in escrow at the Taler exchange.  This is the source of
+the funds for the tips.  Tipping will fail (resulting in disappointed
+visitors) if you do not have enough funds in your reserve! To create a
+reserve for tipping, you need to first create a tipping key.  Use
+
address@hidden
+$ gnunet-ecc -g 1 tip.priv
address@hidden example
+
+to create a file with the private key that will be used to identify the
+reserve.  Then, run
+
address@hidden
+$ gnunet-ecc --print-private-key tip.priv
address@hidden example
+
+to print out the corresponding private key.  It will looks like
+this:
+
address@hidden
+QPE24X8PBX3BZ6E7GQ5VAVHV32FWTTCADR0TRQ183MSSJD2CHNEG
address@hidden example
+
+Now you can configure your backend.  You need to enable tipping for
+each instance separately, or you can use an instance only for
+tipping.  To configure the ``default'' instance for tipping, use
+the following configuration:
+
address@hidden
+[merchant-instance-default]
+# this is NOT the tip.priv
+KEYFILE = signing_key.priv
+# replace the URL with the URL of the exchange you will use
+TIP_EXCHANGE = https://exchange:443/
+# here put the output of gnunet-ecc -P tip.priv
+TIP_RESERVE_PRIV = ENK9E0GYJ5EJEEC0QN3GY7KJRMNXW3B2SSWQDNJ3F1CEMFGC0970
address@hidden example
+
+Note that the KEYFILE option should have already been present for
+the instance. It has nothing to do with the ``tip.priv'' file we
+created above, and you should probably use a different file here.
+
+Instead of manually editing the configuration, you could also run:
+
address@hidden
+$ taler-config -s merchant-instance-default \
+    -o TIP_RESERVE_PRIV \
+    -V `gnunet-ecc -P tip.priv`
+$ taler-config -s merchant-instance-default \
+    -o TIP_EXCHANGE \
+    -V https://exchange:443/
address@hidden example
+
+Now you can (re)start the backend with the new configuration.
+
address@hidden Fund the reserve
address@hidden reserve
address@hidden close
+
+To fund the reserve, you must first extract the public key from ``tip.priv'':
+
address@hidden
+$ gnunet-ecc --print-public-key tip.priv
address@hidden example
+
+The result will look very much like the private key, so be
+very careful to not confuse the two!  In our example, the
+output for the public key is:
+
address@hidden
+QPE24X8PBX3BZ6E7GQ5VAVHV32FWTTCADR0TRQ183MSSJD2CHNEG
address@hidden example
+
+You now need to make a wire transfer to the exchange's bank account
+using the public key as the wire transfer subject.  The exchange's
+bank account details can be found in JSON format at
+``https://exchange:443//wire/METHOD'' where METHOD is the respective
+wire method (i.e. ``sepa'').  Depending on the exchange's operator,
+you may also be able to find the bank details in a human-readable
+format on the main page of the exchange.
+
+Make your wire transfer and (optionally) check at
+``https://exchange:443/reserve/status/reserve_pub=QPE24X...''
+whether your transfer has arrived at the exchange.
address@hidden FIXME: we should create a nicer tool to do this check!
+Once the funds have arrived, you can now enable tipping using:
+
address@hidden
+$ taler-merchant-tip-enable \
+    --amount=AMOUNT \
+    --backend=BACKEND_URI \
+    --credit-uuid=CREDIT_UUID \
+    --instance=INSTANCE \
+    --expiration=EXPIRATION
address@hidden example
+For ``AMOUNT'', specify the amount you transferred in the usual Taler
+format of ``CURRENCY:VALUE[.FRACTION]'', i.e. ``EUR:50''.  The
+``BACKEND_URI'' should be the URI where your Taler merchant backend is
+running.  For ``CREDIT_UUID'', you need to specify a unique number
+that identifies your wire transfer.  You may have gotten one from your
+bank, or you can just make one up! The important thing is that you
+must never use the same UUID twice, except to repeat a failed command.
+For INSTANCE, specify the backend instance (i.e. ``default'').
+Finally, for EXPIRATION, pick a date two weeks after the wire
+transfer, unless you know that the exchange that is being used has a
+different period for closing reserves.
+
+Note that an exchange will typically close a reserve after two weeks,
+wiring all remaining funds back to the sender's account.  Thus, you
+should plan to wire funds corresponding to a campaign of about two
+weeks to the exchange initially. If your campaign runs longer, you
+should wire further funds to the reserve every week to prevent it from
+expiring.  You need to run the ``taler-merchant-tip-enable'' command
+each time after you wire more funds to the reserve.
+
+
address@hidden Authorize a tip
+
+When your front end has reached the point where a client is supposed
+to receive a tip, it needs to first authorize the tip. For this,
+the frontend must use the ``/tip-authorize'' API of the backend.
+To authorize a tip, the frontend has to provide the amount to
+authorize, the name of the instance, and a justification.  The
+justification is just a string that is stored in the database with
+the transaction.  It is not meaningful for Taler.
+
+In response to this triplet, the backend will return a tip identifier,
+an expiration time and the exchange URI.  The expiration time will
+indicate how long the tip is valid (when the reserve expires).  The
+tip identifier allows the client's wallet to pick up the tip.  The
+frontend must now send the tip identifier, expiration time, EXCHANGE
+URI and the total amount to the exchange in a special ``402 Payment Required''
+response with the following headers:
+
address@hidden
+X-Taler-Tipping-Url: PICKUP URL with tip ID
+X-Taler-Tipping-Exchange: EXCHANGE URL
+X-Taler-Tipping-Amount: AMOUNT
+X-Taler-Tipping-Deadline: EXPIRATION
address@hidden example
+
+The first header line must include a Web URL for picking up the tip.
+It should include the tip ID (or at least some information that the
+frontend can use to lookup the tip ID).  For example, it might be
+``https://shop/tip-pickup?tip_id=ID'' where ``ID'' is the tip ID
+that was returned from the backend.  Finally, the frontend must
+implement this ``/tip-pickup'' handler, as described in the next
+section.
+
+The frontend should handle errors returned by the backend, such
+as missconfigured instances or a lack of remaining funds for tipping.
+
+
address@hidden Picking up of the tip
+
+The wallet will POST a JSON object with a single member ``planchets''
+to the shop's ``/tip-pickup'' handler.  The frontend must then add the
+``tip_id'' field to this JSON body and forward it to the
+``/tip-pickup'' handler of the backend.  The response generated by the
+backend can then be forwarded directly to the wallet.  However, the
+frontend may want to add a field ``next_url'' to provide a suggestion
+as to where the wallet should navigate after picking up the tip.  A
+common value for ``next_url'' would be the home page of the shop.
+
address@hidden FIXME: document ``next_url'' somewhere in the API specs?
+
+
 @c **********************************************************
 @c *******************  Appendices  *************************
 @c **********************************************************

-- 
To stop receiving notification emails like this one, please contact
address@hidden