Skip to main content
A funding intent is your application’s request to receive an exact amount of an exact asset at an exact destination. It is registered on the Useroutr Soroban protocol when you create it, and it only ever moves forward through a fixed lifecycle.

Create one

string
required
A positive decimal string within the asset’s precision, for example "25" or "12.5". Never a float.
string
required
An asset id from useroutr.assets.list(), such as asset_usdc_stellar. See Assets and networks.
object
Where the value settles: { network, asset, address }. Defaults to your application’s default destination. It must be on the asset’s own network and for the same asset. A Stellar account must already exist and, for an issued asset such as USDC, hold a trustline for it; otherwise the request is refused with INVALID_DESTINATION rather than taking a payment that could not be delivered.
string
Your own id, up to 255 characters, returned unchanged. Your order id is a good choice.
object
Up to 50 keys of strings, numbers, booleans or null, returned unchanged.
string
ISO 8601. Defaults to 30 minutes from now, at most 24 hours.
The idempotency key is required. The same key with the same body returns the original intent; the same key with a different body is refused. See Idempotency.

Lifecycle

PAYMENT_DETECTED and ROUTING happen inside the steps that confirm a payment and create a settlement, so you never observe them. CANCELLED, REFUND_PENDING and REFUNDED are defined for flows that are not live yet; no intent reaches them today.
Fulfil orders on CREDITED, never earlier. It is the only status that means the value is yours.

Funding instructions

Every intent gets a deposit account: a Stellar account Useroutr creates for that intent alone. It is not your destination; your destination receives the value once the payment settles. While the intent is AWAITING_PAYMENT or PARTIALLY_FUNDED, funding_instructions tells your user exactly what to send:
No memo is needed: the address alone identifies the intent.

Partial payments and overpayments

Payments add up. A smaller payment moves the intent to PARTIALLY_FUNDED and the instructions ask for the remainder. Once the total reaches the amount, the intent is PAYMENT_CONFIRMED. Anything above the amount is never credited. It is recorded as a refund with reason OVERPAYMENT and paid back to the payer. Payments that do not match, such as the wrong asset or a payment after expiry, are recorded as rejected and fire payment.rejected, and the intent keeps waiting. See Refunds.

Read

The intent carries its payment and settlement once they exist, hosted_funding_url for the payer, and while a quote is locked, its source, quote and route.