How it works
402flow keeps the developer surface small and moves merchant discovery, policy, rail selection, receipt issuance, and onchain finality into the control plane.
Execution model
Lifecycle
The shape stays consistent whether the caller uses `fetchPaid(...)` or the inspect-revise-execute loop.
The agent issues a paid request through a small SDK surface instead of embedding protocol mechanics in the application.
402flow checks organization posture, policy, merchant constraints, and spend limits before execution.
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.
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.
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.
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 execution.
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 promotes them to confirmed only after the onchain 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, and owns the protocol-specific payment path inline.
402flow-mediated request
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.
Next step
Start with the SDK. Then use the hosted demo to see observed-only discovery, policy review events, wallet-order rail selection, provisional receipts, and later observer-backed confirmation in one paid request.