Improve withdrawal flow on wallets that enable cross-border payments #404
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
accordeiro
changed the title
msfeldstein
reviewed
Sep 17, 2019
ecosystem/sep-0006.md
Outdated
| @@ -420,7 +424,7 @@ The wallet must use the response fields in the following way to complete the wit | |||
| - `withdraw_anchor_account`: send the withdrawal payment to this Stellar account. | |||
| - `withdraw_memo`: (if specified) use this memo in the payment transaction to the anchor. | |||
| - `withdraw_memo_type`: use this as the memo type. | |||
| - `amount_in`: the amount expected in the stellar payment. | |||
| - `amount_in`: the amount expected in the Stellar payment (with an acceptable error margin of 10%) | |||
There was a problem hiding this comment.
The amount_in should never fluctuate right? Only the amount that actually ends up sent? The error margin here is confusing.
There was a problem hiding this comment.
Yeah, I agree it's confusing. I wanted to make it clear for wallets that there is an acceptable error margin, but this is probably not the spot. I'll push a change to address this shortly.
msfeldstein
suggested changes
Sep 17, 2019
ecosystem/sep-0006.md
Outdated
| * We recommend you use [SEP-10 authentication](#authentication) in the interactive flow and do not separately prompt for password to achieve a good user experience (although asking for MFA when confirming a transaction or requiring email confirmation is reasonable). Be sure to accept the [`jwt` parameter](#adding-parameters-to-the-url) so the user does not have to re-login. Support the `callback` parameter as well. | ||
| * Test your interactive flows on mobile. They should be easy to use on all devices: make them responsive, handle auto-fill well, and do smart keyboard management on mobile devices. | ||
| * **Interactive deposit** | ||
| * Your interactive deposit popup will do everything needed to initiate the deposit without the user needing to interact with the wallet further. It should either directly initiate the deposit, or handle displaying information (such as reference number or bank account number) that the user will need to complete their deposit. | ||
| * **Interactive withdrawal** | ||
| * Your withdrawal flow will have to pass control back to the user's wallet, so it can initiate the withdrawal with a Stellar payment to your withdrawal address. You'll need to communicate the withdrawal address, amount and status to the wallet using the [`callback` parameter](#adding-parameters-to-the-url), and also by making it available on your `/transaction` endpoint. See [details](#guidance-for-wallets-completing-an-interactive-withdrawal). | ||
| * If an `amount` parameter is provided to the interactive URL, make sure to use that value to pre-populate the amount on the interactive form. This greatly improves the user experience, especially in wallets that enable cross-border payments. |
There was a problem hiding this comment.
Remove the reference to cross-border payments here
ecosystem/sep-0006.md
Outdated
| * We recommend you use [SEP-10 authentication](#authentication) in the interactive flow and do not separately prompt for password to achieve a good user experience (although asking for MFA when confirming a transaction or requiring email confirmation is reasonable). Be sure to accept the [`jwt` parameter](#adding-parameters-to-the-url) so the user does not have to re-login. Support the `callback` parameter as well. | ||
| * Test your interactive flows on mobile. They should be easy to use on all devices: make them responsive, handle auto-fill well, and do smart keyboard management on mobile devices. | ||
| * **Interactive deposit** | ||
| * Your interactive deposit popup will do everything needed to initiate the deposit without the user needing to interact with the wallet further. It should either directly initiate the deposit, or handle displaying information (such as reference number or bank account number) that the user will need to complete their deposit. | ||
| * **Interactive withdrawal** | ||
| * Your withdrawal flow will have to pass control back to the user's wallet, so it can initiate the withdrawal with a Stellar payment to your withdrawal address. You'll need to communicate the withdrawal address, amount and status to the wallet using the [`callback` parameter](#adding-parameters-to-the-url), and also by making it available on your `/transaction` endpoint. See [details](#guidance-for-wallets-completing-an-interactive-withdrawal). | ||
| * If an `amount` parameter is provided to the interactive URL, make sure to use that value to pre-populate the amount on the interactive form. This greatly improves the user experience, especially in wallets that enable cross-border payments. | ||
| * In order to fulfill a withdrawal, a wallet must make a payment to the Stellar address that the anchor provides. It is the anchor's job to watch for Stellar payments to the given address and make the external transaction as soon as they're detected. It is recommended for anchors to listen to at least `payment` and `path_payment` [operations](https://www.stellar.org/developers/horizon/reference/endpoints/payments-all.html), although supporting the remaining ones is important for covering all use cases. |
There was a problem hiding this comment.
It is recommended for anchors to listen to at least
paymentandpath_payment
Should we mention our SDKs do this for our /payment streaming endpoints already?
ecosystem/sep-0006.md
Outdated
| * We recommend you use [SEP-10 authentication](#authentication) in the interactive flow and do not separately prompt for password to achieve a good user experience (although asking for MFA when confirming a transaction or requiring email confirmation is reasonable). Be sure to accept the [`jwt` parameter](#adding-parameters-to-the-url) so the user does not have to re-login. Support the `callback` parameter as well. | ||
| * Test your interactive flows on mobile. They should be easy to use on all devices: make them responsive, handle auto-fill well, and do smart keyboard management on mobile devices. | ||
| * **Interactive deposit** | ||
| * Your interactive deposit popup will do everything needed to initiate the deposit without the user needing to interact with the wallet further. It should either directly initiate the deposit, or handle displaying information (such as reference number or bank account number) that the user will need to complete their deposit. | ||
| * **Interactive withdrawal** | ||
| * Your withdrawal flow will have to pass control back to the user's wallet, so it can initiate the withdrawal with a Stellar payment to your withdrawal address. You'll need to communicate the withdrawal address, amount and status to the wallet using the [`callback` parameter](#adding-parameters-to-the-url), and also by making it available on your `/transaction` endpoint. See [details](#guidance-for-wallets-completing-an-interactive-withdrawal). | ||
| * If an `amount` parameter is provided to the interactive URL, make sure to use that value to pre-populate the amount on the interactive form. This greatly improves the user experience, especially in wallets that enable cross-border payments. | ||
| * In order to fulfill a withdrawal, a wallet must make a payment to the Stellar address that the anchor provides. It is the anchor's job to watch for Stellar payments to the given address and make the external transaction as soon as they're detected. It is recommended for anchors to listen to at least `payment` and `path_payment` [operations](https://www.stellar.org/developers/horizon/reference/endpoints/payments-all.html), although supporting the remaining ones is important for covering all use cases. | ||
| * When the wallet is exchanging relatively unstable currencies, there might be slight fluctuations on value between the informed withdrawal `amount` and the actual transferred amount. It is recommended for anchors to accept an amount fluctuation of up to ±10%, and adjust the amount to be transferred (and fees) to reflect the actual value received. |
There was a problem hiding this comment.
I'd like to make this section a little clearer that the unstable currencies isn't something the anchor needs to worry about, but they should expect that the amount requested to withdraw might not be the exact amount they receive, and they should be flexible.
There was a problem hiding this comment.
I'd prefer to say "Some wallets might..." to be clear that this isn't something that always happens, and just a feature some wallets add
msfeldstein
approved these changes
Sep 17, 2019
ecosystem/sep-0006.md
Outdated
| @@ -102,6 +102,7 @@ SEP-6 lays out many options for how deposit and withdrawal can work. These are r | |||
| * 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. | |||
| * If the anchor responds with an interactive flow, handle it as [described in detail](#3-customer-information-needed-interactive). | |||
| * For now, do not handle the non-interactive or status responses to the `/withdraw` request. | |||
| * For wallets that enable cross-border payments: 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. | |||
There was a problem hiding this comment.
make the same type of "Some wallets" change here too and we should be good to go
msfeldstein
approved these changes
Sep 17, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #395. It aims to:
/withdrawand the interactive flow URLpaymentoperations besidespaymentI'm still a bit unsure whether I've made changes in the right places, since we now have the Basic Implementation recommendations and the actual specs.
@msfeldstein @tomerweller @tomquisel please let me know your thoughts.