commit 1618db53416dcf0340e0bbde52f09464d6dcc925
parent 3764a1cbe2ba5e15c5f3d0ab6126012318a2df3c
Author: Florian Dold <florian.dold@gmail.com>
Date: Wed, 8 Mar 2017 03:16:33 +0100
proposal format
Diffstat:
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/api/api-merchant.rst b/api/api-merchant.rst
@@ -148,7 +148,7 @@ The following API are made available by the merchant's `backend` to the merchant
.. _proposal:
- The backend expects an `order` as input. The sketch is an :ref:`ProposalData`_
+ The backend expects an `order` as input. The order is a :ref:`ProposalData`_
object **without** the fields:
* `exchanges`
@@ -161,6 +161,9 @@ The following API are made available by the merchant's `backend` to the merchant
in by the backend if not present:
* `merchant.instance` (default instance will be used)
+ * `order_id` (random alphanumeric identifier will be used)
+ * `refund_deadline` (instance's default will be used)
+ * `pay_deadline` (instance's default will be used)
**Response**
@@ -517,9 +520,6 @@ The `proposal data` must have the following structure:
// invalid and also interpreted as 1.
wire_fee_amortization: Integer;
- // A free-form identifier for this transaction.
- transaction_id: string;
-
// List of products that are part of the purchase (see `below <Product>`_)
products: Product[];
@@ -551,10 +551,14 @@ The `proposal data` must have the following structure:
// Map from labels to locations
locations: { [label: string]: [location: Location], ... };
+ // Nonce generated by the wallet and echoed by the merchant
+ // in this field when the proposal is generated.
+ nonce: string;
+
// Extra data that is only interpreted by the merchant frontend.
// Useful when the merchant needs to store extra information on a
// contract without storing it separately in their database.
- extra: any;
+ extra?: any;
}
The wallet must select a exchange that either the mechant accepts directly by