Other agents can pay your agent the same way any x402 buyer pays a protected resource. They call your route, receive HTTP 402, evaluate the price against their policy, sign a guarantee with a unique request ID, and retry the request.
Your server verifies and settles the guarantee before running the paid operation.
What changes when the payer is an agent
The payment flow stays the same. The operating model changes because the buyer may decide without a human approval step, call many sellers in one task, arrive with little reputation, resell your result inside a larger workflow, or require machine-readable pricing and limits.
Design your API for that reality. Make the price explicit, reject requests that exceed policy, and log enough context to support automated workflows.
Assume another agent will read your payment requirements before a person does. Clear amounts, limits, expiration rules, and task metadata help autonomous buyers make safer decisions.
Receiving payment without human approval
You do not need a human to approve every inbound payment. Your protected route defines the price and requirements. If the buyer produces a valid guarantee, your server can accept it automatically.
The buyer controls whether its own agent can sign without human approval. That authority comes from the buyer’s wallet, signer, collateral, and policy.
Resale and downstream paid calls
Your agent can call another paid agent, combine the result, and sell the final output. Treat this as a workflow with input cost, not a single free operation.
For resale workflows, quote high enough to cover downstream calls, cap downstream spend per request, log each paid sub-call, and reject requests that cannot be fulfilled profitably. If your product has resale or data-use limits, disclose them before the buyer pays.
If you split revenue with other agents or tools, track each participant’s contribution and payment obligation in your application. 4Mica can handle the paid requests and guarantees, while your workflow defines the revenue allocation.
Do not resell downstream work unless your price, permissions, and logs can support it. A profitable top-level request can still fail if one sub-call costs more than expected or forbids reuse.
Allow or block buyers
You can define who is allowed to buy from your agent. Access policy usually combines trust, economics, and abuse prevention.
| Control | When to use it |
|---|
| Allowlists | You only want trusted wallets, agents, domains, or customers to buy. |
| Blocklists | You need to stop suspicious payers from returning. |
| Per-buyer limits | You want to cap request volume or spend from one buyer. |
| Higher unknown-buyer prices | You want the price to reflect extra risk or support cost. |
| Deposits or minimum guarantees | You need confidence before expensive work starts. |
| Identity or metadata checks | You need more context before accepting a task. |
Negotiating price
Agents can negotiate price before payment if your API exposes a quote or planning endpoint. A simple flow is:
- The buyer describes the task.
- You estimate cost, time, and constraints.
- You return a quoted price and expiration.
- The buyer signs only if the quote fits policy.
- You execute after payment validation.
For deterministic products, skip negotiation and publish fixed route prices.
Exposing payment requirements through an API
HTTP 402 is the API-native way to expose payment requirements. An agent can discover the required scheme, amount, accepted network and asset, payTo address, expiration, and metadata directly from your route.
This lets agents decide automatically whether to pay, choose another provider, or ask their operator for more budget.
Multi-agent workflows
A single workflow may involve multiple paid agents. Each seller should receive a payment guarantee for its own work. Do not rely on another seller’s payment record as proof that your route was paid.
For every agent-to-agent step, log enough to explain the chain of work.
| Log field | Why it matters |
|---|
| Upstream and downstream request IDs | Connects your request to the larger workflow. |
| Payer and seller | Shows who paid whom at each step. |
| Amount and settlement result | Shows the obligation and whether it completed. |
| Delivered output or hash | Connects the payment to the result provided. |
