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 sends the intended HTTP method and body to 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 a payment payload or prepared transaction 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 over HTTPS with GET, POST, PUT, PATCH, or DELETE. Non-GET request bodies are sent directly by the Agent SDK. StableOps stores only their SHA-256 digest and content type.
• 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.

Use Base Sepolia for your first Sandbox payment and Base for your first Live payment. Other x402 services may charge on different networks. Before choosing a network marked Confirm before use, check that the paid service offers the exact network and USDC shown below, then complete a small payment with human approval before enabling automatic payments.

Live networks

Sandbox networks

If a paid service charges on BNB Smart Chain, confirm that it accepts the asset shown below and complete the required Permit2 approval first. The mainnet asset is Binance-Peg USDC and the testnet asset is a community-pegged test token; neither is Circle-issued USDC.

Signers and gas

• EVM networks use LocalTestSigner in Sandbox and AwsKmsSigner in Live, regardless of whether the payment method is EIP-3009 or Permit2. AwsKmsSigner supports EVM networks only.
• For EIP-3009, the x402 facilitator submits the payment transaction, so the payer wallet does not need native tokens for each payment.
• For Permit2, 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 in both Sandbox and Live. The Solana private key must remain in the customer environment. The facilitator fee payer covers transaction fees, so the payment wallet does not need SOL for x402 payments.

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. As an advanced-network example, BNB Smart Chain represents a 1 USDC payment as 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 network accepted by the paid service. Start with Base unless the service requires another network and your small test payment has succeeded.
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.