diff --git a/ecosystem/sep-0006.md b/ecosystem/sep-0006.md index e4aab6827..92d6795cb 100644 --- a/ecosystem/sep-0006.md +++ b/ecosystem/sep-0006.md @@ -410,7 +410,8 @@ Request Parameters: | `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. | +| `funding_method` | string | (optional) Method supported by the anchor for transferring or settling assets. If the anchor supports multiple deposit methods (e.g. `SEPA` or `SWIFT`), the wallet should specify `funding_method`. This field may be necessary for the anchor to determine which KYC fields to collect. | +| `type` | string | (**deprecated** in favor of `funding_method` ,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. | @@ -711,7 +712,8 @@ 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. | +| `funding_method` | string | (optional) Method supported by the anchor for transferring or settling assets. 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. | +| `type` | string | (**deprecated** in favor of `funding_method` ,optional) 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. | | `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. | @@ -824,9 +826,10 @@ Request Parameters: | `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. | +| `funding_method` | string | (optional) Method supported by the anchor for transferring or settling assets. If the anchor supports multiple deposit methods (e.g. `SEPA` or `SWIFT`), the wallet should specify `funding_method`. This field may be necessary for the anchor to determine which KYC fields to collect. | +| `type` | string | (**deprecated** in favor of `funding_method`, 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. | @@ -873,7 +876,8 @@ Request parameters: | `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. | +| `funding_method` | string | (optional) Method supported by the anchor for transferring or settling assets. 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. | +| `type` | string | (**deprecated** in favor of `funding_method` ,optional) 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. | @@ -1078,6 +1082,7 @@ The response should be a JSON object like: "authentication_required": true, "min_amount": 0.1, "max_amount": 1000, + "funding_method": ["SEPA", "SWIFT", "cash"], "fields": { "email_address" : { "description": "your email address for transaction status updates", @@ -1104,6 +1109,7 @@ The response should be a JSON object like: "deposit-exchange": { "USD": { "authentication_required": true, + "funding_method": ["SEPA", "SWIFT", "cash"], "fields": { "email_address" : { "description": "your email address for transaction status updates", @@ -1129,6 +1135,7 @@ The response should be a JSON object like: "authentication_required": true, "min_amount": 0.1, "max_amount": 1000, + "funding_method": ["bank_account", "cash"], "types": { "bank_account": { "fields": { @@ -1161,6 +1168,7 @@ The response should be a JSON object like: "authentication_required": true, "min_amount": 0.1, "max_amount": 1000, + "funding_method": ["bank_account", "cash"], "types": { "bank_account": { "fields": { @@ -1213,6 +1221,8 @@ 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_method`: Optional. A list of methods supported by the anchor for transferring or settling assets, often + detailing options like `WIRE` or `ACH` for fiat settlements. - `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 +1243,18 @@ 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_method`: Optional. A list of methods supported by the anchor for transferring or settling assets. For + example, `["SEPA", "SWIFT", "cash"]`. 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. +- `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 +1268,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 diff --git a/ecosystem/sep-0031.md b/ecosystem/sep-0031.md index 70534818f..f672587c5 100644 --- a/ecosystem/sep-0031.md +++ b/ecosystem/sep-0031.md @@ -326,38 +326,7 @@ The response should be a JSON object like: "fee_percent": 1, "min_amount": 0.1, "max_amount": 1000, - "fields": { - "type": { - "description": "methods supported by the anchor for asset deposits", - "choices": ["SEPA", "SWIFT"], - "optional": false - } - }, - "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_method": ["SEPA", "SWIFT"] } } } @@ -376,49 +345,14 @@ the corresponding off-chain asset, after fees have been applied. | Name | Type | Description | | --------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `sep12` | object | An object containing `sender` and `receiver` keys. | | `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 that contains multiple key-value pairs, where each key represents a field related to the transaction, and the value is an `transaction` object describing the field's details. | +| `funding_method` | array | (optional) Methods supported by the anchor for transferring or settling assets, often detailing options like WIRE or ACH for fiat settlements. | | `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 Schema - -| Name | Type | Description | -| ---------- | ------ | ------------------------------------------------------------------------------------------------------------ | -| `sender` | object | An object containing a `types` key if KYC information is required for the Sending Client, empty otherwise. | -| `receiver` | object | An object containing a `types` key if KYC information is required for the Receiving Client, empty otherwise. | - -#### `types` Object Schema - -| Name | Type | Description | -| ------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `types` | object | (optional) An object containing the accepted values for the `type` parameter in [SEP-12](sep-0012.md) requests. Each key should map to an object with a human-readable `description`. | - -If KYC is required for a Sending or Receiving client in some cases but not others, it is recommended to provide values -in the respective `types` object for all cases and return an empty `fields` object from -[SEP-12 GET /customer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-get) for -the cases where no KYC is necessary. - -#### `fields` Object Schema - -| Name | Type | Description | -| -------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `fields` | object | An object that contains multiple key-value pairs, where each key represents a field related to the transaction, and the value is an `transaction` object describing the field's details. | - -#### `transaction` Object Schema - -| Name | Type | Description | -| ------------- | ------- | --------------------------------------------------- | -| `description` | string | A description of field to show to user. | -| `choices` | array | (optional) A list of possible values for the field. | -| `optional` | boolean | (optional) false if not specified. | - ### POST Transactions #### Request @@ -489,19 +423,20 @@ Content-Type: application/json ##### 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. | +| `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` | 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. | +| `funding_method` | string | (optional) Type of method for Receiving Anchor to deliver asset. If the Receiving Anchor supports multiple methods (e.g. `SEPA` or `SWIFT`), the wallet should specify `funding_method`. This field may be necessary for the anchor to determine which KYC fields to collect. | #### Responses