|author||Christian Grothoff <firstname.lastname@example.org>||2020-10-25 22:59:28 +0100|
|committer||Christian Grothoff <email@example.com>||2020-10-25 22:59:28 +0100|
Diffstat (limited to 'taler-merchant-api-tutorial.rst')
1 files changed, 3 insertions, 3 deletions
diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst
index 39cf36d..823a675 100644
@@ -377,7 +377,7 @@ are recognized in the JSON request object:
- amount: Amount that should be given to the visitor as a tip.
- instance: Merchant instance that grants the tip (each instance may
- have its own independend tipping funds configured).
+ have its own independent tipping funds configured).
- justification: Description of why the tip was granted. Human-readable
text not exposed to the customer, but used by the Back Office.
@@ -533,14 +533,14 @@ signature (``session_sig``). This signature certifies that the wallet
showed a payment receipt for the respective order in the current
-Session-bound payments are triggerd by passing the ``session_id``
+Session-bound payments are triggered by passing the ``session_id``
parameter to the ``/check-payment`` endpoint. The wallet will then
redirect to the fulfillment page, but include an additional
``session_sig`` parameter. The frontend can query ``/check-payment``
with both the ``session_id`` and the ``session_sig`` to verify that the
signature is correct.
-The last session ID that was successfuly used to prove that the payment
+The last session ID that was successfully used to prove that the payment
receipt is in the user’s wallet is also available as ``last_session_id``
in the response to ``/check-payment``.