> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useroutr.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How it works

> The path from a funding intent to a credit, and what Useroutr guarantees along it.

Every flow starts with a **funding intent**: your application's request to receive a specific
amount of a specific asset at a specific destination. Everything else exists to fulfil it.

<Steps>
  <Step title="You create a funding intent">
    Your server asks for, say, 25 USDC on Stellar, delivered to your account. Useroutr creates a
    deposit account for this intent alone and registers the intent on its Soroban protocol.
  </Step>

  <Step title="Your user chooses how to pay">
    If they hold the asset you asked for, they pay it directly. If they hold something else, a
    [quote](/concepts/quotes-and-routes) prices the route: how much of their asset covers your
    requirement, and how it gets converted.
  </Step>

  <Step title="Useroutr watches for the payment">
    The payment lands in the intent's deposit account, so no memo is needed. Useroutr verifies
    the asset and amount on chain. A partial payment waits for the rest; an overpayment is
    refunded.
  </Step>

  <Step title="The payment is settled and reconciled">
    The value moves to your destination through the Useroutr settlement contract. Useroutr then
    checks the chain against its own records, field by field.
  </Step>

  <Step title="Your ledger is credited and you are told">
    One credit is posted to your application's ledger, the intent becomes `CREDITED`, and a
    signed `funding.credited` webhook reaches your server.
  </Step>
</Steps>

## What you can rely on

<AccordionGroup>
  <Accordion title="One successful intent, one credit" icon="circle-check">
    A funding intent produces exactly one credit. This is enforced by unique constraints in the
    database, not only by application checks, and reconciliation flags any drift. Replayed
    webhooks, retried jobs and repeated API calls cannot create a second credit.
  </Accordion>

  <Accordion title="Nothing is credited on a promise" icon="shield-check">
    A transaction hash is evidence, not completion. Useroutr credits only after the payment is
    verified on chain and the settlement is confirmed and reconciled.
  </Accordion>

  <Accordion title="Your funds, your account" icon="wallet">
    Useroutr holds no balances for you. Settled value goes to your own destination account; your
    Useroutr balance is the accounting record of what has arrived there.
  </Accordion>

  <Accordion title="Assets are exact" icon="coins">
    An asset is identified by its network and, on Stellar, its issuer, never by its symbol alone.
    USDC from one issuer is never mistaken for another.
  </Accordion>
</AccordionGroup>

## Where the work happens

| Part | Where | What it does |
| - | - | - |
| Your server | The SDK or the API, with your API key | Creates funding intents, reads state, receives webhooks |
| Your user | Hosted page, embedded checkout or your own screens | Chooses an asset and pays |
| Useroutr | API, workers and the Soroban protocol | Quotes, detects, settles, reconciles, credits, notifies |
| Stellar | Testnet in the sandbox, mainnet in production | Carries the payment and the settlement |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.