Add support for asynchronous deposit instructions

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: 2023-01-13
-Version 3.18.1
+Updated: 2023-08-10
+Version 3.19.0
 ```
 
 ## Simple Summary
@@ -1121,6 +1121,8 @@ Name | Type | Description
 `refunds` | object | (optional) An object describing any on or off-chain refund associated with this transaction. The schema for this object is defined in the [Refunds Object Schema](#refunds-object-schema) section below.
 `required_info_message` | string | (optional) A human-readable message indicating any errors that require updated information from the user.
 `required_info_updates` | object | (optional) A set of fields that require update from the user described in the same format as [/info](#info).  This field is only relevant when `status` is `pending_transaction_info_update`.
+`customer_info_type` | string | (optional) The SEP-12 type of customer information that is required to complete the transaction. This field is only relevant when `status` is `pending_customer_info_update`.
+`how` | string | (optional) A human-readable message indicating how the user should complete the transaction. This field is only relevant when an anchor cannot synchronously provide the instructions as part of the `GET /deposit` response.
 `claimable_balance_id` | string | (optional) ID of the Claimable Balance used to send the asset initially requested. Only relevant for deposit transactions.
 
 `status` should be one of:
@@ -1361,7 +1363,7 @@ Every HTTP status code other than `200 OK` will be considered an error and in th
 
 ## Pending Customer Info Update
 
-In certain cases the anchor may need updated customer information from the user. For example, the bank could tell the anchor that the account address does not match the user's name or other identifying information. Since this information was sent via SEP-12, the transaction should go into the `pending_customer_info_update` status until the sender makes another `PUT /customer` request to update. The sending anchor can check which fields need to be updated by making a `GET /customer` request including the `id` or `account` & `memo` parameters. The anchor should respond with a `NEEDS_INFO` status and include the fields that need to be updated.
+In certain cases the anchor may need updated customer information from the user. For example, the bank could tell the anchor that the account address does not match the user's name or other identifying information. Since this information was sent via SEP-12, the transaction should go into the `pending_customer_info_update` status until the sender makes another `PUT /customer` request to update. The anchor can check which fields need to be updated by making a `GET /customer` request including the `id` or `account` & `memo` with the `customer_info_type` associated with the transaction. The anchor should respond with a `NEEDS_INFO` status and include the fields that need to be updated.
 
 ## Pending Transaction Info Update
 
@@ -1420,6 +1422,7 @@ If the information was malformed, or if the sender tried to update data that isn
 
 ## Changelog
 
+* `v3.19.0` Add support for asynchronous deposit instructions. ([#1379](https://github.com/stellar/stellar-protocol/pull/1379/))
 * `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))