402flowPaid API governance for agents
View SDKTry Demo

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.

View SDKTry DemoSee how it works
  • 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
  • Control-plane investigation and triage for exceptions and failed requests
  • 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

Review if needed

Requests that fall outside policy stop for operator review and possible policy adjustment instead of failing silently or spending automatically.

04

Execute

Requests that satisfy current policy 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 and smart.

When the model needs to decide what to send, give it the inspect-then-execute loop so it can shape the right request instead of hardcoding parameters in the host.

  • Canonical three-tool contract backed by a preparedId
  • Hints and validation issues help the agent shape the right request parameters
  • nextAction stays authoritative before execution

The agent-driven path matters when the model has to achieve a specific outcome: merchant-published hints and validation issues help it choose the right parameters for the result it is trying to get, and the authoritative next action tells the host when execution is allowed.

AgentHarness quickstartOpen repo
import {
  AgentHarness,
  AgentPayClient,
  defaultHarnessInstructions,
  defaultHarnessToolSpecs,
} 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 harness = new AgentHarness({ client });

console.log(defaultHarnessInstructions);
console.log(defaultHarnessToolSpecs.map((spec) => spec.name));
// [ 'prepare_paid_request', 'execute_prepared_request', 'get_execution_result' ]

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 demo

Public SDK

The public SDK gives developers a small integration surface. Start from the public package, examples, and harness flows instead of building payment handling into every host.

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:evm:base-sepolia:usdc
  • x402:evm:base-mainnet:usdc
  • x402:solana:solana-devnet:usdc
  • x402:solana:solana-mainnet:usdc

Final CTA

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 SDKTry Demo