Skip to main content

Payments Overview

A payment constitutes the transfer of a token from one account to another. On Stellar network a token can be either a Stellar asset or a custom contract token which follows the SEP-41 token standard. There are two primary ways payments are transacted on Stellar: The approach you should take depends on the use case:
  • If you want to make a payment of a Stellar asset between two Stellar accounts, use the payment operations. Transaction fees are cheaper when using them compared to the fees for invoking the asset’s token contract directly which is referred to as the Stellar Asset Contract.
  • If you want to make a payment of a Stellar asset between a Stellar account and a contract address, or between two contract addresses, then the asset’s contract must be used. Stellar’s payment-related operations cannot have contract addresses as their source or destination.
  • If you want to make a payment of a custom contract token which is not a Stellar asset but follows the SEP-41 token standard, you must use the token’s contract. Stellar’s payment operations can only be used to transfer Stellar assets.
To learn more about the differences between Stellar assets and contract tokens, see the Tokens overview.
In the following code samples, proper error checking is omitted for brevity. However, you should always validate your results, as there are many ways that requests can fail.

Using Payments Example

This example highlights the approach mentioned for transacting payments using operations and assets and using the Stellar RPC with Stellar Client SDKs to perform all actions needed.

Send a Payment

Lets demonstrate a payment of an asset on Stellar. We will build a transaction with a payment operation to send 10 Lummens from a sender account to a receiver account, sign it as the sender account, and submit it to the network.
  • Submitting the transaction to the SDF-maintained public testnet instance of Stellar RPC server.
  • When submitting transactions to the RPC server it’s possible that you will not receive a response from the server due to network conditions.
    • In such a situation it’s impossible to determine the status of your transaction.
    • Highlights a recommendation to always save a transaction (or transaction encoded in XDR format) in a variable or a database and resubmit it if you don’t know its status.
    • The transaction in serialized XDR format is idempotent meaning if the transaction has already been successfully applied to the ledger, RPC will simply return the saved result and not attempt to submit the transaction again.
    • Only in cases where a transaction’s status is unknown (and thus will have a chance of being included into a ledger) will a resubmission to the network occur.

Monitoring Payments as event stream

Leverage the latest Protocol 23 (Whisk) to capture payment activity as pure events. These events can be efficiently monitored using the RPC server’s getEvents method, which provides server-side filtering and real-time payment detection. The RPC approach offers several advantages:
  • Server-side event topic filtering: Filter for specific events using topic patterns
  • Efficient polling: Use cursors and pagination for reliable event processing
  • Unified event model: supports CAP-67, all asset movements on the network are emitted as events with standardized topic names to indicate the type of movement (e.g., “transfer” for payments)
  • Better error handling: RPC stateless HTTP polling is more resilient than persistent streaming protocols like SSE or WebSockets
Demonstrate near real-time monitoring of transactions from the Stellar network by establishing an asynchronous listener to consume events from RPC and filter them by topic for just our example payments generated by our previous payments script.

Running Your Payment Pipeline with RPC

  1. Run the payment submission script in one terminal. Leave it running, it will submit a payment once every 30 seconds.
  1. Run the payment monitor script in a separate terminal.
  1. Observe the payment events as they’re detected and displayed on console.

Summary

  • Payments from transaction operations or contract invocations on Stellar network can be monitored by leveraging the unified events model as of Protocol 23 (Whisk) and the RPC getEvents method.
    • Payments are ‘transfer’ events: the unified events model ensures whether a payment happened through an operation or contract invocation it will result in the same ‘transfer’ event being emitted.
    • Event Type: "contract" denotes payments are an application level event rather than ‘system’ event.
    • Transfer Topics Model: an array of four topics, specified in CAP-67 and summarized:
      • topic[0] = Event name ‘transfer’ determines the next 3 topics
      • topic[1] = Transfer Sender address
      • topic[2] = Transfer Recipient address
      • topic[3] = Asset identifier (only present for Stellar Assets, through their built-in contracts (SAC))
  • RPC provides precise filtering of Stellar network events and this includes event topics model defined for unified events in CAP-67. You save time by using the RPC server-side filter capabilities to focus on processing only events relative to your application such as payments from a specific account in this example.
    • Wildcards: The RPC getEvents allows to use ”*” to match any value in a topic position
    • Server-side Filtering: RPC getEvents applies the filters and only matching events are returned, reducing bandwidth
    • Cursor-based Pagination: RPC getEvents retrieves event data efficiently with a paging mechanism