Agent Payments

Agent Payments is StableOps's payment control layer for Agents. An operator registers payment wallets, activates immutable spending policies, sets budgets, and issues a restricted Agent Key. The Agent runtime can purchase paid resources only within those boundaries.

How one payment completes

1. The Agent SDK requests a paid resource and reads its x402 402 payment requirements.
2. The StableOps control plane validates origin, recipient, network, asset, amount, policy, and both daily budgets.
3. If a human decision is required, the Intent waits for approval and later resumes with the same Intent.
4. A customer-hosted signer sidecar validates the short-lived execution grant before signing with a local key or AWS KMS.
5. The Agent SDK retries the original resource with the payment credential while the control plane reconciles resource and onchain settlement states.

Trust boundaries

• The Agent runtime holds only a restricted Agent Key and sidecar token. It cannot change wallets, policies, budgets, or approvals.
• The signer signs only typed data that exactly matches a StableOps execution grant; it exposes no arbitrary signing interface.
• Wallet private keys and KMS permissions stay in the customer environment.
• StableOps does not proxy business requests, broadcast payment transactions, or hold customer private keys.
• Payment state and resource state are tracked separately; receiving a resource does not prove settlement.

Packages

Supported scope

• Server-side Node.js 20 or later; no browser or edge runtime support.
• x402 v2 exact, GET, and HTTPS paid resources.
• The asset is limited to the configured USDC below. TRON mainnet and Nile are excluded for now.
• Sandbox accepts testnets only, while Live accepts mainnets only. Live is disabled by default and is enabled by StableOps after the organization completes its risk and recovery-drill gates.

Sandbox and Live network boundaries are independently enforced when creating policies, registering wallets, creating intents, and issuing authorizations. A caller cannot cross environments by constructing a custom request.

Live networks

Sandbox networks

BNB Smart Chain uses Binance-Peg USDC, while its testnet uses a community-pegged test token; neither should be described as Circle-issued USDC.

Signers and gas

• EIP-3009 networks use LocalTestSigner in Sandbox and AwsKmsSigner in Live. The x402 facilitator submits the payment transaction, so the payer wallet does not need native tokens for each payment.
• Permit2 networks use the local EVM test signer in Sandbox and AWS KMS in Live. The payer wallet must first approve the canonical Permit2 contract (0x000000000022D473030F116dDEE9F6B43aC78BA3) to spend USDC. Approve only the allowance required by your treasury policy and verify the chain, token, spender, and amount before broadcasting. The wallet needs the network's native token for this approval's gas; the facilitator still submits subsequent x402 payments.
• Solana uses LocalSvmSigner. The facilitator fee payer covers transaction fees, so the payment wallet does not need SOL for x402 payments.
• AwsKmsSigner supports EVM networks only. A Solana private key remains in the customer environment and is used by LocalSvmSigner.

Amount units

Payment quotes, approvals, and receipts use the token decimals shown above. Policies and budgets always use a six-decimal USDC budget unit, where 1000000 means 1 USDC. On BNB Smart Chain, a 1 USDC payment amount is 1000000000000000000, while the corresponding policy limit remains 1000000.

Move from Sandbox to Live

Sandbox and Live are isolated environments. Do not reuse Sandbox Agents, Agent Keys, wallets, policies, budgets, signer instances, authorization stores, or idempotency keys in Live.

Before the first mainnet payment:

1. Complete StableOps's organization risk review and recovery drill, then confirm Live is enabled with a healthy recipient-screening path.
2. Create a Live Agent Payments management API key and new Live Agent. Register and bind a dedicated wallet on the exact mainnet.
3. Recreate the policy and budgets using the six-decimal budget unit. Pin the production resource origin, recipient, network, and USDC contract from the tables above.
4. Configure the signer with environment: 'LIVE' and that mainnet's exact CAIP-2 identifier. Use a separate durable authorization store per signer instance.
5. For BNB Smart Chain, verify the Permit2 allowance and native-token gas balance. For every network, verify the wallet's USDC balance independently.
6. Start with a deliberately small canary payment that requires human approval. Confirm the paid resource response, StableOps payment and receipt, signed Webhook, facilitator settlement, and wallet balance before enabling automatic payments.

An ak_sandbox_... Agent Key cannot access Live; issue and securely store a new ak_live_... key. A 403 mainnet-risk response means the organization has not completed activation. A 503 risk-screening response must fail closed and be escalated; do not retry by creating a second Intent.

Where to start

• To inspect a real 402 challenge, open the online x402 test.
• To complete your first controlled payment, follow the quickstart.
• After the basic flow, continue with the management SDK, signer, and Webhooks.