How it works
402flow keeps the developer surface small, then moves policy evaluation, approval routing, payment execution, and receipt persistence into the control plane.
Execution model
Lifecycle
The product shape stays consistent whether the caller uses the fast `fetchPaid(...)` path or an explicit inspect-then-execute loop.
The agent issues a paid request through a small SDK surface instead of embedding protocol mechanics directly in the application.
402flow evaluates the request against organization posture, policy, merchant constraints, and spend limits before execution is allowed.
Requests that fall outside policy stop for operator review and possible policy adjustment instead of failing silently or spending automatically.
Requests that satisfy current policy move through the supported payment rail with protocol-specific handling kept behind adapters.
402flow stores the normalized receipt, decision history, and audit context so operators can understand what happened after the request completes.
Control plane
The key difference is not payment support. It is that the control plane becomes the place where the important decisions happen.
Requests are checked against organization posture, merchant rules, and spend controls before an execution path is allowed.
Requests that need approval stop for review instead of turning into side-channel ops work or automatic spend.
After execution, 402flow persists normalized receipt and audit context so the operator can prove what happened.
Before / After
The request can succeed in either model. The difference is whether approvals, policy, 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, routes review when needed, executes through the payment adapter, and stores the result.
Next step
Start with the SDK if you already know the request shape. Use the hosted demo merchant when you want to verify the end-to-end paid-request path against a real merchant surface.