Skip to main content
Three payment primitives beyond the interactive SEP-24 ramp. All are Stellar-only.

Direct anchor-to-anchor payments (SEP-31)

StellarDirectPaymentProvider implements the same RampProvider interface as StellarAnchorProvider, so it works through the existing RampManager API. The flow has no interactive step:
  1. SEP-10: authenticates the sending account, or uses a pre-obtained authToken.
  2. SEP-12: registers the receiver with the receiving anchor, using fields derived from payoutAccount (bank or mobile money) plus any anchor-specific receiverFields.
  3. SEP-31: POST /transactions with your senderId and the new receiver_id.
  4. On-chain leg: with autoPay (the default), pays the anchor’s stellar_account_id with its memo via Horizon. With autoPay: false, it returns paymentInstructions so you can pay from your own custody, or from a ramp-settlement deposit.
  5. getStatus(id) polls GET /transactions/:id and maps SEP-31 statuses to RampSessionStatus.
SEP-31 is send-side only, so pair it with an interactive provider for deposits:
Declarative selection works too: createRampProvider({ provider: "stellar-sep31", homeDomain, senderId }, { stellarSigner }).
Receiving anchors differ in which SEP-12 fields they require. Check the anchor’s GET /info and supply extras with receiverFields. Test against the anchor’s testnet before going live.

payment-stream: streaming and vesting

One deployment serves any number of streams in any SEP-41 token. There’s no admin. Each stream is controlled only by its sender and recipient.
  • Linear: per-second release from start to end, with an optional cliff. Nothing can be claimed before the cliff. At the cliff, everything accrued since start unlocks.
  • Tranches: discrete installments (up to 48), each unlocking at its own time.
  • Cancel (only for streams created cancelable): the vested-but-unclaimed amount goes to the recipient and the unvested remainder goes back to the sender.

batch-disburser: payroll and distributions

A stateless contract with no custody and no admin. disburse(payer, token, payments, reference) transfers straight from the payer to each recipient, up to 100 per transaction. Each batch is atomic, and the token’s own identity-verifier and compliance checks still apply to every recipient. disburse_equal pays the same amount to a list of recipients.
From the CLI: ankara batch-pay --contract <DISBURSER> --token <USDC_SAC> --file payouts.csv.