[taler-docs] branch master updated (647c891 -> 4407809)

[gnunet]

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

ttn pushed a change to branch master
in repository docs.

    from 647c891  Merge branch 'master' of git+ssh://git.taler.net/docs
     new db7c50a  mark up ‘requests’
     new 045dbe0  grammar: s/is//
     new cf0263e  mark up field names ‘amount’, ‘summary’, ‘fulfillment_url’
     new dda9542  say "discussed below" instead of "discussed later"
     new 25b65d0  diction: s/read/see/
     new c38aeda  mark up field names ‘contract_terms’, ‘refunded’, 
‘refunded_amount’
     new b8dc72b  fix typo: s/endpoint/endpoints/
     new db395bb  mark up field names ‘refund’, ‘reason’
     new b6965c9  change markup from " to ``
     new d9f891a  fix typo: use anchor syntax for ‘authorize-tip’
     new 6d32d8a  mark up field names ‘amount’, ‘instance’, ‘justification’, 
‘next_url’
     new bfd9cf8  fix typo: use anchor syntax for ‘pick-up-tip’
     new 32b1984  fix typo: s/reveil/reveal/
     new 6c2853b  diction: s/triplet/format/
     new 77a7d1e  mark up ‘quantity’
     new beb3ffd  mark up ‘delivery_location’
     new c27bbe9  mark up ‘product_id’, ‘price’, ‘delivery_location’
     new 4407809  mark up ‘locations’

The 18 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 taler-merchant-api-tutorial.rst | 57 ++++++++++++++++++++++-------------------
 1 file changed, 30 insertions(+), 27 deletions(-)

diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst
index 2070a94..e4a9d15 100644
--- a/taler-merchant-api-tutorial.rst
+++ b/taler-merchant-api-tutorial.rst
@@ -49,7 +49,7 @@ This chapter explains some basic concepts. In the
 second chapter, you will learn how to do basic payments.
 
 This version of the tutorial has examples for Python3. It uses the
-requests library for HTTP requests. Versions for other
+``requests`` library for HTTP requests. Versions for other
 languages/environments are available as well.
 
 If you want to look at some simple, running examples, check out these:
@@ -167,7 +167,7 @@ https://backend.demo.taler.net/:
 .. Note:: These are fictional merchants used for our demonstrators and
    not affiliated with or officially approved by the respective projects.
 
-All endpoints for instances offer the same API. Thus, which instance is
+All endpoints for instances offer the same API. Thus, which instance
 to be used is simply included in the base URL of the merchant backend.
 
 
@@ -193,26 +193,26 @@ field:
 .. index:: summary
 .. index:: fulfillment URL
 
--  amount: The amount to be paid, as a string in the format
+-  ``amount``: The amount to be paid, as a string in the format
    ``CURRENCY:DECIMAL_VALUE``, for example ``EUR:10`` for 10 Euros or
    ``KUDOS:1.5`` for 1.5 KUDOS.
 
--  summary: A human-readable summary for what the payment is about. The
+-  ``summary``: A human-readable summary for what the payment is about. The
    summary should be short enough to fit into titles, though no hard
    limit is enforced.
 
--  fulfillment_url: A URL that will be displayed once the payment is
+-  ``fulfillment_url``: A URL that will be displayed once the payment is
    completed. For digital goods, this should be a page that displays the
    product that was purchased. On successful payment, the wallet
    automatically appends the ``order_id`` as a query parameter, as well
-   as the ``session_sig`` for session-bound payments (discussed later).
+   as the ``session_sig`` for session-bound payments (discussed below).
 
 Orders can have many more fields, see `The Taler Order
 Format <#The-Taler-Order-Format>`__.  When POSTing an order,
 you can also specify additional details such as an override
 for the refund duration and instructions for inventory
 management. These are rarely needed and not covered in this
-tutorial; please read the :doc:`core/api-merchant` reference
+tutorial; please see the :doc:`core/api-merchant` reference
 manual for details.
 
 A minimal Python snippet for creating an order would look like this:
@@ -289,12 +289,12 @@ If the ``order_status`` field in the response is 
``paid``, you will not
 get a ``payment_redirect_url`` and instead information about the
 payment status, including:
 
--  contract_terms: The full contract terms of the order.
+-  ``contract_terms``: The full contract terms of the order.
 
--  refunded: ``true`` if a (possibly partial) refund was granted for
+-  ``refunded``: ``true`` if a (possibly partial) refund was granted for
    this purchase.
 
--  refunded_amount: Amount that was refunded
+-  ``refunded_amount``: Amount that was refunded
 
 Once the frontend has confirmed that the payment was successful, it
 usually needs to trigger the business logic for the merchant to fulfill
