Skip to main content
This guide is available on four different programming languages: Typescript, Kotlin, Flutter (Dart) and Swift. You can change the shown version on each page via the buttons above.
The SEP-24 standard defines the standard way for anchors and wallets to interact on behalf of users. Wallets use this standard to facilitate exchanges between on-chain assets (such as stablecoins) and off-chain assets (such as fiat, or other network assets such as BTC). During the flow, a wallet makes several requests to the anchor, and finally receives an interactive URL to open in iframe. This URL is used by the user to provide an input (such as KYC) directly to the anchor. Finally, the wallet can fetch transaction information using query endpoints.

Get Anchor Information

Let’s start with getting an instance of Sep24 class, responsible for all SEP-24 interactions:
First, let’s get the information about the anchor’s support for SEP-24. This request doesn’t require authentication, and will return generic info, such as supported currencies, and features supported by the anchor. You can get a full list of returned fields in the SEP-24 specification.

Interactive Flows

Before getting started, make sure you have connected to the anchor and received an authentication token, as described in the Stellar Authentication wallet guide. We will use the authToken object in the examples below as the SEP-10 authentication token, obtained earlier. To initiate an operation, we need to know an asset. You may want to hard-code it, or get it dynamically from the anchor’s info file, like shown below (for USDC):
Before starting with the deposit flow, make sure that the user account has established a trustline for the asset you are working with.

Basic Flow

Let’s start with a basic deposit:
As a result, you will get an interactive response from the anchor. Open the received URL in an iframe and save the transaction ID for future reference:
Similarly to the deposit flow, a basic withdrawal flow has the same method signature and response type:

Providing KYC Info

To improve the user experience, the SEP-24 standard supports passing user KYC to the anchor via SEP-9. In turn, the anchor will pre-fill this information in the interactive popup.
While SEP-9 supports passing binary data, the current version of the SDK doesn’t offer such functionality.
At the time, accepted SEP-9 is not strictly typed yet. Improved typing will be offered in future versions.

Changing Stellar Transfer Account

By default, the Stellar transfer will be sent to the authenticated account (with a memo) that initiated the deposit. While in most cases it’s acceptable, some wallets may split their accounts. To do so, pass additional account (and optionally a memo):
Similarly, for a withdrawal, the origin account of the Stellar transaction could be changed:

Getting Transaction Info

On the typical flow, the wallet would get transaction data to notify users about status updates. This is done via the SEP-24 GET /transaction and GET /transactions endpoint. Alternatively, some anchors support webhooks for notifications. Note that this feature is not widely adopted yet.

Tracking Transaction

Let’s look into how to use the wallet SDK to track transaction status changes. We will use Watcher class for this purpose. First, let’s initialize watcher and start tracking a transaction.
Alternatively, we can track multiple transactions for the same asset.
Next, let’s get the channel provided by WatcherResult to receive events.
This code example will consume all events coming from the channel until it’s closed. There are three types of events:
  • StatusChange: indicates that transaction status has changed.
  • ExceptionHandlerExit: indicates that the exception handler exited the processing loop. With default retry handler it happens when retries are exhausted.
  • ChannelClosed: indicates that the channel is closed and no more events will be emitted. This event will always fire. If ExceptionHandlerExit happened, channel will close right after. Otherwise, (under normal circumstances) it will stop when all transactions reach terminal statuses.
Events are stored in the channel until they are received, and calling the receive() method will block the channel until a message is received. You can read more about how channels work in the channel documentation.

Fetching Transaction

While Watcher class offers powerful tracking capabilities, sometimes it’s required to just fetch a transaction (or transactions) once. The Anchor class allows you to fetch a transaction by ID, Stellar transaction ID, or external transaction ID:
It’s also possible to fetch transaction by the asset

Submitting Withdrawal Transfer

Previously, we took a look at starting the withdrawal flow. Now, let’s take a look at a full example. First, start the withdrawal:
Next, open an interactive url :
After that we need to wait until the anchor is ready to receive funds. To do so, we will be waiting until transaction reaches pending_user_transfer_start status. This code uses a simple watching (polling) mechanism with no bail-out condition. The application’s code should be more robust.
Next, sign and submit the Stellar transfer:
Where keypair is the SEP-10 authenticated account. If you want to transfer funds from a different address, refer to Changing Stellar Transfer Account section. Code for submitting transactions to Stellar should be developed thoughtfully. The SDF has a documentation page dedicated to submitting transactions and handling errors gracefully. Here are a few things you need to keep in mind:
  • Offer a high fee. Your fee should be as high as you would offer before deciding the transaction is no longer worth sending. Stellar will only charge you the minimum necessary to be included in the ledger — you won’t be charged the amount you offer unless everyone else is offering the same amount or greater. Otherwise, you’ll pay the smallest fee offered in the set of transactions included in the ledger.
  • Set a maximum timebound on the transaction. This ensures that if your transaction is not included in a ledger before the set time, you can reconstruct the transaction with a higher offered fee and submit it again with better chances of inclusion.
  • Resubmit the transaction when you get 504 status codes. 504 status codes are just telling you that your transaction is still pending — not that it has been canceled or that your request was invalid. You should simply make the request again with the same transaction to get a final status (either included or expired).
Finally, let’s track transaction status updates. In this example we simply check if the transaction has been completed: