What happens between your agent and the API.
402flow sits in the payment path. Each paid request is checked against your policy before anything is paid, and each step leaves a record your operators can read.
The path every paid request takes.
- The agent sends the request through the SDK, using its own credential.
- The merchant answers with a price. 402flow checks the request against your posture and every policy that covers this agent and this merchant.
- If a policy says no, the request stops here. Nothing is paid, and the reason is recorded.
- If it’s allowed, 402flow pays from one of your wallets. When more than one could pay, a fixed rule picks the same one every time.
- It watches the chain separately. The receipt is provisional until the payment reaches finality, then confirmed.
- It records what the merchant returned. If you paid and weren’t served, an exception opens for triage.
Start with a posture.
Each organization picks one of two defaults. Either way, every request is checked and every decision is recorded.
Allow and monitor
Paid requests go through unless a policy stops them. Merchants you haven’t set up yet appear in Reports as observed, so you see real traffic before you write rules, then tighten from there.
Deny by default
Nothing is paid unless a policy allows it. Blocked requests land in the policy review queue, so access widens on purpose, one decision at a time.
How policies stack.
A policy applies to the whole organization, to chosen agents, or to chosen merchants. It can cap a single request, or cap total spend per day, week, or month. A group of agents or merchants can share one budget, or each get its own.
| The organization | 100 USDC per month |
|---|---|
| Each research agent | 25 USDC per day |
| Each data vendor | 1 USDC per request |
One request can match all three. 402flow checks its amount against each limit, together with what has already been spent in each window, and pays only if the request fits within every one.
When a request is denied.
The request stops before any money moves. Your code gets a denial with the reason, and operators get a review item showing the agent, the merchant, the amount, and the limit it hit. Change the policy and the next request follows the new rule. The record of the earlier decision stays.
Try it on one of your workflows.
A pilot runs for up to 60 days on one agent workflow, in a test or controlled payment environment, with no software fee.