summaryrefslogtreecommitdiff
path: root/core/api-exchange.rst
diff options
context:
space:
mode:
Diffstat (limited to 'core/api-exchange.rst')
-rw-r--r--core/api-exchange.rst87
1 files changed, 24 insertions, 63 deletions
diff --git a/core/api-exchange.rst b/core/api-exchange.rst
index 27886c2..a2e3257 100644
--- a/core/api-exchange.rst
+++ b/core/api-exchange.rst
@@ -1046,9 +1046,9 @@ exchange.
| ReserveClosingTransaction
| ReserveRecoupTransaction;
- .. ts:def:: AccountHistoryTransaction
+ .. ts:def:: ReserveHistoryTransaction
- interface AccountHistoryTransaction {
+ interface ReserveHistoryTransaction {
type: "HISTORY";
// Fee agreed to by the reserve owner.
@@ -1562,7 +1562,7 @@ denomination.
| CoinRecoupTransaction
| CoinOldCoinRecoupTransaction
| CoinRecoupRefreshTransaction
- | CoinPursePaymentTransaction;
+ | CoinPurseDepositTransaction;
.. ts:def:: CoinDepositTransaction
@@ -1759,10 +1759,10 @@ denomination.
new_coin_ev: RsaBlindingKeySecret;
}
- .. ts:def:: CoinPursePaymentTransaction
+ .. ts:def:: CoinPurseDepositTransaction
- interface CoinPursePaymentTransaction {
- type: "PURSE_PAYMENT";
+ interface CoinPurseDepositTransaction {
+ type: "PURSE_DEPOSIT";
// The total amount of the coin's value absorbed
// by this transaction.
@@ -2432,12 +2432,11 @@ Wallet-to-wallet transfers
TODO for the spec:
- * add reserve history requests (with fee!)
- to reserve history (changes balance!)
- * specify new database schema at exchange (add SQL to DD13!)
- - something for in-progress kyc vs. completed kyc?
- => add kyc_date to reserves?
- => or have separate KYC table instead of NULLs in reserves!
+ * update DD13 eDB SQL: tables for incoming wads!
+ * do we need some special entry in account/reserve
+ histories for incoming WAD-transfers vs. other merges,
+ or do we re-use the existing 'merge' entry and just
+ generate it from the incoming-wad table?
* update wire transfer API to enable WAD IDs (and while we are
at it, should probably also write extended version to allow
_merchants_ to query for their inbound transfers, so spec
@@ -2445,19 +2444,6 @@ TODO for the spec:
tell exchange for inbound wire transfers that they are
from a partner bank where KYC fees would be waived!
-Discussion:
-
- * when the user POSTs to /kyc for a reserve with a payto URI
- that differs from the URI that was used to establish the
- reserve, do we 409 conflict or accept?
- That seems like an attack vector:
- Say I learn your account pub and wire you money from my
- bank account, thus blocking you from /kyc'ing your account!)
- * when the user POSTs to /kyc for an account with a payto URI
- that differs from the URI that was previously used for a
- /kyc for the same account, do we allow the KYC to proceed
- and update the bank account? Is there an attack vector?
-
.. http:GET:: /purses/$PURSE_PUB
@@ -2551,12 +2537,12 @@ Discussion:
:http:statuscode:`200 OK`:
The operation succeeded, the exchange confirms that all
coins were deposited into the purse.
- The response will include a `PursePaymentSuccess` object.
+ The response will include a `PurseDepositSuccess` object.
:http:statuscode:`202 Accepted`:
The payment was accepted, but insufficient to reach the
specified purse balance. The client should make further
purse deposits before the expiration deadline.
- The response will include a `PursePaymentAccepted` object.
+ The response will include a `PurseDepositAccepted` object.
:http:statuscode:`401 Unauthorized`:
A coin signature is invalid.
This response comes with a standard `ErrorDetail` response.
@@ -2656,9 +2642,9 @@ Discussion:
}
- .. ts:def:: PursePaymentSuccess
+ .. ts:def:: PurseDepositSuccess
- interface PursePaymentSuccess {
+ interface PurseDepositSuccess {
// Total amount paid into the purse.
total_purse_amount: Amount;
@@ -2667,7 +2653,7 @@ Discussion:
total_deposit_fees: Amount;
// EdDSA signature of the exchange affirming the payment,
- // of purpose TALER_SIGNATURE_PURSE_PAYMENT_CONFIRMED
+ // of purpose TALER_SIGNATURE_PURSE_DEPOSIT_CONFIRMED
// Signs over the above and the purse public key and
// the hash of the contract terms.
exchange_sig: EddsaSignature;
@@ -2677,9 +2663,9 @@ Discussion:
}
- .. ts:def:: PursePaymentAccepted
+ .. ts:def:: PurseDepositAccepted
- interface PursePaymentAccepted {
+ interface PurseDepositAccepted {
// Total amount paid so far into the purse, in this
// and previous requests.
@@ -2812,32 +2798,6 @@ Discussion:
// purse with the payment.
contract?: EncryptedContract;
- // Array of payments made to pay for the creation of the
- // purse. Can be empty, say if no payment is needed.
- payments: CreatePurseDeposit[];
-
- }
-
- .. ts:def:: CreatePurseDeposit {
-
- // Public key of the coin being used to pay for creating a purse.
- coin_pub: EddsaPublicKey;
-
- // Amount to be deposited, can be a fraction of the
- // coin's total value.
- contribution: Amount;
-
- // Hash of denomination RSA key with which the coin is signed.
- denom_pub_hash: HashCode;
-
- // Exchange's unblinded RSA signature of the coin.
- ub_sig: RsaSignature;
-
- // Signature of purpose TALER_SIGNATURE_PURSE_PAYMENT.
- // made by the customer with the
- // `coin's private key <coin-priv>`.
- coin_sig: EddsaSignature;
-
}
.. ts:def:: MergeSuccess
@@ -2882,6 +2842,8 @@ Discussion:
(from wire transfers or merges of purses) already have a
sufficient balance to cover the KYC fee. The signature
affirms that the KYC fee can and should be charged to the reserve.
+ The request always updates the payto URI associated with
+ the reserve, even if the KYC process fails or is not completed.
**Request:** The request body must be a `AccountSetupRequest` object.
@@ -2900,11 +2862,6 @@ Discussion:
the required KYC checks to open the account. Afterwards, the
request should be repeated.
The response will be an `AccountKycRedirect` object.
- :http:statuscode:`409 Conflict`:
- The reserve or account was previously associated with a different
- payto URI, and changing the associated bank account is not
- permitted. FIXME: should we allow it? Should we use PATCH for this?
- Or only conflict if this was an account and not a reserve!??
:http:statuscode:`504 Gateway Timeout`:
The exchange did not receive a confirmation from the KYC service
within the specified time period. Used when long-polling for the
@@ -3002,6 +2959,10 @@ wallet-to-wallet payments. Only another exchange should access this endpoint.
// Total transfer amount claimed by the exchange.
total: Amount;
+ // Indicative time by which the wad was given to the
+ // bank to execute the wire transfer.
+ wad_execution_time: Timestamp;
+
// Transfers aggregated in the wad.
items: WadItem[];