402flowPaid API governance for agents
Live DemoTalk to us

Control before money moves

The control plane for AI agent spend

Let agents call paid APIs without losing control. 402flow enforces policy before money moves, tracks settlement and fulfillment separately, and records the receipts, decisions, and exceptions operators need after paid execution.

Request design partner accessView live demoSee how it works
  • Policy before spend
  • Onchain settlement visibility
  • Durable receipt ledger
  • Exception triage path

governed spend record

paid attempt after policy review

ready for operator review

Policy gate

allowed before spend
budget windowdaily agent cap
methodx402 usdc

Execution state

  1. settlementobserved
  2. receiptpersisted
  3. fulfillmentfailed
  4. exceptiontriage open

What 402flow records

policy decisionallow: merchant scoped budget matched
denial reasondaily agent cap exceeded
agentresearch-worker
merchantdemo-merchant
railx402:solana-mainnet:usdc
settlementobserved -> confirmed onchain
fulfillmentfailed after payment
receiptpersisted with transaction context
exceptionoperator review required

Agent spend changes the risk profile

Agent spend needs an operating layer.

Agents can discover, invoke, and pay for API services at runtime. Once money can move inside automated workflows, teams need policy before spend, evidence after spend, and a way to investigate failed paid execution.

Agents are starting to spend inside automated workflows

Once a model can discover, invoke, and pay for API services at runtime, the risk is no longer just whether a request can be executed. It is whether spend is governed before payment and traceable when something breaks.

Payment execution alone is not enough

Operators need policy decisions, denial reasons, spend limits, merchant context, settlement status, and receipt state in one control path instead of scattered across agent hosts.

Fulfillment failures need an evidence trail

Payment success is not the same as fulfillment success. When those states diverge, teams need the transaction context, policy decision, receipt, and exception history needed to investigate.

Before / after

Direct payment execution versus governed agent spend.

The request can move money in either model. The difference is whether policy, settlement, fulfillment, receipts, and exceptions stay coherent across agents and merchants.

Direct paid request

Payment logic spreads through the agent runtime

The application detects a paid endpoint, decides whether to proceed, executes payment inline, and has to reconcile settlement and fulfillment afterward.

  • Payment logic and merchant quirks spread through app code
  • Policy visibility, denial reasons, and budget context are limited
  • Payment and fulfillment failures are hard to reconcile
  • Operators lack a central view of agent spend

402flow-mediated request

Governed execution with evidence after payment

The agent prepares the request once. 402flow evaluates policy, chooses a compatible rail, tracks settlement and fulfillment separately, and records the result for operator review.

  • Policy enforced before spend
  • Receipts persisted after payment
  • Settlement and fulfillment tracked separately
  • Exceptions surfaced for review with transaction context

How it works

Prepare. Govern. Execute. Observe. Receipt. Triage.

Keep the developer surface small while the control plane owns policy before spend, settlement visibility after payment, and exception review when fulfillment fails.

01

Prepare

The agent shapes a paid request through a small SDK surface instead of embedding protocol mechanics throughout the host.

02

Govern

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

03

Execute

Requests that satisfy policy move through the payment adapter. When multiple compatible rails fit, 402flow uses a predictable rail-selection rule.

04

Observe

Onchain settlement observation stays separate from the initial payment attempt, so the operator can see provisional state and later chain-backed finality.

05

Receipt

402flow stores the receipt, policy decision, execution metadata, and audit context for each paid attempt.

06

Triage

If money moves but fulfillment fails, the exception record keeps the merchant, agent, rail, transaction context, and receipt state together for review.

Operational record

One record for settlement and fulfillment.

402flow gives operators a clear record of what happened after payment. Settlement, fulfillment, receipts, policy decisions, merchant context, and exceptions stay connected, so teams can review paid execution without reconstructing it from logs.

Policy decision

allowed before spend

Merchant matched policy scope and the request stayed inside the active spend window.

Settlement status

payment observed

The paid attempt has transaction context and a provisional receipt before onchain settlement finality is confirmed.

Fulfillment outcome

service failed after payment

402flow keeps the receipt, merchant, policy decision, and exception history together for operator triage.

For two roles

Governance for operators. A small surface for developers.

Operators get policy, receipts, settlement visibility, and exception context. Developers integrate through a small SDK surface into the same governed execution flow.

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 spend decisions and evidence visible.

Operators need more than a payment success signal. They need posture, merchant activity, policy review, settlement visibility, receipts, and a record of what happened when fulfillment completes or fails.

  • Default allow-and-monitor or deny-by-default org posture
  • Observed-only merchant discovery from live paid traffic
  • Per-agent and per-merchant spend controls
  • Policy review events and denial reasons
  • Predictable payment-rail selection
  • Receipt ledger and onchain settlement visibility after payment
  • Exception triage for paid-but-failed fulfillment
  • Reporting and audit visibility for reconciliation

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.

Proof

Working pieces of governed paid execution.

402flow has a hosted demo, public SDK, x402 rails, policy-controlled paid requests, receipt tracking, and receipts backed by onchain settlement evidence.

Hosted demo and x402 Browser

Use the hosted Console to explore paid endpoint catalogs with x402 Browser, inspect challenges, run governed test requests, then review observed merchants, provisional receipts, and later onchain settlement confirmation.

Open demo

Public SDK

The public SDK gives developers a small integration surface while the control plane owns policy decisions, attempt tracking, receipts, and onchain settlement confirmation.

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

Building paid API or agent-payment flows?

For teams building paid APIs, agent-payment flows, MCP tools, or x402 services. Get direct implementation support and help shape the 402flow control plane.

Request design partner accessView live demoView SDK