# Run payments with a durable worker

Documentation revision **2026-09-25**. Unattended execution is application-owned scheduling and signing of an already authorized payment. **Auto-route is optional discovery and ranking**, charged at 4× standard comparison/completion credits; it does not own a wallet, grant spending permission or run an unrestricted payment agent. Ordinary routing can also be automated. See [pricing](usage-and-billing.md) and [Auto-route](auto-route.md).

Use the [normalized next-action API and explicit-operation SDK](next-actions.md) to decide each worker step. It does not schedule, sign, submit or retry on its own; retain the durable operation record described below.

## Establish authority first

Your application controls the signer: a customer wallet supplies individual signatures, or an explicitly authorized backend/HSM signer enforces recipient, asset, amount, network and fee limits. Keep Route credentials on the backend and signing keys inside your signing system. Route builds and verifies actions and submits the exact signed transaction; it never needs the customer's private key.

A background worker cannot sign for a disconnected customer wallet unless your application already has appropriate authorization and a supported signer. A saved payment intent signature alone cannot authorize a transfer. Do not infer permission to increase a fee cap, change a recipient or execute another leg from an earlier quote.

## Worker recipe

1. **Save the business order.** Assign one unique order ID and persist the network, source/destination asset IDs, sender, recipient, amount, selected policy, fee ceiling, quote request key and payment creation key before sending requests. Enforce a unique order-to-payment mapping in your database.
2. **Check compatibility and choose a route.** Discover exact assets and live capabilities, compare candidates, and follow the [next-action table](/docs/#next-action). A provisional gas estimate permits only wallet preparation where explicitly advertised. It does not authorize signing.
3. **Prepare once.** Save each endpoint/body/key before sending it. NEAR preparation can allocate deposit instructions; a timeout requires reconciliation of that preparation, not another allocation. Protocol preparation can return a token approval before the transfer.
4. **Handle the actual authorization.** For NEAR, obtain and verify the wallet intent approval before requesting its transaction. For protocols, register the exact action directly. Validate every action against the immutable order and current checks before your signer signs. A token approval can consume gas but is not the payment.
5. **Persist before submitting.** Store the authorization ID and pending signature/submission operation. Send the exact signature to Route, read its state, and execute only when current flags allow it. If the response is lost, read the saved authorization before retrying; never call a wallet's broadcast function as a fallback.
6. **Continue after approval.** One successful canonical EVM approval block allows the next action when Route reports `canContinue: true` (testnet `approval_confirmed`). Get the current preparation/payment version and fresh transfer terms. Already-approved senders skip unnecessary approval actions.
7. **Detect and track funding.** Use saved payment reads and controlled refreshes. NEAR provider recognition, canonical source inclusion, destination delivery and final completion are distinct observations. A provider's deposit address balance alone is not sufficient receipt evidence. Deduplicate enabled webhooks, then reread current state. Without webhook delivery, poll with [backoff](recovery.md#polling-and-retry-schedule).
8. **Handle destination work.** Managed Circle-to-Stellar minting requires no destination customer signature; track the same source message. Customer-funded minting needs the approved destination signer and XLM. Other providers have their own relay mechanisms. Destination failure never automatically authorizes another source transfer.
9. **For a composed payment, finish one leg before advancing.** Wait for verified finalized intermediate settlement, reconcile actual received assets, obtain the next supported quote and authorize that leg. Keep enough native gas in the intermediate wallet. The current API does not offer a universal gas station, atomic two-leg execution or native Bitcoin intermediate custody. See [composed payments](composed-payments.md).
10. **Commit completion once.** Use verified payment completion to settle your business order; record delivery earlier as a separate observation if exposed. Deduplicate completion events and credit accounting. Keep unresolved payments in a recoverable queue with their original evidence.

## Pause conditions

Stop automated signing or submission on unknown future states, changed identity/recipient, policy/version conflicts, unavailable execution, failed or unknown mandatory checks, expired signed reviews, signer uncertainty, changed wallet slots, or ambiguous submission. Continue safe tracking of an existing transaction when appropriate. Reconcile the same payment using the [recovery playbook](recovery.md); do not “retry” by creating and funding another payment.

Use a database transaction, durable operation log and per-order lease to prevent concurrent workers. A restart should recover the pending operation before reading a new job. At-most-once Route submission covers Route's recorded broadcast attempt; it is not a guarantee that external wallet software cannot send the signed bytes or that a chain will include them.

The [testnet starter](payment-starter.md) demonstrates the durable sequence with a private file store and an explicitly authorized test signer. It is a reference implementation, not a production custody service or hosted workflow scheduler.