Usage and payment reporting
Route separates transferred funds, provider/network fees and Route usage credits. Moving $100 does not mean consuming 100 credits.
Payment views#
The Payments page brings payment history, transaction evidence and recovery into one place. Its mainnet views are:
| View | Records shown |
|---|---|
| All | Every saved logical payment, including cancelled and archived records. |
| In progress | Preparation, wallet action, source/destination processing and receipt or finality checks. |
| Completed | Verified, finalized delivery on both networks. |
| Refunded | Verified, finalized source and refund receipts. |
| Needs attention | Failed source transfers, unresolved checks and intermediate funds waiting for the next transfer. |
| Drafts | Saved payments without a provider preparation. |
| Archived | Unused drafts retained for reference. |
Search applies to the selected view across its full history. Filtering happens before pagination. Exports contain the current page of that same filtered search. A two-step route appears once; its individual transfers remain available inside its details.
Open View payment for source, destination and refund hashes, receipt verification, the activity timeline, original quote estimates and available wallet or recovery actions. A signed transaction hash alone does not prove submission. Normal waiting belongs in In progress; Needs attention does not automatically mean funds were lost.
Refresh list reads saved status. The payment's Refresh payment status action requests a new provider/receipt check where available. Background tracking continues independently of the page. Opening a payment does not sign, submit or resend it. The page supports operational review; external accounting-statement matching is not provided.
Previous Transactions links open All payments, Settlements links open Completed (refunds have their own view), and Reconciliation links open Needs attention. Existing API payment and recovery endpoints are unchanged.
Total processed in USD#
Overview reports completed mainnet payments whose source and destination receipts have both been verified and finalized. A composed payment counts once, after every expected transfer completes. Its intermediate transfer is not added to volume a second time.
USD volume uses the source principal and a valid historical price captured with the funding action. It excludes drafts, pending transfers, testnet tokens and refunds. It does not assume a stablecoin is worth $1 or use today's market price to fill missing history. Completed payments without usable historical pricing remain in the completed count and appear separately as unpriced; they are excluded from the USD total.
The report is refreshed from saved chain evidence. It can briefly lag the payment view while reconciliation runs. It is an operational payment-volume measure, not a tax report or a measure of Route revenue.
Public Route explorer#
The Route explorer shows platform-wide processed volume and settled mainnet activity without sign-in. Filter its charts and network, provider, route and asset breakdowns by date, network or provider. Search settlement history by a public payment reference or transaction hash.
The explorer uses the same verified settlement accounting described above. Customer and workspace names, project identifiers, customer wallet addresses and internal accounting queues are not included. A public reference is distinct from the payment ID used by the customer API. Transaction hashes allow public on-chain verification. The all-time counter remains platform-wide when filters are applied to the analysis below it.
Pay-as-you-go credits#
Usage & Billing shows workspace usage, credit balance and recent activity across projects. Credit top-ups use native USDC on Stellar mainnet.
1 USDC buys 1,000 credits. Top-up packages are 5, 20 and 100 USDC, providing 5,000, 20,000 and 100,000 credits respectively. Credits have no expiry, subscription or automatic overage.
| Mainnet API operation | Credits |
|---|---|
| New comparison with at least one policy-eligible route | 1 |
| Verified completed logical payment | 10 |
| Auto-route comparison with an eligible recommendation | 4 |
| Verified completed Auto-route payment, including both legs | 40 |
| No eligible route, failed comparison or unsuccessful payment | 0 |
| Draft creation, wallet approvals, signing and internal refreshes | 0 |
| Reads, tracking, reconciliation and idempotent retries | 0 |
| Testnet, dashboard-origin work and catalog/account administration | 0 |
Standard pricing below is multiplied by four when the comparison explicitly opts into Auto-route. Auto-route reserves four credits per comparison and forty per prepared logical payment; its legs and internal refreshes are never charged separately. No eligible recommendation, a failed TypeSafe call or unclear intent releases the comparison reservation. Existing standard payments retain their pricing.
A standard quote comparison costs one credit regardless of how many adapters are queried. Candidates marked needs-data alone do not qualify. A composed payment costs ten credits once, after all expected transfers are verified complete. A successful quote charge remains if you later abandon its payment. Provider fees, network gas and destination sponsorship remain separate from Route credits.
Route reserves one credit before requesting a new mainnet API comparison, then spends it only when a policy-eligible result is saved. Failed or ineligible comparisons release it. Interrupted quote reservations expire after two minutes and are reclaimed by the background worker; a stale request cannot spend a renewed reservation. Retry the same input with the same Idempotency-Key to retrieve an existing result without another charge.
Preparing an API-origin payment reserves ten credits before Route issues funding instructions. This is a hold, not a preparation fee. Route spends the reserved credits only after verified, finalized delivery. A verified refund or conclusive first-source failure releases the hold. Reconciled NEAR attempts which issued no funding instructions or wallet action can also release it. An uncertain, signed or potentially funded payment retains its reservation until resolved; quote or review expiry alone does not release payment credits. SwapKit reserves with its channel claim, before /v3/swap is called, so a build that fails, has an unknown outcome or expires before deposit instructions are attached also keeps its hold. SwapKit's definite refusal (409 SWAPKIT_BUILD_REFUSED) proves no channel exists and releases the hold at once; a retry of /prepare reserves it again before calling SwapKit. A composed transfer with funds already at its intermediate destination retains the hold while recovery continues.
Billing shows Available credits, Reserved credits and Credits used this month separately. Credits are shared across all workspace projects and API keys. When the available balance is insufficient, new mainnet API quotes or preparations return HTTP 402 with INSUFFICIENT_CREDITS. Add credits in Billing and retry the same operation. Existing preparations, signatures, submission, tracking, refunds and reconciliation remain available at zero available balance. API-origin work remains billable when continued from the dashboard; work originally created in the dashboard is free.
Rates are frozen for each reserved operation. Payments already prepared before activation are not charged retroactively, including the remaining leg of a composed payment. If usage charging is paused, new operations reserve nothing, but operations already reserved are still charged at their frozen rate if they complete; Billing lists them with their rate version. Historical request logs do not become charges. Usage counts include free recorded quotes and drafts, so they are not the same as billed operations; the credit activity records show actual deductions. Recent activity lists the latest 50 entries.
Buying credits with USDC#
A workspace member with billing access can select Add credits, choose a package, and use Connect Freighter. Route fills in the native USDC amount, collection account and invoice reference automatically. Review the payment and maximum XLM network fee, select Pay with Freighter, then approve it in your wallet. Connecting the wallet alone does not authorize a payment.
Freighter must be set to Stellar mainnet. Your wallet needs enough native USDC and spendable XLM after its account reserve. Route checks the USDC trustlines, available funds, signing authority and current network fee before preparing and submitting the payment. The displayed XLM amount is a maximum fee budget; the network may charge less. This checkout supports a standard Stellar G account whose own key can authorize the payment. Multisignature accounts can use the manual option.
Pay manually from another wallet remains available before submission. It shows the exact amount, recipient and unique text memo to copy. Send one direct native-USDC payment, using memo type Text. The memo identifies the workspace invoice; a verified blockchain receipt confirms payment. Never make both a manual and a Freighter payment for the same invoice. Swaps, Soroban contract transfers, batched payments, other assets and other networks are not accepted for credit purchases. The sending wallet pays the network fee in XLM.
The accepted issuer is Circle's GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN; verify the official USDC asset identity. Never infer the token from its display name alone.
An invoice has a 30-minute payment window. Route checks the collection account in the background and credits the workspace only after verifying a successful Stellar mainnet transaction, its signed envelope and result, exact recipient, asset, amount, memo and ledger inclusion time. No customer private key is sent to Route. Fee-bump sponsorship is supported for an otherwise matching single payment.
Route submits only the exact transaction approved in Freighter. One saved transaction and one submission attempt are allowed per invoice, so duplicate clicks, repeated requests or a lost response cannot create a replacement transfer. A wallet or network change stops submission. Your private key stays in your wallet, and Route does not save the signed payment payload or gain permission to charge the wallet again.
You can close checkout and reopen the top-up from Billing. Its status refreshes while open; background verification continues independently. Check payment requests another verification; optionally provide the transaction hash for a direct lookup. Credits and the receipt commit together, and a transaction can fund only one invoice. Repeated checks cannot add credits again. Top-ups are separate from payment-processing volume and API usage.
If submission is uncertain, checkout shows verification in progress and removes the manual payment option. Do not send another payment. Reopen the invoice and check its saved transaction; contact support with that reference if it remains unresolved. A prepared payment keeps its original wallet, fee and sequence. If the wallet changes or its sequence is used elsewhere, Route does not silently rebuild or replace it.
An expired invoice must not receive a new payment. A payment included before expiry can still be credited when verified later. Automatic checks continue for up to 24 hours after expiry, less frequently after the payment window; direct hash verification remains available afterwards. Checkout shows when automatic checks end and says so once they have. A Freighter payment without a verified receipt shows Not confirmed once Stellar can no longer include it. Its payment reference is the transaction hash: paste it under Already paid? for a direct lookup, or contact support with it. Incorrect amounts, missing or incorrect memos, unsupported transaction types and late payments require support review with the transaction hash. Route does not automatically refund or re-send those funds. Do not send a second payment to repair an invoice.
At most three unpaid, unexpired invoices may be open per workspace. Billing displays the 20 most recent top-ups. Old invoice terms and verified receipts are retained when credit packages change.
Unused drafts#
Unused, unprepared standalone mainnet drafts are archived 24 hours after quote expiry. Use the Archived view to inspect them. Prepared, signed, submitted and uncertain payments are retained for tracking and reconciliation. Archival preserves saved evidence and retry history; it does not undo blockchain activity.
Use the customer API guide for pagination and manual archival.
A payment created in the dashboard from an API-key quote retains the quote's billing provenance. It reserves the same payment credits at preparation and charges once on verified completion. Dashboard-only quotes and payments remain unmetered. A canonically finalized source revert releases unused payment credits and rolling API-key spending capacity atomically. An uncertain submission or funds held at an intermediate step do not release those holds. The release does not deactivate a provider deposit address, so do not reuse it; see reservations and recovery.