From 7d9643064442d0c7c1c695b69fc56b2322a4213d Mon Sep 17 00:00:00 2001
From: Christian Grothoff <christian@grothoff.org>
Date: Sun, 8 Aug 2021 20:33:41 +0200
Subject: -fix misc warnings

---
 taler-mcig.rst | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

(limited to 'taler-mcig.rst')

diff --git a/taler-mcig.rst b/taler-mcig.rst
index e7c89a67..d1247aee 100644
--- a/taler-mcig.rst
+++ b/taler-mcig.rst
@@ -67,20 +67,21 @@ This guide assumes you and the customer agree to use the Taler payment system.
 At this point, you generate a *contract* and present it to the customer for
 authorization.
 The contract includes:
+
 - the total amount due;
 - a short summary;
 - a *fulfillment URI*;
-- the *duration* of the offer
-  (how long the customer has to authorize before timeout);
-- (optional) an itemized product list, with
+- the *duration* of the offer (how long the customer has to authorize before timeout);
+- (optional) an itemized product list, with:
+
   - (optional) some kind of identification for the selected product(s);
+
 - (optional) applicable taxes and fee limits;
 - (optional) an order ID (if omitted, the backend will auto-generate one);
 - (optional) information which details are *forgettable*;
 - (optional) a *claim token* that the customer can use later;
 - (optional) information on the *refund deadline*;
-- (optional) information on the the *auto-refund period* (how long does
-  the wallet check for refunds without user prompting for it).
+- (optional) information on the the *auto-refund period* (how long does the wallet check for refunds without user prompting for it).
 
 If the customer does nothing (timeout / the contract expires),
 the merchant backend automatically *unlocks* the product(s),
@@ -400,12 +401,11 @@ M: :http:post:`/instances/default/private/orders`
    }
 
 Notes:
+
 - There is no ``refund_delay`` field (no refunds possible).
-- We show the ``create_token`` field with value ``true`` even though
-  that is the default (for illustrative purposes).
+- We show the ``create_token`` field with value ``true`` even though that is the default (for illustrative purposes).
 - The ``order`` value is actually a ``MinimalOrderDetail`` object.
-- The ``fulfillment_URI`` value includes the product ID and the literal
-  string ``${ORDER_ID}``, to be replaced by the backend-generated order ID.
+- The ``fulfillment_URI`` value includes the product ID and the literal string ``${ORDER_ID}``, to be replaced by the backend-generated order ID.
 
 The backend returns ``200 OK`` with the body:
 
@@ -436,10 +436,10 @@ W: :http:post:`/orders/G93420934823/claim`
    }
 
 Notes:
+
 - The ``nonce`` value is a randomly-generated string.
 - The POST endpoint includes the order ID ``G93420934823``.
-- The ``token`` value is the claim token ``TEUFHEFBQALK``
-  received in the ``PostOrderResponse``.
+- The ``token`` value is the claim token ``TEUFHEFBQALK`` received in the ``PostOrderResponse``.
 
 The backend returns ``200 OK`` with body:
 
@@ -483,6 +483,7 @@ The backend returns ``200 OK`` with body:
    }
 
 Notes:
+
 - The backend determined both fees to be 0.015 KUDOS.
   Because the amortization is 1 (one), both fees (processing and wire
   transfer) are included in full.
@@ -535,6 +536,7 @@ W: :http:post:`/orders/G93420934823/pay`
    }
 
 Notes:
+
 - There is no session ID in the ``PayRequest`` object.
 - The total of the contribution is 8.0 + 2.0 = 10.0 KUDOS,
   which is enough to cover the purchase price (9.900 KUDOS
-- 
cgit v1.2.3