@@ -302,7 +302,7 @@ the merchant’s obligations under the contract.
 
 .. Note::
    You do not need to keep querying to notice changes
-   to the order's transaction status.  The endpoint
+   to the order's transaction status.  The endpoints
    support long polling, simply specify a ``timeout_ms``
    query parameter with how long you want to wait at most
    for the order status to change to ``paid``.
@@ -328,12 +328,12 @@ The frontend can instruct the merchant backend to 
authorize a refund by
 
 The refund request JSON object has only two fields:
 
--  refund: Amount to be refunded. If a previous refund was authorized
+-  ``refund``: Amount to be refunded. If a previous refund was authorized
    for the same order, the new amount must be higher, otherwise the
    operation has no effect. The value indicates the total amount to be
    refunded, *not* an increase in the refund.
 
--  reason: Human-readable justification for the refund. The reason is
+-  ``reason``: Human-readable justification for the refund. The reason is
    only used by the Back Office and is not exposed to the customer.
 
 If the request is successful (indicated by HTTP status code 200), the
@@ -406,7 +406,7 @@ Note that changing the session ID to a different device 
requires the
 involvement of the wallet that made the payment, thus reasonably limiting the
 possibility of broadly sharing the digital purchases.  Repurchase detection is
 also *only* done for HTTP(S) fulfillment URLs. In particular, this means
-fulfillment URIs like "taler://fulfillment-success/$MESSAGE" are not
+fulfillment URIs like ``taler://fulfillment-success/$MESSAGE`` are not
 considered to identify a resource you can pay for and thus do not have to be
 unique.
 
@@ -442,24 +442,27 @@ funds available for tipping, query the ``/tip-query`` 
endpoint:
    ...              headers={"Authorization": "ApiKey sandbox"})
    <Response [200]>
 
-authorize tip
+.. _authorize-tip:
+
 To authorize a tip, ``POST`` to ``/tip-authorize``. The following fields
 are recognized in the JSON request object:
 
--  amount: Amount that should be given to the visitor as a tip.
+-  ``amount``: Amount that should be given to the visitor as a tip.
 
--  instance: Merchant instance that grants the tip (each instance may
+-  ``instance``: Merchant instance that grants the tip (each instance may
    have its own independent tipping funds configured).
 
--  justification: Description of why the tip was granted. Human-readable
+-  ``justification``: Description of why the tip was granted. Human-readable
    text not exposed to the customer, but used by the Back Office.
 
--  next_url: The URL that the user’s browser should be redirected to by
+-  ``next_url``: The URL that the user’s browser should be redirected to by
    the wallet, once the tip has been processed.
 
 The response from the backend contains a ``tip_redirect_url``. The
 customer’s browser must be redirected to this URL for the wallet to pick
-up the tip. pick up tip
+up the tip.
+
+.. _pick-up-tip:
 
 This code snipped illustrates giving a tip:
 
@@ -527,7 +530,7 @@ Product Identification
 
 In some situations the user may have paid for some digital good, but the
 frontend does not know the exact order ID, and thus cannot instruct the
-wallet to reveil the existing payment receipt. This is common for simple
+wallet to reveal the existing payment receipt. This is common for simple
 shops without a login system. In this case, the user would be prompted
 for payment again, even though they already purchased the product.
 
@@ -564,7 +567,7 @@ max_fee
    This is the maximum total amount of deposit fees that the merchant is
    willing to pay. If the deposit fees for the coins exceed this amount,
    the customer has to include it in the payment total. The fee is
-   specified using the same triplet used for ``amount``.
+   specified using the same format used for ``amount``.
 
 .. index:: fees
 .. index:: maximum wire fee
@@ -652,7 +655,7 @@ products
       or just the count.
 
    price
-      Price for quantity units of this product shipped to the given
+      Price for ``quantity`` units of this product shipped to the given
       ``delivery_location``. Note that usually the sum of all of the prices
       should add up to the total amount of the contract, but it may be
       different due to discounts or because individual prices are
@@ -675,17 +678,17 @@ products
 
    delivery_date
       Time by which the product is to be delivered to the
-      delivery_location.
+      ``delivery_location``.
 
    delivery_location
-      This should give a label in the locations map, specifying where
+      This should give a label in the ``locations`` map, specifying where
       the item is to be delivered.
 
    Values can be omitted if they are not applicable. For example, if a
    purchase is about a bundle of products that have no individual prices
-   or product IDs, the product_id or price may not be specified in the
+   or product IDs, the ``product_id`` or ``price`` may not be specified in the
    contract. Similarly, for virtual products delivered directly via the
-   fulfillment URI, there is no delivery location.
+   fulfillment URI, there is no ``delivery_location``.
 
 merchant
    address

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.