diff --git a/ecosystem/sep-0006.md b/ecosystem/sep-0006.md index e4aab6827..12eaa464a 100644 --- a/ecosystem/sep-0006.md +++ b/ecosystem/sep-0006.md @@ -6,8 +6,8 @@ Title: Deposit and Withdrawal API Author: SDF Status: Active (Interactive components are deprecated in favor of SEP-24) Created: 2017-10-30 -Updated: 2024-05-07 -Version 4.1.0 +Updated: 2024-11-05 +Version 4.2.0 ``` ## Simple Summary @@ -407,12 +407,10 @@ Request Parameters: | ----------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `asset_code` | string | The code of the on-chain asset the user wants to get from the Anchor after doing an off-chain deposit. The value passed must match one of the codes listed in the [/info](#info) response's deposit object. | | `account` | `G...` or `M...` string | The stellar or muxed account ID of the user that wants to deposit. This is where the asset token will be sent. Note that the account specified in this request could differ from the account authenticated via SEP-10. | +| `funding_method` | string | A method supported by the Anchor for transferring or settling assets. Must match one of the values specified in the corresponding `/info` response. This field is required to help the Anchor identify the necessary KYC information to collect. | | `memo_type` | string | (optional) Type of memo that the anchor should attach to the Stellar payment transaction, one of `text`, `id` or `hash`. | | `memo` | string | (optional) Value of memo to attach to transaction, for `hash` this should be base64-encoded. Because a memo can be specified in the SEP-10 JWT for [Shared Accounts](#shared-omnibus-or-pooled-accounts), this field as well as `memo_type` can be different than the values included in the SEP-10 JWT. For example, a client application could use the value passed for this parameter as a reference number used to match payments made to `account`. | | `email_address` | string | (optional) Email address of depositor. If desired, an anchor can use this to send email updates to the user about the deposit. | -| `type` | string | (optional) Type of deposit. If the anchor supports multiple deposit methods (e.g. `SEPA` or `SWIFT`), the wallet should specify `type`. This field may be necessary for the anchor to determine which KYC fields to collect. | -| `wallet_name` | string | (**deprecated**,optional) In communications / pages about the deposit, anchor should display the wallet name to the user to explain where funds are going. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | -| `wallet_url` | string | (**deprecated**,optional) Anchor should link to this when notifying the user that the transaction has completed. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | | `lang` | string | (optional) Defaults to `en` if not specified or if the specified language is not supported. Language code specified using [RFC 4646]. `error` fields and other human readable messages in the response should be in this language. | | `on_change_callback` | string | (optional) A URL that the anchor should `POST` a JSON message to when the `status` property of the transaction created as a result of this request changes. The JSON message should be identical to the response format for the [/transaction](#single-historical-transaction) endpoint. The callback needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature). | | `amount` | string | (optional) The amount of the asset the user would like to deposit with the anchor. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | @@ -420,13 +418,16 @@ Request Parameters: | `claimable_balance_supported` | string | (optional) `true` if the client supports receiving deposit transactions as a claimable balance, `false` otherwise. | | `customer_id` | string | (optional) id of an off-chain account (managed by the anchor) associated with this user's Stellar account (identified by the JWT's `sub` field). If the anchor supports [SEP-12], the `customer_id` field should match the [SEP-12] customer's id. `customer_id` should be passed only when the off-chain id is know to the client, but the relationship between this id and the user's Stellar account is not known to the Anchor. | | `location_id` | string | (optional) optional) id of the chosen location to drop off cash | +| `type` | string | (**Deprecated** in favor of `funding_method`) Type of deposit. If the Anchor supports multiple deposit methods (e.g. `SEPA` or `SWIFT`), the wallet should specify `type`. This field may be necessary for the anchor to determine which KYC fields to collect. | +| `wallet_name` | string | (**Deprecated**, optional) In communications / pages about the deposit, anchor should display the wallet name to the user to explain where funds are going. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | +| `wallet_url` | string | (**Deprecated**, optional) Anchor should link to this when notifying the user that the transaction has completed. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | The request parameters also must include the required fields from the `/info` endpoint. Example: ``` -GET https://api.example.com/deposit?asset_code=ETH&account=GACW7NONV43MZIFHCOKCQJAKSJSISSICFVUJ2C6EZIW5773OU3HD64VI +GET https://api.example.com/deposit?asset_code=ETH&account=GACW7NONV43MZIFHCOKCQJAKSJSISSICFVUJ2C6EZIW5773OU3HD64VI&funding_method=WIRE ``` ### Response @@ -711,14 +712,9 @@ Request parameters: | Name | Type | Description | | -------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `asset_code` | string | Code of the on-chain asset the user wants to withdraw. The value passed must match one of the codes listed in the [/info](#info) response's withdraw object. | -| `type` | string | Type of withdrawal. Can be: `crypto`, `bank_account`, `cash`, `mobile`, `bill_payment` or other custom values. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | -| `dest` | string | (**Deprecated**, [see note below](#dest--dest_extra-parameters)) The account that the user wants to withdraw their funds to. This can be a crypto account, a bank account number, IBAN, mobile number, or email address. | -| `dest_extra` | string | (**Deprecated**, [see note below](#dest--dest_extra-parameters), optional) Extra information to specify withdrawal location. For crypto it may be a memo in addition to the `dest` address. It can also be a routing number for a bank, a BIC, or the name of a partner handling the withdrawal. | +| `funding_method` | string | A method supported by the Anchor for transferring or settling assets. Must match one of the values specified in the corresponding `/info` response. This field is required to help the Anchor identify the necessary KYC information to collect. | | `account` | `G...` or `M...` string | (optional) The Stellar or muxed account the client will use as the source of the withdrawal payment to the anchor. If SEP-10 authentication is not used, the anchor can use `account` to look up the user's KYC information. Note that the account specified in this request could differ from the account authenticated via SEP-10. | | `memo` | string | (optional) This field should only be used if SEP-10 authentication is not. It was originally intended to distinguish users of the same Stellar account. However if SEP-10 is supported, the anchor should use the `sub` value included in the decoded SEP-10 JWT instead. See the [Shared Account Authentication](#shared-omnibus-or-pooled-accounts) section for more information. | -| `memo_type` | string | (**Deprecated**, optional) Type of `memo`. One of `text`, `id` or `hash`. Deprecated because memos used to identify users of the same Stellar account should always be of type of `id`. | -| `wallet_name` | string | (**deprecated**,optional) In communications / pages about the withdrawal, anchor should display the wallet name to the user to explain where funds are coming from. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | -| `wallet_url` | string | (**deprecated**,optional) Anchor can show this to the user when referencing the wallet involved in the withdrawal (ex. in the anchor's transaction history). However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | | `lang` | string | (optional) Defaults to `en` if not specified or if the specified language is not supported. Language code specified using [RFC 4646]. `error` fields and other human readable messages in the response should be in this language. | | `on_change_callback` | string | (optional) A URL that the anchor should `POST` a JSON message to when the `status` property of the transaction created as a result of this request changes. The JSON message should be identical to the response format for the [/transaction](#single-historical-transaction) endpoint. The callback needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature). | | `amount` | string | (optional) The amount of the asset the user would like to withdraw. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | @@ -727,6 +723,12 @@ Request parameters: | `refund_memo_type` | string | (optional) The type of the `refund_memo`. Can be `id`, `text`, or `hash`. See the [memos](https://developers.stellar.org/docs/encyclopedia/memos) documentation for more information. If specified, `refund_memo` must also be specified. | | `customer_id` | string | (optional) id of an off-chain account (managed by the anchor) associated with this user's Stellar account (identified by the JWT's `sub` field). If the anchor supports [SEP-12], the `customer_id` field should match the [SEP-12] customer's id. `customer_id` should be passed only when the off-chain id is know to the client, but the relationship between this id and the user's Stellar account is not known to the Anchor. | | `location_id` | string | (optional) id of the chosen location to pick up cash | +| `type` | string | (**Deprecated** in favor of `funding_method`) Type of withdrawal. Can be: `crypto`, `bank_account`, `cash`, `mobile`, `bill_payment` or other custom values. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | +| `dest` | string | (**Deprecated**, [see note below](#dest--dest_extra-parameters)) The account that the user wants to withdraw their funds to. This can be a crypto account, a bank account number, IBAN, mobile number, or email address. | +| `dest_extra` | string | (**Deprecated**, [see note below](#dest--dest_extra-parameters), optional) Extra information to specify withdrawal location. For crypto it may be a memo in addition to the `dest` address. It can also be a routing number for a bank, a BIC, or the name of a partner handling the withdrawal. | +| `memo_type` | string | (**Deprecated**, optional) Type of `memo`. One of `text`, `id` or `hash`. Deprecated because memos used to identify users of the same Stellar account should always be of type of `id`. | +| `wallet_name` | string | (**Deprecated**, optional) In communications / pages about the withdrawal, anchor should display the wallet name to the user to explain where funds are coming from. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | +| `wallet_url` | string | (**Deprecated**, optional) Anchor can show this to the user when referencing the wallet involved in the withdrawal (ex. in the anchor's transaction history). However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | The request parameters also must include the required fields from the `/info` endpoint. @@ -742,7 +744,7 @@ include `dest` and/or `dest_extra` in the `/info` response. Example: ``` -GET https://api.example.com/withdraw?asset_code=ETH&dest=0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe +GET https://api.example.com/withdraw?asset_code=ETH&dest=0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe&funding_method=WIRE ``` ### Response @@ -818,30 +820,31 @@ Request Parameters: | ----------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `destination_asset` | string | The code of the on-chain asset the user wants to get from the Anchor after doing an off-chain deposit. The value passed must match one of the codes listed in the [/info](#info) response's `deposit-exchange` object. | | `source_asset` | string | The off-chain asset the Anchor will receive from the user. The value must match one of the `asset` values included in a [`SEP-38 GET /prices?buy_asset=stellar::`](sep-0038.md#get-prices) response using [SEP-38 Asset Identification Format](sep-0038.md#asset-identification-format). | -| `quote_id` | string | (optional) The `id` returned from a `SEP-38 POST /quote` response. If this parameter is provided and the user delivers the deposit funds to the Anchor before the quote expiration, the Anchor should respect the conversion rate agreed in that quote. If the values of `destination_asset`, `source_asset` and `amount` conflict with the ones used to create the [SEP-38] quote, this request should be rejected with a `400`. | | `amount` | string | The amount of the `source_asset` the user would like to deposit to the anchor's off-chain account. This field may be necessary for the anchor to determine what KYC information is necessary to collect. Should be equals to `quote.sell_amount` if a `quote_id` was used. | +| `funding_method` | string | A method supported by the Anchor for transferring or settling assets. Must match one of the values specified in the corresponding `/info` response. This field is required to help the Anchor identify the necessary KYC information to collect. | | `account` | `G...` or `M...` string | The stellar or muxed account ID of the user that wants to deposit. This is where the asset token will be sent. Note that the account specified in this request could differ from the account authenticated via SEP-10. | +| `quote_id` | string | (optional) The `id` returned from a `SEP-38 POST /quote` response. If this parameter is provided and the user delivers the deposit funds to the Anchor before the quote expiration, the Anchor should respect the conversion rate agreed in that quote. If the values of `destination_asset`, `source_asset`, `amount` and `funding_method` conflict with the ones used to create the [SEP-38] quote, this request should be rejected with a `400`. | | `memo_type` | string | (optional) Type of memo that the anchor should attach to the Stellar payment transaction, one of `text`, `id` or `hash`. | | `memo` | string | (optional) Value of memo to attach to transaction, for `hash` this should be base64-encoded. Because a memo can be specified in the SEP-10 JWT for [Shared Accounts](#shared-omnibus-or-pooled-accounts), this field as well as `memo_type` can be different than the values included in the SEP-10 JWT. For example, a client application could use the value passed for this parameter as a reference number used to match payments made to `account`. | | `email_address` | string | (optional) Email address of depositor. If desired, an anchor can use this to send email updates to the user about the deposit. | -| `type` | string | (optional) Type of deposit. If the anchor supports multiple deposit methods (e.g. `SEPA` or `SWIFT`), the wallet should specify `type`. This field may be necessary for the anchor to determine which KYC fields to collect. | -| `wallet_name` | string | (**deprecated**,optional) In communications / pages about the deposit, anchor should display the wallet name to the user to explain where funds are going. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | -| `wallet_url` | string | (**deprecated**,optional) Anchor should link to this when notifying the user that the transaction has completed. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | | `lang` | string | (optional) Defaults to `en` if not specified or if the specified language is not supported. Language code specified using [RFC 4646]. `error` fields and other human readable messages in the response should be in this language. | | `on_change_callback` | string | (optional) A URL that the anchor should `POST` a JSON message to when the `status` property of the transaction created as a result of this request changes. The JSON message should be identical to the response format for the [/transaction](#single-historical-transaction) endpoint. The callback needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature). | | `country_code` | string | (optional) The [ISO 3166-1 alpha-3](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3) code of the user's current address. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | | `claimable_balance_supported` | string | (optional) `true` if the client supports receiving deposit transactions as a claimable balance, `false` otherwise. | | `customer_id` | string | (optional) id of an off-chain account (managed by the anchor) associated with this user's Stellar account (identified by the JWT's `sub` field). If the anchor supports [SEP-12], the `customer_id` field should match the [SEP-12] customer's id. `customer_id` should be passed only when the off-chain id is know to the client, but the relationship between this id and the user's Stellar account is not known to the Anchor. | | `location_id` | string | (optional) optional) id of the chosen location to drop off cash | +| `type` | string | (**Deprecated** in favor of `funding_method`) Type of deposit. If the Anchor supports multiple deposit methods (e.g. `SEPA` or `SWIFT`), the wallet should specify `type`. This field may be necessary for the anchor to determine which KYC fields to collect. | +| `wallet_name` | string | (**Deprecated**, optional) In communications / pages about the deposit, anchor should display the wallet name to the user to explain where funds are going. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | +| `wallet_url` | string | (**Deprecated**, optional) Anchor should link to this when notifying the user that the transaction has completed. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | Examples: ```curl -GET https://api.example.com/deposit-exchange?destination_asset=USDC&source_asset=iso4217:BRL&account=GACW7NONV43MZIFHCOKCQJAKSJSISSICFVUJ2C6EZIW5773OU3HD64VI +GET https://api.example.com/deposit-exchange?destination_asset=USDC&source_asset=iso4217:BRL&account=GACW7NONV43MZIFHCOKCQJAKSJSISSICFVUJ2C6EZIW5773OU3HD64VI&funding_method=WIRE ``` ```curl -GET https://api.example.com/deposit-exchange?destination_asset=USDC&source_asset=iso4217:BRL&account=GACW7NONV43MZIFHCOKCQJAKSJSISSICFVUJ2C6EZIW5773OU3HD64VI"e_id=asdf1234 +GET https://api.example.com/deposit-exchange?destination_asset=USDC&source_asset=iso4217:BRL&account=GACW7NONV43MZIFHCOKCQJAKSJSISSICFVUJ2C6EZIW5773OU3HD64VI&funding_method=WIRE"e_id=asdf1234 ``` ### Response @@ -867,36 +870,37 @@ GET TRANSFER_SERVER/withdraw-exchange Request parameters: -| Name | Type | Description | -| -------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `source_asset` | string | Code of the on-chain asset the user wants to withdraw. The value passed must match one of the codes listed in the [/info](#info) response's `withdraw-exchange` object. | -| `destination_asset` | string | The off-chain asset the Anchor will deliver to the user's account. The value must match one of the `asset` values included in a [`SEP-38 GET /prices?sell_asset=stellar::`](sep-0038.md#get-prices) response using [SEP-38 Asset Identification Format](sep-0038.md#asset-identification-format). | -| `quote_id` | string | (optional) The `id` returned from a `SEP-38 POST /quote` response. If this parameter is provided and the Stellar transaction used to send the asset to the Anchor has a [`created_at`](https://developers.stellar.org/api/resources/transactions/object/) timestamp earlier than the quote's `expires_at` attribute, the Anchor should respect the conversion rate agreed in that quote. If the values of `destination_asset`, `source_asset` and `amount` conflict with the ones used to create the [SEP-38] quote, this request should be rejected with a `400`. | -| `amount` | string | The amount of the on-chain asset (`source_asset`) the user would like to send to the anchor's Stellar account. This field may be necessary for the anchor to determine what KYC information is necessary to collect. Should be equals to `quote.sell_amount` if a `quote_id` was used. | -| `type` | string | Type of withdrawal. Can be: `crypto`, `bank_account`, `cash`, `mobile`, `bill_payment` or other custom values. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | -| `dest` | string | (**Deprecated**, [see note](#dest--dest_extra-parameters)) The account that the user wants to withdraw their funds to. This can be a crypto account, a bank account number, IBAN, mobile number, or email address. | -| `dest_extra` | string | (**Deprecated**, [see note](#dest--dest_extra-parameters), optional) Extra information to specify withdrawal location. For crypto it may be a memo in addition to the `dest` address. It can also be a routing number for a bank, a BIC, or the name of a partner handling the withdrawal. | -| `account` | `G...` or `M...` string | (optional) The Stellar or muxed account of the user that wants to do the withdrawal. This is only needed if the anchor requires KYC information for withdrawal and SEP-10 authentication is not used. Instead, the anchor can use `account` to look up the user's KYC information. Note that the account specified in this request could differ from the account authenticated via SEP-10. | -| `memo` | string | (optional) This field should only be used if SEP-10 authentication is not. It was originally intended to distinguish users of the same Stellar account. However if SEP-10 is supported, the anchor should use the `sub` value included in the decoded SEP-10 JWT instead. See the [Shared Account Authentication](#shared-omnibus-or-pooled-accounts) section for more information. | -| `memo_type` | string | (**Deprecated**, optional) Type of `memo`. One of `text`, `id` or `hash`. Deprecated because memos used to identify users of the same Stellar account should always be of type of `id`. | -| `wallet_name` | string | (**deprecated**,optional) In communications / pages about the withdrawal, anchor should display the wallet name to the user to explain where funds are coming from. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | -| `wallet_url` | string | (**deprecated**,optional) Anchor can show this to the user when referencing the wallet involved in the withdrawal (ex. in the anchor's transaction history). However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | -| `lang` | string | (optional) Defaults to `en` if not specified or if the specified language is not supported. Language code specified using [RFC 4646]. `error` fields and other human readable messages in the response should be in this language. | -| `on_change_callback` | string | (optional) A URL that the anchor should `POST` a JSON message to when the `status` property of the transaction created as a result of this request changes. The JSON message should be identical to the response format for the [/transaction](#single-historical-transaction) endpoint. The callback needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature). | -| `country_code` | string | (optional) The [ISO 3166-1 alpha-3](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3) code of the user's current address. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | -| `refund_memo` | string | (optional) The memo the anchor must use when sending refund payments back to the user. If not specified, the anchor should use the same memo used by the user to send the original payment. If specified, `refund_memo_type` must also be specified. | -| `refund_memo_type` | string | (optional) The type of the `refund_memo`. Can be `id`, `text`, or `hash`. See the [memos](https://developers.stellar.org/docs/encyclopedia/memos) documentation for more information. If specified, `refund_memo` must also be specified. | -| `customer_id` | string | (optional) id of an off-chain account (managed by the anchor) associated with this user's Stellar account (identified by the JWT's `sub` field). If the anchor supports [SEP-12], the `customer_id` field should match the [SEP-12] customer's id. `customer_id` should be passed only when the off-chain id is know to the client, but the relationship between this id and the user's Stellar account is not known to the Anchor. | -| `location_id` | string | (optional) id of the chosen location to pick up cash | +| Name | Type | Description | +| -------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `source_asset` | string | Code of the on-chain asset the user wants to withdraw. The value passed must match one of the codes listed in the [/info](#info) response's `withdraw-exchange` object. | +| `destination_asset` | string | The off-chain asset the Anchor will deliver to the user's account. The value must match one of the `asset` values included in a [`SEP-38 GET /prices?sell_asset=stellar::`](sep-0038.md#get-prices) response using [SEP-38 Asset Identification Format](sep-0038.md#asset-identification-format). | +| `amount` | string | The amount of the on-chain asset (`source_asset`) the user would like to send to the anchor's Stellar account. This field may be necessary for the anchor to determine what KYC information is necessary to collect. Should be equals to `quote.sell_amount` if a `quote_id` was used. | +| `funding_method` | string | A method supported by the Anchor for transferring or settling assets. Must match one of the values specified in the corresponding `/info` response. This field is required to help the Anchor identify the necessary KYC information to collect. | +| `quote_id` | string | (optional) The `id` returned from a `SEP-38 POST /quote` response. If this parameter is provided and the Stellar transaction used to send the asset to the Anchor has a [`created_at`](https://developers.stellar.org/api/resources/transactions/object/) timestamp earlier than the quote's `expires_at` attribute, the Anchor should respect the conversion rate agreed in that quote. If the values of `destination_asset`, `source_asset`, `amount` and `funding_method` conflict with the ones used to create the [SEP-38] quote, this request should be rejected with a `400`. | +| `account` | `G...` or `M...` string | (optional) The Stellar or muxed account of the user that wants to do the withdrawal. This is only needed if the anchor requires KYC information for withdrawal and SEP-10 authentication is not used. Instead, the anchor can use `account` to look up the user's KYC information. Note that the account specified in this request could differ from the account authenticated via SEP-10. | +| `memo` | string | (optional) This field should only be used if SEP-10 authentication is not. It was originally intended to distinguish users of the same Stellar account. However if SEP-10 is supported, the anchor should use the `sub` value included in the decoded SEP-10 JWT instead. See the [Shared Account Authentication](#shared-omnibus-or-pooled-accounts) section for more information. | +| `lang` | string | (optional) Defaults to `en` if not specified or if the specified language is not supported. Language code specified using [RFC 4646]. `error` fields and other human readable messages in the response should be in this language. | +| `on_change_callback` | string | (optional) A URL that the anchor should `POST` a JSON message to when the `status` property of the transaction created as a result of this request changes. The JSON message should be identical to the response format for the [/transaction](#single-historical-transaction) endpoint. The callback needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature). | +| `country_code` | string | (optional) The [ISO 3166-1 alpha-3](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3) code of the user's current address. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | +| `refund_memo` | string | (optional) The memo the anchor must use when sending refund payments back to the user. If not specified, the anchor should use the same memo used by the user to send the original payment. If specified, `refund_memo_type` must also be specified. | +| `refund_memo_type` | string | (optional) The type of the `refund_memo`. Can be `id`, `text`, or `hash`. See the [memos](https://developers.stellar.org/docs/encyclopedia/memos) documentation for more information. If specified, `refund_memo` must also be specified. | +| `customer_id` | string | (optional) id of an off-chain account (managed by the anchor) associated with this user's Stellar account (identified by the JWT's `sub` field). If the anchor supports [SEP-12], the `customer_id` field should match the [SEP-12] customer's id. `customer_id` should be passed only when the off-chain id is know to the client, but the relationship between this id and the user's Stellar account is not known to the Anchor. | +| `location_id` | string | (optional) id of the chosen location to pick up cash | +| `type` | string | (**Deprecated** in favor of `funding_method`) Type of withdrawal. Can be: `crypto`, `bank_account`, `cash`, `mobile`, `bill_payment` or other custom values. This field may be necessary for the anchor to determine what KYC information is necessary to collect. | +| `dest` | string | (**Deprecated**, [see note](#dest--dest_extra-parameters)) The account that the user wants to withdraw their funds to. This can be a crypto account, a bank account number, IBAN, mobile number, or email address. | +| `dest_extra` | string | (**Deprecated**, [see note](#dest--dest_extra-parameters), optional) Extra information to specify withdrawal location. For crypto it may be a memo in addition to the `dest` address. It can also be a routing number for a bank, a BIC, or the name of a partner handling the withdrawal. | +| `memo_type` | string | (**Deprecated**, optional) Type of `memo`. One of `text`, `id` or `hash`. Deprecated because memos used to identify users of the same Stellar account should always be of type of `id`. | +| `wallet_name` | string | (**Deprecated**, optional) In communications / pages about the withdrawal, anchor should display the wallet name to the user to explain where funds are coming from. However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | +| `wallet_url` | string | (**Deprecated**, optional) Anchor can show this to the user when referencing the wallet involved in the withdrawal (ex. in the anchor's transaction history). However, anchors should use client_domain (for non-custodial) and `sub` value of JWT (for custodial) to determine wallet information. | Example: ```curl -GET https://api.example.com/withdraw-exchange?source_asset=USDC&destination_asset=iso4217:NGN&dest=0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe +GET https://api.example.com/withdraw-exchange?source_asset=USDC&destination_asset=iso4217:NGN&dest=0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe&funding_method=WIRE ``` ```curl -GET https://api.example.com/withdraw-exchange?source_asset=USDC&destination_asset=iso4217:NGN&dest=0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe"e_id=asdf1234 +GET https://api.example.com/withdraw-exchange?source_asset=USDC&destination_asset=iso4217:NGN&dest=0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe&funding_method=WIRE"e_id=asdf1234 ``` ### Response @@ -1078,23 +1082,7 @@ The response should be a JSON object like: "authentication_required": true, "min_amount": 0.1, "max_amount": 1000, - "fields": { - "email_address" : { - "description": "your email address for transaction status updates", - "optional": true - }, - "amount" : { - "description": "amount in USD that you plan to deposit" - }, - "country_code": { - "description": "The ISO 3166-1 alpha-3 code of the user's current address", - "choices": ["USA", "PRI"] - }, - "type" : { - "description": "type of deposit to make", - "choices": ["SEPA", "SWIFT", "cash"] - } - } + "funding_methods": ["SEPA", "SWIFT", "cash"] }, "ETH": { "enabled": true, @@ -1104,22 +1092,7 @@ The response should be a JSON object like: "deposit-exchange": { "USD": { "authentication_required": true, - "fields": { - "email_address" : { - "description": "your email address for transaction status updates", - "optional": true - }, - "amount" : { - "description": "amount in USD that you plan to deposit" - }, - "country_code": { - "description": "The ISO 3166-1 alpha-3 code of the user's current address", - "choices": ["USA", "PRI"] - }, - "type" : { - "description": "type of deposit to make", - "choices": ["SEPA", "SWIFT", "cash"] - } + "funding_methods": ["SEPA", "SWIFT", "cash"] } } }, @@ -1129,28 +1102,7 @@ The response should be a JSON object like: "authentication_required": true, "min_amount": 0.1, "max_amount": 1000, - "types": { - "bank_account": { - "fields": { - "dest": {"description": "your bank account number" }, - "dest_extra": { "description": "your routing number" }, - "bank_branch": { "description": "address of your bank branch" }, - "phone_number": { "description": "your phone number in case there's an issue" }, - "country_code": { - "description": "The ISO 3166-1 alpha-3 code of the user's current address", - "choices": ["USA", "PRI"] - } - } - }, - "cash": { - "fields": { - "dest": { - "description": "your email address. Your cashout PIN will be sent here. If not provided, your account's default email will be used", - "optional": true - } - } - } - } + "funding_methods": ["bank_account", "cash", "crypto", "mobile", "bill_payment"] }, "ETH": { "enabled": false @@ -1161,28 +1113,7 @@ The response should be a JSON object like: "authentication_required": true, "min_amount": 0.1, "max_amount": 1000, - "types": { - "bank_account": { - "fields": { - "dest": {"description": "your bank account number" }, - "dest_extra": { "description": "your routing number" }, - "bank_branch": { "description": "address of your bank branch" }, - "phone_number": { "description": "your phone number in case there's an issue" }, - "country_code": { - "description": "The ISO 3166-1 alpha-3 code of the user's current address", - "choices": ["USA", "PRI"] - } - } - }, - "cash": { - "fields": { - "dest": { - "description": "your email address. Your cashout PIN will be sent here. If not provided, your account's default email will be used", - "optional": true - } - } - } - } + "funding_methods": ["bank_account", "cash", "crypto", "mobile", "bill_payment"] } }, "fee": { @@ -1213,6 +1144,10 @@ All assets listed in a `deposit` and `deposit-exchange` can contain these attrib - `enabled`: `true` if SEP-6 deposit for this asset is supported - `authentication_required`: Optional. `true` if client must be [authenticated](#authentication) before accessing the deposit endpoint for this asset. `false` if not specified. +- `funding_methods`: A list of methods supported by the Anchor for transferring or settling assets. For deposits, this + specifies the methods available to transfer funds from the client’s account to the anchor, typically listing options + such as `WIRE` or `ACH` for fiat settlements. If quote is in use, the `buy_delivery_method` or the + `sell_delivery_method` should match the `funding_methods` options here. - `fields` (**Deprecated**, Accepting personally identifiable information through request parameters is a security risk due to web server request logging. KYC information should be supplied to the Anchor via SEP-12) `fields` object is explained below. @@ -1233,13 +1168,20 @@ All assets listed in a `withdraw` and `withdraw-exchange` can contain these attr - `enabled`: `true` if SEP-6 withdrawal for this asset is supported - `authentication_required`: Optional. `true` if client must be [authenticated](#authentication) before accessing the withdraw endpoint for this asset. `false` if not specified. -- `types`: a field with each type of withdrawal supported for that asset as a key. Each type can specify a `fields` - object as below explaining what fields are needed and what they do. Anchors are encouraged to use - [SEP-9 financial account fields](sep-0009.md#financial-account-fields), but can also define custom fields if - necessary. If a `fields` object is not specified, the wallet should assume that no extra fields are needed for that - type of withdrawal. In the case that the Anchor requires additional fields for a withdrawal, it should set the - transaction status to `pending_customer_info_update`. The wallet can query the `/transaction` endpoint to get the - fields needed to complete the transaction in `required_customer_info_updates` and then use +- `funding_methods`: A list of methods supported by the Anchor for transferring or settling assets. For withdrawals, + this specifies the methods available for the anchor to send funds to the client’s account, such as ["SEPA", "SWIFT", + "cash"]. If quote is in use, the `buy_delivery_method` or the `sell_delivery_method` should match the + `funding_methods` options here. In the case that the Anchor requires additional fields for a withdrawal, Anchor should + set the transaction status to `pending_customer_info_update`. The wallet can query the `/transaction` endpoint to get + the fields needed to complete the transaction in `required_customer_info_updates` and then use + [SEP-12](sep-0012.md#customer-put) to collect the information from the user. +- `types`: (**Deprecated** in favor of `funding_method`) A field with each type of withdrawal supported for that asset + as a key. Each type can specify a `fields` object as below explaining what fields are needed and what they do. Anchors + are encouraged to use [SEP-9 financial account fields](sep-0009.md#financial-account-fields), but can also define + custom fields if necessary. If a `fields` object is not specified, the wallet should assume that no extra fields are + needed for that type of withdrawal. In the case that the Anchor requires additional fields for a withdrawal, it should + set the transaction status to `pending_customer_info_update`. The wallet can query the `/transaction` endpoint to get + the fields needed to complete the transaction in `required_customer_info_updates` and then use [SEP-12](sep-0012.md#customer-put) to collect the information from the user. Withdrawal assets listed in the `withdraw` object can also contain the attributes: @@ -1253,7 +1195,7 @@ Withdrawal assets listed in the `withdraw` object can also contain the attribute #### Fields -The `fields` object allows an anchor to describe fields that are passed into `/deposit`, `/withdraw`, +(**Deprecated**) The `fields` object allows an anchor to describe fields that are passed into `/deposit`, `/withdraw`, `/deposit-exchange` and/or `/withdraw-exchange`. It can explain standard fields like `dest` and `dest_extra` for withdrawals, as well as extra fields that could be needed for all deposit and withdrawal endpoints such as an email address or bank name. If a field is part of the KYC/AML flow handled by SEP-12 or the field is handled by the Anchor's @@ -1789,6 +1731,8 @@ object containing an error message. ## Changelog +- `v4.2.0` Deprecate `fields` in favor of `funding_method` field + ([#1567](https://github.com/stellar/stellar-protocol/pull/1567/)) - `v4.1.0` Add `user_action_required_by` field to transaction responses and add new `on_hold` status ([#1484](https://github.com/stellar/stellar-protocol/pull/1484/)) - `v4.0.0`: Update flow to delegate getting KYC fields to SEP-12 diff --git a/ecosystem/sep-0031.md b/ecosystem/sep-0031.md index adaee0045..39dddf78b 100644 --- a/ecosystem/sep-0031.md +++ b/ecosystem/sep-0031.md @@ -6,8 +6,8 @@ Title: Cross-Border Payments API Author: SDF Status: Active Created: 2020-04-07 -Updated: 2024-07-23 -Version 3.0.0 +Updated: 2024-11-05 +Version 3.1.0 ``` ## Simple Summary @@ -249,7 +249,7 @@ earlier than the quote's expiration. 1. If `error`, the Receiving Anchor should be contacted to resolve the situation. 1. If `pending_transaction_info_update`, the `transaction.fields` values collected from the Sending Client were invalid and must be corrected by the Sending Client. See the - [Pending Transaction Info Update](#pending-transaction-info-update) section for more information. + [Pending Transaction Info Update](#pending-transaction-info-update-deprecated) section for more information. 1. If `pending_customer_info_update`, the SEP-9 KYC values collected were invalid and must be corrected by the Sending Client. See the [Pending Customer Info Update](#pending-customer-info-update) section for more information. 1. After providing the Receiving Anchor with updated values, the status should ultimately change to `completed`. @@ -326,31 +326,7 @@ The response should be a JSON object like: "fee_percent": 1, "min_amount": 0.1, "max_amount": 1000, - "sep12": { - "sender": { - "types": { - "sep31-sender": { - "description": "U.S. citizens limited to sending payments of less than $10,000 in value" - }, - "sep31-large-sender": { - "description": "U.S. citizens that do not have sending limits" - }, - "sep31-foreign-sender": { - "description": "non-U.S. citizens sending payments of less than $10,000 in value" - } - } - }, - "receiver": { - "types": { - "sep31-receiver": { - "description": "U.S. citizens receiving USD" - }, - "sep31-foreign-receiver": { - "description": "non-U.S. citizens receiving USD" - } - } - } - } + "funding_methods": ["SEPA", "SWIFT"] } } } @@ -369,16 +345,17 @@ the corresponding off-chain asset, after fees have been applied. | Name | Type | Description | | --------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `sep12` | object | An object containing `sender` and `receiver` keys. | +| `funding_methods` | array | A list of methods supported by the Anchor for transferring or settling assets. For SEP-31, this specifies the methods the receiving anchor uses to deliver the asset to the receiving client. | | `min_amount` | number | (optional) Minimum amount. No limit if not specified. | | `max_amount` | number | (optional) Maximum amount. No limit if not specified. | | `fee_fixed` | number | (optional) A fixed fee in units of the Stellar asset. Leave blank if there is no fee or fee calculation cannot be modeled using a fixed and percentage fee. | | `fee_percent` | number | (optional) A percentage fee in percentage points. Leave blank if there is no fee or fee calculation cannot be modeled using a fixed and percentage fee. | -| `sender_sep12_type` | string | (**deprecated**, optional) The value of the `type` parameter the Sending Anchor should use for a `SEP-12 GET /customer` request. This field can be omitted if no KYC is necessary. Use a value from `sep12.sender.types` instead if any are present. | -| `receiver_sep12_type` | string | (**deprecated**, optional) The value of the `type` parameter the Sending Anchor should use for a `SEP-12 GET /customer` request. This field can be omitted if no KYC is necessary. Use a values from `sep12.receiver.types` instead if any are present. | -| `fields` | object | (**deprecated**, optional) An object containing the per-transaction parameters required in `POST /transactions` requests. Pass [SEP-9] fields via [SEP-12 PUT /customer](sep-0012.md#customer-put) instead. | | `quotes_supported` | boolean | (optional) If true, the Receiving Anchor can deliver the off-chain assets listed in the [`SEP-38 GET /prices`](sep-0038.md#get-prices) response in exchange for receiving the Stellar asset. | | `quotes_required` | boolean | (optional) If true, the Receiving Anchor can only deliver an off-chain asset listed in the [`SEP-38 GET /prices`](sep-0038.md#get-prices) response in exchange for receiving the Stellar asset. | +| `sep12` | object | (**Deprecated**, optional) An object containing `sender` and `receiver` keys. | +| `sender_sep12_type` | string | (**Deprecated**, optional) The value of the `type` parameter the Sending Anchor should use for a `SEP-12 GET /customer` request. This field can be omitted if no KYC is necessary. Use a value from `sep12.sender.types` instead if any are present. | +| `receiver_sep12_type` | string | (**Deprecated**, optional) The value of the `type` parameter the Sending Anchor should use for a `SEP-12 GET /customer` request. This field can be omitted if no KYC is necessary. Use a values from `sep12.receiver.types` instead if any are present. | +| `fields` | object | (**Deprecated**, optional) An object containing the per-transaction parameters required in `POST /transactions` requests. Pass [SEP-9] fields via [SEP-12 PUT /customer](sep-0012.md#customer-put) instead. | #### `sep12` Object Schema @@ -477,24 +454,26 @@ Content-Type: application/json "quote_id": "2bc5b322-5117-413f-869f-e7ca494cb1a4", "sender_id": "d2bd1412-e2f6-4047-ad70-a1a2f133b25c", "receiver_id": "137938d4-43a7-4252-a452-842adcee474c" + "funding_method": "SWIFT" } ``` ##### Request Parameters -| Name | Type | Description | -| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `amount` | number | Amount of the Stellar asset sent to the Receiving Anchor. | -| `asset_code` | string | Code of the asset the Sending Anchor intends to send. This must match one of the entries listed in the receiving anchor's `GET /info` endpoint. | -| `asset_issuer` | string | (optional) The issuer of the Stellar asset the Sending Anchor intends to send. If not specified, the asset sent must be issued by the Receiving Anchor. | -| `destination_asset` | string | (optional) The off-chain asset the Receiving Anchor will deliver to the Receiving Client. The value must match one of the `asset` values included in a [`SEP-38 GET /prices?sell_asset=stellar::`](sep-0038.md#get-prices) response using [SEP-38 Asset Identification Format](sep-0038.md#asset-identification-format). If neither this field nor `quote_id` are set, it's assumed that [Sending Anchor Asset Conversions](#sending-anchor-asset-conversion) was used. | -| `quote_id` | string | (optional) The `id` returned from a `SEP-38 POST /quote` response. If this attribute is specified, the values for the fields defined above must match the values associated with the quote. | -| `sender_id` | `string` | (optional) The ID included in the [SEP-12 PUT /customer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-put) response for the Sending Client. Required if the Receiving Anchor requires SEP-12 KYC on the Sending Client. | -| `receiver_id` | `string` | (optional) The ID included in the [SEP-12 PUT /customer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-put) response for the Receiving Client. Required if the Receiving Anchor requires SEP-12 KYC on the Receiving Client. | -| `fields` | object | (**deprecated**, optional) An object containing the values requested by the Receiving Anchor in the `GET /info` endpoint. Pass [SEP-9] fields via [SEP-12 PUT /customer](sep-0012.md#customer-put) instead. | -| `lang` | string | (optional) Defaults to `en`. Language code specified using [ISO 639-1](https://en.wikipedia.org/wiki/ISO_639-1). Any human-readable error codes or field descriptions will be returned in this language. | -| `refund_memo` | (optional) The memo the Receiving Anchor must use when sending refund payments back to the Sending Anchor. If not specified, the Receiving Anchor should use the same memo the Sending Anchor used to send the original payment. If specified, `refund_memo_type` must also be specified. | -| `refund_memo_type` | (optional) The type of the `refund_memo`. Can be `id`, `text`, or `hash`. See the [memos](https://developers.stellar.org/docs/encyclopedia/memos) documentation for more information. If specified, `refund_memo` must also be specified. | +| Name | Type | Description | +| ------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `amount` | number | Amount of the Stellar asset sent to the Receiving Anchor. | +| `asset_code` | string | Code of the asset the Sending Anchor intends to send. This must match one of the entries listed in the receiving anchor's `GET /info` endpoint. | +| `funding_method` | string | A method supported by the Receiving Anchor for transferring or settling assets. Must match one of the values specified in the corresponding `/info` response. This field is required to help the Anchor identify the necessary KYC information to collect. | +| `asset_issuer` | string | (optional) The issuer of the Stellar asset the Sending Anchor intends to send. If not specified, the asset sent must be issued by the Receiving Anchor. | +| `destination_asset` | string | (optional) The off-chain asset the Receiving Anchor will deliver to the Receiving Client. The value must match one of the `asset` values included in a [`SEP-38 GET /prices?sell_asset=stellar::`](sep-0038.md#get-prices) response using [SEP-38 Asset Identification Format](sep-0038.md#asset-identification-format). If neither this field nor `quote_id` are set, it's assumed that [Sending Anchor Asset Conversions](#sending-anchor-asset-conversion) was used. | +| `quote_id` | string | (optional) The `id` returned from a `SEP-38 POST /quote` response. If this attribute is specified, the values for the fields defined above must match the values associated with the quote. | +| `sender_id` | `string` | (optional) The ID included in the [SEP-12 PUT /customer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-put) response for the Sending Client. Required if the Receiving Anchor requires SEP-12 KYC on the Sending Client. | +| `receiver_id` | `string` | (optional) The ID included in the [SEP-12 PUT /customer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-put) response for the Receiving Client. Required if the Receiving Anchor requires SEP-12 KYC on the Receiving Client. | +| `lang` | string | (optional) Defaults to `en`. Language code specified using [ISO 639-1](https://en.wikipedia.org/wiki/ISO_639-1). Any human-readable error codes or field descriptions will be returned in this language. | +| `refund_memo` | string | (optional) The memo the Receiving Anchor must use when sending refund payments back to the Sending Anchor. If not specified, the Receiving Anchor should use the same memo the Sending Anchor used to send the original payment. If specified, `refund_memo_type` must also be specified. | +| `refund_memo_type` | string | (optional) The type of the `refund_memo`. Can be `id`, `text`, or `hash`. See the [memos](https://developers.stellar.org/docs/encyclopedia/memos) documentation for more information. If specified, `refund_memo` must also be specified. | +| `fields` | object | (**Deprecated**, optional) An object containing the values requested by the Receiving Anchor in the `GET /info` endpoint. Pass [SEP-9] fields via [SEP-12 PUT /customer](sep-0012.md#customer-put) instead. | #### Responses @@ -624,7 +603,7 @@ On success the response should include a `200 OK` HTTP status code and the follo - `pending_customer_info_update` -- certain pieces of information need to be updated by the Sending Anchor. See the [Pending Customer Info Update](#pending-customer-info-update) section for more information. - `pending_transaction_info_update` -- certain pieces of information need to be updated by the Sending Anchor. See the - [Pending Transaction Info Update](#pending-transaction-info-update) section for more information. + [Pending Transaction Info Update](#pending-transaction-info-update-deprecated) section for more information. - `pending_receiver` -- payment is being processed by the Receiving Anchor. - `pending_external` -- payment has been submitted to external network, but is not yet confirmed. - `completed` -- funds have been delivered to the Receiving Client. @@ -1040,7 +1019,9 @@ unexpected downtime, it is recommended to poll all in-progress transactions to f ## Changelog -- `v3.0.0`: Update SEP31 with async kyc flow ([#1502](https://github.com/stellar/stellar-protocol/pull/1502)) +- `v3.1.0`: Deprecate `fields` in favor of `funding_method` field + ([#1567](https://github.com/stellar/stellar-protocol/pull/1567/)) +- `v3.0.0`: Update SEP-31 with async kyc flow ([#1502](https://github.com/stellar/stellar-protocol/pull/1502)) - `v2.6.0`: Add `fee_details` field to the transaction object ([#1429](https://github.com/stellar/stellar-protocol/pull/1429)) - `v2.5.0`: Deprecate and make optional the use of per-transaction `fields` objects diff --git a/ecosystem/sep-0038.md b/ecosystem/sep-0038.md index 3386e8072..f12d5574c 100644 --- a/ecosystem/sep-0038.md +++ b/ecosystem/sep-0038.md @@ -7,9 +7,9 @@ Author: Jake Urban <@jakeurban> and Leigh McCulloch <@leighmcculloch> Track: Standard Status: Draft Created: 2021-04-09 -Updated: 2024-09-26 +Updated: 2024-11-07 Discussion: https://github.com/stellar/stellar-protocol/issues/901 -Version 2.4.0 +Version 2.4.1 ``` ## Summary @@ -149,12 +149,12 @@ A `200 Success` status code should be returned for successful requests. `assets` Object Schema -| Name | Type | Description | -| ----------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `asset` | string | The [Asset Identification Format](#asset-identification-format) value. | -| `sell_delivery_methods` | array | (optional) Only for non-Stellar assets. An array of objects describing the methods a client can use to sell/deliver funds to the anchor. The method of delivery may affect the expiration and/or price provided in a [`POST /quote`](#post-quote) response. If the delivery method is not necessary for providing accurate quotes and expirations, the server can omit this attribute. | -| `buy_delivery_methods` | array | (optional) Only for non-Stellar assets. An array of objects describing the methods a client can use to buy/retrieve funds from the anchor. The method of delivery may affect the expiration and/or price provided in a [`POST /quote`](#post-quote) response. If the delivery method is not necessary for providing accurate quotes and expirations, the server can omit this attribute. | -| `country_codes` | array | (optional) Only for fiat assets. A list of [ISO 3166-2](https://en.wikipedia.org/wiki/ISO_3166-2) codes of the countries where the Anchor operates for fiat transactions. Anchor may not require second part of the ISO 3166-2 to be passed (i.e. use [ISO-3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) instead). | +| Name | Type | Description | +| ----------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `asset` | string | The [Asset Identification Format](#asset-identification-format) value. | +| `sell_delivery_methods` | array | (optional) Only for non-Stellar assets. An array of objects describing the methods a client can use to sell/deliver funds to the anchor. All methods listed here should match the `funding_methods` options specified in the protocol (E.g. [SEP-6] `GET /info`) where quote is being applied. The method of delivery may affect the expiration and/or price provided in a [`POST /quote`](#post-quote) response. If the delivery method is not necessary for providing accurate quotes and expirations, the server can omit this attribute. | +| `buy_delivery_methods` | array | (optional) Only for non-Stellar assets. An array of objects describing the methods a client can use to buy/retrieve funds from the anchor. All methods listed here should match the `funding_methods` options specified in the protocol (E.g. [SEP-6] `GET /info`) where quote is being applied. The method of delivery may affect the expiration and/or price provided in a [`POST /quote`](#post-quote) response. If the delivery method is not necessary for providing accurate quotes and expirations, the server can omit this attribute. | +| `country_codes` | array | (optional) Only for fiat assets. A list of [ISO 3166-2](https://en.wikipedia.org/wiki/ISO_3166-2) codes of the countries where the Anchor operates for fiat transactions. Anchor may not require second part of the ISO 3166-2 to be passed (i.e. use [ISO-3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) instead). | Object Schema for `sell_delivery_methods` and `buy_delivery_methods`. @@ -640,10 +640,13 @@ GET /quote/de762cda-a193-4961-861e-57b31fed6eb3 } ``` +[`SEP-6`]: sep-0006.md [`SEP-10`]: #authentication ## Changelog +- `v2.4.1`: `sell_delivery_methods` and `buy_delivery_methods` should match corresponding `funding_methods` options + specified in the SEP-6 or SEP-31 protocol. ([#1567](https://github.com/stellar/stellar-protocol/pull/1567/)) - `v2.4.0`: Add `sell_delivery_method` and `buy_delivery_method` to the `GET /quote` and `POST /quote` response. ([#1527](https://github.com/stellar/stellar-protocol/pull/1556)) - `v2.3.0`: Add `buy_asset` to the `GET /prices` endpoint.