Do I need Agent Payments or StableOps collection?

Choose the buyer-side Agent Payments control plane, the seller-side StableOps collection stack, or both without mixing their credentials and state.

Use Agent Payments when your Agent is the buyer. Use StableOps Payment Orders or hosted Checkout when your application is the seller. They solve different control problems and neither one requires the other.

At a glance

	Agent Payments	StableOps collection
Controls	How an Agent is allowed to spend	How a merchant accepts and reconciles funds
Starts with	An Agent requesting an x402 paid resource	A merchant creating a Payment Order or Checkout Session
Main credentials	Management API Key, restricted Agent Key, and signer credentials	Merchant API Key and Webhook signing secret
Wallet relationship	Pays from a customer-controlled wallet through a constrained signer	Receives into merchant-controlled addresses
Main state	Policy, approval, authorization, settlement, and resource result	Order matching, detection, confirmation, finality, and expiration
Source of truth	Agent Payment record plus signed `agent_payment.*` events	Payment Order plus signed payment events

Agent Payments does not turn an Agent into a merchant, and a Payment Order does not give an Agent permission to spend.

Choose Agent Payments when the Agent is buying

Agent Payments belongs on the buyer side when an autonomous program needs to purchase an x402 resource without receiving unrestricted wallet authority. The operator configures:

allowed resource origins and recipients;
per-payment and daily limits;
when a human must approve;
the wallet and customer-hosted signer the Agent may use; and
a restricted Agent Key for that one Agent runtime.

The Agent SDK reads the seller's 402 challenge, asks the StableOps control plane for authorization, obtains a constrained signature from your signer, and retries the resource request. See the Agent Payments introduction for the current protocol and network scope.

Choose collection when your application is selling

Use Payment Orders when your application needs to assign a transfer to a business order, detect it onchain, wait for the required finality, and reconcile it through Webhooks. Use hosted Checkout when you also want StableOps to provide the payer-facing payment page.

Collection is non-custodial: funds arrive at addresses the merchant controls. It does not depend on the payer using Agent Payments or even on the payer being an Agent.

Use both when you operate both sides

If you operate an Agent buyer and an x402 seller, the two products can describe the same economic payment from separate trust boundaries:

The seller creates a Payment Order and binds its exact address, network, asset, and atomic amount into the x402 payment requirement.
The buyer's Agent Payments policy decides whether the Agent may accept that requirement.
The Agent's customer-hosted signer signs the authorized payment.
The seller's Payment Order independently detects and finalizes the matching onchain transfer.

Keep the records connected in your own business data by storing the buyer task ID, Agent Payment Intent ID, seller Payment Order ID, and transaction reference. Do not reuse API keys, Webhook secrets, state machines, or idempotency keys across the buyer and seller domains.

An x402 paid response answers whether the buyer's HTTP exchange completed. A seller-side payment.finalized event answers whether the merchant's matching transfer reached its configured finality boundary. Treat them as related evidence, not as interchangeable states.

Can only one side use StableOps?

Yes.

An Agent Payments customer can buy from a compatible x402 seller that uses another merchant stack.
A StableOps merchant can collect from a buyer that uses another x402 client or an ordinary wallet flow.
If both sides use StableOps, each organization and environment still has separate credentials, policies, records, and operational responsibilities.