Describe recommended SEP-6 implementations

ecosystem/sep-0006.md

@@ -67,6 +67,50 @@ Valid CORS headers are necessary to allow web clients from other sites to use th
 Access-Control-Allow-Origin: *
 ```
 
+## Recommendations
+
+SEP-6 lays out many options for how deposit and withdrawal can work. These are recommendations for getting a wallet or anchor implementation working with minimal effort while providing a great user experience.
+
+### Basic Wallet Implementation
+
+* Identify assets you want to support manually in advance
+* For each asset, use information from its `stellar.toml` and its `/info` endpoint to display useful information to the user like transaction fee structure, types of deposits and withdrawal supported, and details about the anchor like street address.
+* Use `/info` to determine:
+    * anchor endpoints that require authentication, and perform [authentication](#authentication) via SEP-10 before hitting those endpoints
+    * Fee structure: if `fee_fixed` and `fee_percent` are provided, show this to the user early in the process so they're fully informed.
+    * If the `/fee` endpoint is enabled, use it for computing fees when you need to show them to the user.
+* While `/info` allows an anchor to communicate non-standard fields that are needed for `/deposit` or `/withdraw`, it's easier for a basic wallet implemention to hard-code extra fields that are needed on a per-anchor basis, and ensure those fields are passed in properly.
+* As a conservative measure, pass in any optional fields (including amount, which you should ask the user for) for `/deposit` or `/withdraw` that the wallet has on-hand, such as `email_address` and `account`.
+* For `/deposit`
+    * If the issuer's `/deposit` endpoint immediately returns success:
+        * display the deposit info that came back from the endpoint to the user, including fee and you're done! The user will execute the deposit exernally using the instructions if they want to.
+    * If the issuer responds with an interactive flow, handle it as [described in detail](#3-customer-information-needed-interactive). We expect this is the most common flow, and it should work smoothly.
+    * For now, do not handle the non-interactive or status responses to the `/deposit` request.
+    * Handle the [special cases](#special-cases), they're relatively common.
+* For `/withdraw`
+    * If the issuer's `/withdraw` endpoint immediately returns success:
+        * Provide an interface to the user that allows them to pick a withdrawal amount and view the total fee. The user can then confirm and your 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.
+* It provides a better experience for users to show deposits or withdrawal they've completed in the past via the `/transactions` endpoint, but it's not strictly necessary.
+
+### Basic Anchor Implementation
+
+* Provide a full-featured implementation of `/info`. The more info you provide there, the better a wallet can relay deposits and withdrawals from the user to you.
+* Decide which endpoints, if any, need to be authenticated, and declare that properly in the `/info` endpoint.
+* Pick your approach to [fees](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md#fee). We strongly recommend using `/info` to express fees if possible as it provides a better user experience (the user can see the fee structure in the wallet early in the process).
+* If you need no KYC info, explicit user signup, or other interaction from users to show deposit info or process a withdrawal, you can have your `/deposit` and `/withdraw` endpoints immediately return success with all info that the user will need to complete the deposit or withdrawal.
+* Otherwise, we recommend you provide an interactive deposit or withdrawal flow.
+* For both interactive deposit and withdrawal:
+    * Use the [Customer info needed response](#3-customer-information-needed-interactive) and include the `id` field so the wallet can check up on the status of the transaction (using the `id`) if they want.
+    * You should almost certainly use [authentication](#authentication) in the interactive flow, so 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.
+* 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 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).
+* Provide the `/transaction` endpoint. The wallet may rely on it to complete interactive withdrawals.
+* Provide the `/transactions` endpoint. Users like to see transaction histories.
+
 ## Deposit
 
 A deposit is when a user sends an external token (BTC via Bitcoin, USD via bank transfer, etc...) to an address held by an anchor. In turn, the anchor sends an equal amount of tokens on the Stellar network (minus fees) to the user's Stellar account.
@@ -336,7 +380,7 @@ To detect that the user has completed their interaction with the anchor, the wal
 
 The wallet must use the response fields in the following way to complete the withdrawal:
 
-- `status`: `incomplete` means the user is either still going through the interactive flow with the issuer, or has abandoned the transaction part way through. The wallet should simply keep polling or waiting in this case. The wallet should provide the user with an `x` or other way to abort the transaction and return to their wallet in this case. When the user aborts on the wallet side, the wallet must close the popup containing the anchor's flow as well.
+- `status`: `incomplete` means the user is either still going through the interactive flow with the anchor, or has abandoned the transaction part way through. The wallet should simply keep polling or waiting in this case. The wallet should provide the user with an `x` or other way to abort the transaction and return to their wallet in this case. When the user aborts on the wallet side, the wallet must close the popup containing the anchor's flow as well.
 - `status`: `pending_user_transfer_start` means the user has given all necessary info to the anchor. The next step is for the wallet to confirm the withdrawal with the user, and then send a Stellar payment to the anchor's address.
 
 When the wallet receives the `pending_user_transfer_start` status, it must use these fields from the response in the following ways: