Skip to main content
Integrating with the Anchor Platform involves three key areas:
  • Building a web-based user experience that can be opened in a mobile web view
  • Providing transaction status updates to the Anchor Platform
  • Fetching transaction status updates from the Anchor Platform

Building a Web-Based User Experience

The Anchor Platform does not offer a white-label UI that your business can utilize, and instead expects the business to build their own UI and backend system. We won’t build an entire on & off-ramp user experience in this guide, but will cover the ways in which your existing product should be updated to be compatible with the Anchor Platform.

Authentication

If your business has an existing on & off-ramp product, you likely have an existing system for user authentication. However, because the Anchor Platform authenticates the user prior to providing the business’s URL, requiring the user to go through another form of authentication is actually unnecessary. In this way, the Anchor Platform can be thought of as providing an alternative form of authentication. The business is free to continue requiring users to authenticate using their existing system, but the ideal user experience would skip this step and create an authenticated session for the user if they have already authenticated using their Stellar account. The Anchor Platform adds a JWT token query parameter to the business’s URL given to the wallet application. This token is signed by the previously-configured SECRET_SEP24_INTERACTIVE_URL_JWT_SECRET value, and includes the information you need to identify the user. The process should look something like this:
  1. Pass the token added to the URL of your backend system
  2. Verify the signature on the token and check its expiration
  3. Create an authenticated session for the user identified by token.sub
The decoded contents of the token will look something like this:
Note that the sub value identifies the user using a Stellar account and integer. This is what the value will be when custodial applications that use an omnibus account authenticate with your service. When non-custodial wallets authenticate, the token may look slightly different.
The sub value here only contains a public key to identify the user, and the data.client_domain field identifies the wallet application used to authenticate. In both cases, all information in the data object is optional, and will only be present if the wallet provides that information. Let’s add a backend server to our compose file that will be used to verify the token and create authenticated web sessions for users initiating transactions.
Let’s create a simple Docker container for our application.
Now let’s create a minimal NodeJS application.
Below is an example of a backend server authenticating a user using NodeJS.
Run this with the platform server and database and initiate a new transaction with the demo wallet. Then, we’ll send the token to our server.

Providing Updates to the Platform

Let’s create an endpoint for our business server that accepts the information collected in our UI.
This will update the Anchor Platform’s database with the information provided and enable wallet applications to fetch this updated information so it can relay it back to the user. You should have already informed the user of the transaction’s amounts and that your business’s is waiting for the on-chain payment to arrive, but providing these updates allows users to view their transactions’ statuses through their mobile application without opening the business’ UI again.
At this time, the Anchor Platform does not send notifications to the wallet application when transaction statuses change, however, it is on our roadmap to add these notifications or “callback requests” so that wallet applications do not have to poll the Anchor Platform for updates.

Fetching Updates from the Platform

If you only use the Anchor Platform to expose the SEP APIs to wallet applications, then you won’t have a strong reason for fetching transaction status updates from the Anchor Platform, mostly because it won’t update the transaction status until you make JSON-RPC API requests. However, if you use the Anchor Platform to monitor the Stellar network for incoming payments (associated with withdrawal transactions), the Anchor Platform will update transaction statuses when payments are received. There are two ways to fetch updates from the Anchor Platform,
  • Polling the Platform API’s GET /transactions/:id endpoint for the transactions you’re expecting a payment for
  • Streaming transaction status change events from a Kafka cluster
While streaming transaction status changes from a Kafka cluster may be a more robust and scalable approach, we’re going to use the polling method in this guide. Setting up and using a Kafka cluster will be the subject of a different section of the docs. First, let’s configure the Anchor Platform to observe the Stellar network for incoming payments.
The --stellar-observer command starts a process that monitors the distribution accounts configured in your config.yaml file for withdrawal payments. If a payment is sent to one of these accounts and the memo attached to the transaction matches a memo value provided or generated by the Anchor Platform, the Anchor Platform will consider the transaction that memo is associated with as received and update the transaction’s status to pending_anchor. It does this by making a JSON-RPC API request, so we need to configure the URL it should use.
Let’s make some additions to the server.js file so we can poll the Anchor Platform for our expected payments.

Full Example Implementation

Stellar provides an example business server implementation for SEP-24. It’s split into two parts: 1) a web UI, accessible for the end user; and 2) a back-end implementation, used to get and push updates from/to the Anchor Platform. The code for web UI can be found here The code for the backend is a part of the Anchor Platform, and is available as a submodule.