You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, Anchors are expected to return deposit instructions (In the how field but may change in the future) in the response of the GET /deposit endpoint.
This approach does not work if the Anchor is not able to return the deposit instructions immediately. For example, if the Anchor needs to manually validate a user's KYC information, it should not return deposit instructions until the
validation is complete.
Additionally, the KYC fields required for a deposit may different for each deposit type as well as the arguments passed to the
deposit such as amount, the user's country, etc. The standard currently assumes that the KYC fields are the same for all deposits with the same type. This is not always the case. For example, a deposit of 100 USD may require a different set of KYC fields than a deposit of 10,000 USD.
What would you like to see?
SEP-6 should provide a way for wallets to request deposit instructions without requiring the Anchor to return them immediately from the GET /deposit endpoint.
One way to do this is to immediately put the SEP-6 transaction created by the deposit request into a pending_anchor state with the deposit instructions omitted from the deposit response. Once the KYC information has been validated, the Anchor can transition the transaction to the pending_user_transfer_start state and include the deposit instructions in the GET /transactions response.
If the Anchor determines that more KYC information needs to be provided for the deposit, it can transition the transaction to the pending_customer_info_needed state and include the missing KYC fields in the GET /transactions response so that the wallet can prompt the user to provide the missing information using SEP-12.
What alternatives are there?
The alternative is to require Anchors to return deposit instructions immediately from the GET /deposit endpoint and leverage the 403 status code to indicate that either KYC information is missing or the deposit is not ready to be processed.
The text was updated successfully, but these errors were encountered:
philipliu
changed the title
SEP-6: Deferred deposit instructions
SEP-6: Providing deposit instructions asynchronously
Jul 25, 2023
### Proposal
This adds new fields to the `transaction` object to facilitate
Anchors providing deposit instructions outside of `GET /deposit` response.
### Backwards Compatability
This change is backward compatible as it does not introduce
new required fields if Anchors can provide deposit instructions in
the `GET /deposit` response.
Resolves#1372,
#1368.
What problem does your feature solve?
Today, Anchors are expected to return deposit instructions (In the
how
field but may change in the future) in the response of theGET /deposit
endpoint.This approach does not work if the Anchor is not able to return the deposit instructions immediately. For example, if the Anchor needs to manually validate a user's KYC information, it should not return deposit instructions until the
validation is complete.
Additionally, the KYC fields required for a deposit may different for each deposit type as well as the arguments passed to the
deposit such as amount, the user's country, etc. The standard currently assumes that the KYC fields are the same for all deposits with the same type. This is not always the case. For example, a deposit of 100 USD may require a different set of KYC fields than a deposit of 10,000 USD.
What would you like to see?
SEP-6 should provide a way for wallets to request deposit instructions without requiring the Anchor to return them immediately from the
GET /deposit
endpoint.One way to do this is to immediately put the SEP-6 transaction created by the deposit request into a
pending_anchor
state with the deposit instructions omitted from the deposit response. Once the KYC information has been validated, the Anchor can transition the transaction to thepending_user_transfer_start
state and include the deposit instructions in theGET /transactions
response.If the Anchor determines that more KYC information needs to be provided for the deposit, it can transition the transaction to the
pending_customer_info_needed
state and include the missing KYC fields in theGET /transactions
response so that the wallet can prompt the user to provide the missing information using SEP-12.What alternatives are there?
The alternative is to require Anchors to return deposit instructions immediately from the
GET /deposit
endpoint and leverage the 403 status code to indicate that either KYC information is missing or the deposit is not ready to be processed.The text was updated successfully, but these errors were encountered: