* Fix the missing types of the withdraw request parameters and some…

… typo. (#1365)

* Fix the missing types of the `withdraw` request parameters and some typo.

ecosystem/sep-0006.md

@@ -7,7 +7,7 @@ Author: SDF
 Status: Active (Interactive components are deprecated in favor of SEP-24)
 Created: 2017-10-30
 Updated: 2023-01-13
-Version 3.18.0
+Version 3.18.1
 ```
 
 ## Simple Summary
@@ -278,11 +278,11 @@ SEP-6 lays out many options for how deposit and withdrawal can work. These are r
     * In the `/withdraw` request, have the user enter the crypto account or bank account where they'd like their withdrawal to end up and provide that to the anchor via `dest` and `dest_extra`.
     * Before making the payment, make a request to `[SEP-6]/transaction?id=<transaction_id>` to get the amount_in details. Some anchors may use additive fees, which would produce an `amount_in` different from the wallet's proposed amount.
 * **For `/deposit`**
-    * If the issuer's `/deposit` endpoint immediately returns success:
+    * If the anchor's `/deposit` endpoint immediately returns success:
         * display the deposit info that came back from the endpoint to the user, including fee. You're done! The user will execute the deposit exernally using the instructions if they want to.
     * Handle the [special cases](#special-cases), they're relatively common.
 * **For `/withdraw`**
-    * If the issuer's `/withdraw` endpoint immediately returns success:
+    * If the anchor's `/withdraw` endpoint immediately returns success:
         * Provide an interface to the user that allows them to view the withdrawal details including the computed fee. The user can confirm and then the wallet will initiate the withdrawal by sending the Stellar payment to the address provided by the issuer.
     * Some wallets might exchange currencies only once they're ready to send the withdrawal payment, so exchange rate fluctuations might require withdrawal values to slightly vary from the originally provided `amount`. Anchors are instructed to accept a variation of ±10% between the informed `amount` and the actual value sent to the anchor's Stellar account. The withdrawn amount will be adjusted accordingly.
 * **Transaction history**
@@ -334,6 +334,8 @@ Name | Type | Description
 `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.
 
+The request parameters also must include the required fields from the `/info` endpoint. 
+
 Example:
 
 ```
@@ -524,8 +526,10 @@ Name | Type | Description
 `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.
 `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` | (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` | (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.
+`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.
+
+The request parameters also must include the required fields from the `/info` endpoint.
 
 Example:
 
@@ -668,7 +672,7 @@ The expected response as well as the special cases are the same ones covered in
 
 ## Deposit and Withdraw shared responses
 
-### 2. Customer information needed (non-interactive)
+### Customer information needed (non-interactive)
 
 Response code: `403 Forbidden`
 
@@ -1416,6 +1420,7 @@ If the information was malformed, or if the sender tried to update data that isn
 
 ## Changelog
 
+* `v3.18.1`: Fix the missing types of the `withdraw` request parameters and some typo.  ([#1365](https://github.com/stellar/stellar-protocol/pull/1365))
 * `v3.18.0`: Added `refunded` status and `updated_at` transaction fields to match other SEPs (24, 31) ([#1336](https://github.com/stellar/stellar-protocol/pull/1336))
 * `v3.17.1`: Allow anchors to omit the deprecated `X-Stellar-Signature` header ([#1335](https://github.com/stellar/stellar-protocol/pull/1335))
 * `v3.17.0`: Deprecate `X-Stellar-Signature` in favor of `Signature` ([#1333](https://github.com/stellar/stellar-protocol/pull/1333))