1
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.
2
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 prices the route: how much of their asset covers your
requirement, and how it gets converted.
3
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.
4
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.
5
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.What you can rely on
One successful intent, one credit
One successful intent, one credit
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.
Nothing is credited on a promise
Nothing is credited on a promise
A transaction hash is evidence, not completion. Useroutr credits only after the payment is
verified on chain and the settlement is confirmed and reconciled.
Your funds, your account
Your funds, your account
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.
Assets are exact
Assets are exact
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.