Control before money moves

One simple way for agents to call paid APIs.

Let agents call paid APIs without losing control. 402flow keeps policy, payment exceptions, and receipt finality in the control plane instead of scattering them across agent hosts.

View SDK Try Demo See how it works

Policy checks before execution
Observed-only merchant discovery
Onchain receipt finality
Deterministic multi-rail routing

control plane · paid request

Request

research brief

Agent sends a paid request through the control plane with a topic, audience, and format.

merchantdemo

railx402:solana-mainnet:usdc

Policy gate

allowed

merchant allowlist matched
budget remaining inside threshold
receipt persistence required

Execution timeline

preparerequest shaped
governpolicy decision issued
executeadapter paid request
receiptprovisional receipt issued

Operator view

policyallow: org posture satisfied

attemptpayment settled via adapter

receiptprovisional receipt id persisted

observeronchain finality still tracking

x402 base-sepolia usdc
x402 base-mainnet usdc
x402 solana-devnet usdc
x402 solana-mainnet usdc

What changes once payment is involved

Two ways to handle a paid request.

Agents can already discover tools and call APIs. The hard part starts when the endpoint requires payment, policy, and durable settlement truth afterward. The difference is whether policy, receipts, and onchain finality are first-class — before and after execution.

Direct paid request

More payment logic in the agent runtime

The application detects a paid endpoint, decides whether to proceed, and owns the protocol-specific payment path inline.

Payment logic and merchant quirks spread through app code
Observed-only discovery and policy denials turn into side channels
Rail selection, receipts, and retries are inconsistent across hosts

402flow-mediated request

Control before money moves

The agent prepares the request once, and 402flow evaluates policy, keeps unconfigured merchants visible as observed-only when posture allows it, chooses a compatible rail, and stores the result.

One SDK surface for developers instead of protocol branching
Operator-selected posture, observed-only discovery, and policy review events
Deterministic rail selection plus normalized receipts and audit history

For both sides

One control plane. Two audiences.

Operators get visibility and policy. Developers get a small integration surface. Both lean on the same governed execution path.

Default org posture

allow and monitorAdopt fast, refine from live traffic

Allow paid requests by default, discover merchants from live traffic, and use reporting, monitoring, and follow-up controls to refine governance over time.

deny by defaultWiden access deliberately

Block paid requests unless org, agent, or merchant policies explicitly allow them, using review and policy updates to widen access deliberately.

Keep payment decisions visible.

Operators need more than a payment success signal. They need an org posture, merchant discovery, policy review, and a record of what happened after execution.

Default allow-and-monitor or deny-by-default org posture
Observed-only merchant discovery from live paid traffic
Promotion of discovered merchants into Setup when governance should become explicit
Per-agent and per-merchant policy refinement
Policy review events when requests are denied
Deterministic wallet-order rail selection
Control-plane investigation and triage for exceptions and failed requests
Reporting, receipts, and audit visibility after execution

Start with an organization-wide default. Teams that want adoption fast can allow paid requests and tighten policy from live traffic. Teams that need strict control can block by default and widen access through org, agent, merchant policy, and review.

How it works

Prepare. Govern. Execute. Receipt.

Keep the developer surface small. Move payment orchestration and decision-making into the control plane.

Prepare

The agent issues a paid request through a small SDK surface instead of embedding protocol mechanics in the application.

Govern

402flow checks organization posture, policy, merchant constraints, and spend limits before execution.

Discover or deny

Under Default allow and monitor, unconfigured merchants remain observed-only until the org promotes them into Setup. Requests outside policy are denied before execution and create policy review events.

Execute

Requests that satisfy policy move through the payment adapter. When a merchant advertises multiple compatible rails, 402flow uses the Org's preferred wallet to choose deterministically.

Receipt

402flow stores the receipt, decision history, and audit context immediately, then lets the chain observer promote provisional receipts to confirmed once the finality rule is satisfied onchain.

Proof

Built for real paid-request flows.

402flow is not a slideware abstraction. It is a working control plane and SDK for governed paid API execution.

Hosted demo

Try a real paid-request flow end to end on the hosted demo, then inspect observed-only merchants, provisional receipts, and later chain-observer confirmation before you integrate 402flow into your own stack.

Try demo

Public SDK

The public SDK gives developers a small integration surface. Start from the public package, examples, and harness flows while the control plane and chain observer own policy and receipt finality.

View SDK

Current rails

x402 support is live across Base Sepolia, Base mainnet, Solana devnet, and Solana mainnet. L402 and MPP remain on the roadmap.

x402 base-sepolia usdc
x402 base-mainnet usdc
x402 solana-devnet usdc
x402 solana-mainnet usdc

Next step

Put a control plane between agents and paid execution.

If agents are going to buy APIs, data, compute, and services, the payment path needs policy and operator visibility. 402flow gives teams a simpler integration path and a safer execution model.

View SDK Try Demo