How it works
402flow keeps the developer surface small and moves merchant discovery, policy, rail selection, receipt issuance, and onchain settlement confirmation into the control plane.
Execution model
Lifecycle
The shape stays consistent whether the caller uses `fetchPaid(...)` or the inspect-revise-execute loop.
The agent shapes a paid request through a small SDK surface instead of embedding protocol mechanics throughout the host.
402flow checks organization posture, policy, merchant constraints, and spend limits before money moves.
Requests that satisfy policy move through the payment adapter. When multiple compatible rails fit, 402flow uses a predictable rail-selection rule.
Onchain settlement observation stays separate from the initial payment attempt, so the operator can see provisional state and later chain-backed finality.
402flow stores the receipt, policy decision, execution metadata, and audit context for each paid attempt.
If money moves but fulfillment fails, the exception record keeps the merchant, agent, rail, transaction context, and receipt state together for review.
Control plane
The key difference is not payment support. Merchant discovery, policy denials, and rail selection become product behavior instead of hidden runtime logic.
Requests are checked against organization posture, merchant rules, and spend controls before money moves.
Under Default allow and monitor, merchants that are not yet configured in Setup remain observed-only in Reports until the org promotes them.
When a managed request does not satisfy policy, 402flow denies it before execution and creates a policy review event.
Receipts can be provisional at first. The chain observer confirms onchain settlement only after the finality rule is satisfied.
Policy shape
402flow policies are not just one org-wide threshold. The model can target the organization, specific merchants, or specific agents, then enforce either per-request limits or over-time budgets before execution begins.
A policy can apply org-wide or to merchant- and agent-scoped traffic. Non-org scopes can target selected sets of merchants or agents, or all merchants or agents, and can apply either as a shared cap or a per-member cap.
Limits can deny a single request based on its current amount, or evaluate cumulative spend over day, week, or month windows before execution continues.
Policies are amount-based and asset-aware, so org caps, merchant budgets, and agent spend limits all use one structured model instead of ad hoc rules in app code.
Before / After
The request can succeed in either model. The difference is whether discovery, denials, rail choice, and receipts stay coherent across hosts.
Direct paid request
The application detects a paid endpoint, decides whether to proceed, executes payment inline, and has to reconcile settlement and fulfillment afterward.
402flow-mediated request
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.
Next step
Start with the SDK. Then use the hosted demo to see observed-only discovery, policy review events, predictable rail selection, provisional receipts, and later observer-backed onchain settlement confirmation in one paid request.