Request
research brief
Agent proposes a paid POST to the hosted demo merchant with a topic, audience, and format.
Control before money moves
One simple way for agents to call paid APIs.
Let agents call paid APIs without losing control. 402flow puts policy, approvals, receipts, and spend controls in the path before execution.
- Policy checks before execution
- Approval workflow when spend needs review
- Receipts and audit trail stored centrally
- Hosted demo merchant and public SDK
Problem
Paid execution changes the risk profile.
Agents can already discover tools and call APIs. The hard part starts when the endpoint requires payment, approval, and durable evidence afterward.
Payment logic leaks into the runtime
Without a control plane, each agent host starts owning protocol branching, idempotency, retries, and merchant-specific request behavior.
Approvals turn into ad hoc process
Requests that should stop for human review either fail late or spend automatically because there is no dedicated approval path before execution.
Receipts and evidence get fragmented
Operators need more than a success signal. They need durable receipts, denial reasons, merchant visibility, and audit context after the request completes.
Before / After
Two ways to handle a paid request.
The difference is not whether money moves. The difference is whether policy, approvals, and receipts 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
- Approvals become side channels instead of productized review
- Receipts, denials, and retries are inconsistent across hosts
402flow-mediated request
Control before money moves
The agent prepares the request once, and 402flow evaluates policy, routes review when needed, executes through the payment adapter, and stores the result.
- One SDK surface for developers instead of protocol branching
- Operator-selected governance posture and review path
- Normalized receipts and audit history after execution
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.
For operators
Keep payment decisions visible.
Operators need more than a payment success signal. They need an org posture, merchant discovery, approval routing, and a record of what happened after execution.
- Default allow-and-monitor or deny-by-default org posture
- Merchant discovery from live paid traffic
- Per-agent and per-merchant policy refinement
- Reporting, review, and receipt visibility after settlement
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.
01
Prepare
The agent issues a paid request through a small SDK surface instead of embedding protocol mechanics directly in the application.
02
Govern
402flow evaluates the request against organization posture, policy, merchant constraints, and spend limits before execution is allowed.
03
Approve if needed
Requests that fall outside policy stop for human review instead of failing silently or spending automatically.
04
Execute
Approved requests move through the supported payment rail with protocol-specific handling kept behind adapters.
05
Receipt
402flow stores the normalized receipt, decision history, and audit context so operators can understand what happened after the request completes.
For agent developers
Keep the integration small.
Developers should not have to embed payment orchestration, approval routing, and receipt handling into every agent runtime.
- One client surface for paid requests
- No x402 details leaking through the runtime
- Hosted demo route for end-to-end proving
Write the paid request once. Let the control plane handle policy, execution, and receipts around it.
SDK quickstartOpen repo
import { AgentPayClient, createJsonRequestBody } from '@402flow/sdk';
const client = new AgentPayClient({
controlPlaneBaseUrl: 'https://api.402flow.ai',
organization: 'acme-labs',
agent: 'research-worker',
auth: {
type: 'bootstrapKey',
bootstrapKey: process.env.X402FLOW_BOOTSTRAP_KEY ?? '',
},
});
const result = await client.fetchPaid(
'https://demo-merchant.402flow.ai/demo-merchant/research-brief/solana-devnet',
{
method: 'POST',
headers: {
'content-type': 'application/json',
},
body: createJsonRequestBody({
topic: 'sdk integration rollout',
audience: 'platform engineers',
format: 'bullets',
}),
},
{
description: 'generate a staged research brief',
idempotencyKey: 'site-homepage-example',
},
);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 merchant
A separate first-party merchant surface for exercising real paid-request flows without turning the marketing site into the demo environment.
Try demoPublic SDK
The developer wedge is a small SDK surface. Start from the public package, examples, and harness flows instead of building payment handling into every host.
View SDKCurrent rails
x402 support is live across Base Sepolia, Base mainnet, Solana devnet, and Solana mainnet. L402 and MPP remain on the roadmap.
- x402:evm:base-sepolia:usdc
- x402:evm:base-mainnet:usdc
- x402:solana:solana-devnet:usdc
- x402:solana:solana-mainnet:usdc