How it works

From a bill to a receipt, and what is real today

Settle is meant to let a supporter fund part or all of a bill, paid straight to the provider on Stellar. This page walks the whole flow and says plainly which steps exist.
Testnet prototype
No real funds move. The app uses sample data, and mainnet is not enabled. The status labels below describe what you experience in the app at this version.

How to read the labels

  • Built
    The code exists and does what the step says.
  • Simulated
    The app shows this step with sample data. Nothing real happens.
  • Not built
    Planned or required before any live use. It does not exist yet.

The flow, step by step

  • 1

    A requester chooses a bill

    Built
    In the app
    The requester picks a photo or PDF with the system picker, or tries a built-in demo bill. The file is previewed on the device. It is not uploaded anywhere.
    In the repositories
    Nothing in the app sends the picked file over the network. An evidence service exists separately in settle-api, but the app does not call it.
  • 2

    Review and redaction

    Simulated
    In the app
    A timer runs a scripted review and shows sample extracted fields (provider, amount, due date, account) with redaction toggles. No model reads your file.
    In the repositories
    settle-api has encrypted local quarantine, a restricted manual review step, an allowlisted redacted summary, an audit log and retention purge. Automated redaction, malware scanning, individual reviewer authorization and authenticated client upload are not built.
  • 3

    A supporter chooses how much to fund

    Simulated
    In the app
    A supporter swipes through sample bills and picks a custom, partial or full amount, with an optional Kind Gesture. The bills and people are sample data, and choosing an amount creates no payment.
    In the repositories
    There is no real bill or provider directory behind the sample bills.
  • 4

    Quote with an unsigned payment

    Simulated
    In the app
    The public demo build shows a simulated preview and requests no quote. A build configured with a settlement API URL asks the API for a quote and shows the amount, the fixture exchange rate, the network fee and the expiry before you sign.
    In the repositories
    settle-api is a separate repository and a testnet reference implementation: it returns an expiring, fee-disclosed quote and an unsigned transaction from fixture providers and fixture rates. It has no authentication, no real provider directory and no real rate source. The app has a client for it that only runs when a settlement API URL is configured at build time.
  • 5

    The wallet signs

    Simulated
    In the app
    In the public demo build nothing is signed. In a build configured with a settlement API URL, desktop web asks the Freighter extension to sign the exact transaction the API built, and the app refuses a transaction that differs. On iOS and Android the wallet is reported as unavailable.
    In the repositories
    A wallet adapter exists for Freighter on web. It is designed to sign only the exact transaction the settlement API produced. Mobile wallet signing is not built.
  • 6

    The network confirms

    Simulated
    In the app
    In the public demo build there is no payment to watch. In a configured testnet build the app asks the settlement API to confirm, and shows success only when the API has re-read the transaction from the network and matched it to the quote.
    In the repositories
    The settle-api reference re-reads a submitted testnet transaction from the network and compares it to the quote before treating it as confirmed. A production confirmation observer and indexer are not built.
  • 7

    A receipt

    Simulated
    In the app
    In the public demo build, a preview ends with a "payment preview saved" screen that has no transaction behind it. In a configured testnet build the app shows the receipt id, a Stellar Expert testnet link and the receipt JSON.
    In the repositories
    The settle-api reference keeps an append-only, hash-chained receipt ledger on testnet. Provider reconciliation and a production receipt indexer are not built.

What stays out of the app by design

  • The app never holds a signing key and never builds a transaction.
  • The app does not choose the destination, the asset issuer, the exchange rate or the fee. The settlement API decides them.
  • A payment is not called settled until the network confirms it independently.
The settlement API is a separate project, settle-api, with an API contract and a threat model. The readiness guide lists what must exist before any mainnet decision.

Not built yet

  • Mainnet settlement. Mainnet is not enabled in any build of Settle.
  • A real provider directory and a real exchange-rate source.
  • Authentication for the settlement API.
  • Mobile wallet signing on iOS and Android.
  • A production confirmation observer, receipt indexer and provider reconciliation.
  • Automated redaction, malware scanning and authenticated bill upload.
  • Fraud controls, disputes and refunds, monitoring and an incident runbook.
  • Legal and compliance review for any operating jurisdiction.
Questions about any of this are answered on the FAQ. The rules for requesters and supporters are on the Guidelines page.