Skip to main content
The best experience is simple for the agent and controlled for the operator. Your code calls a protected resource normally, the wrapper handles the paid retry, and your policy decides whether the payment should be signed. Automatic payment does not mean unlimited payment. Treat the wrapper as the transport layer and your policy as the guardrail.

​
What the wrapper handles

The wrapper handles the payment mechanics around a normal HTTP request.
1

Read payment requirements

The wrapper receives the seller’s payment requirements from the protected route.
2

Create a unique request

It generates a request ID that has not been used for another guarantee.
3

Sign the guarantee

It signs a payment guarantee with your configured account.
4

Retry the request

It sends the request again with the payment header attached.
5

Return the response

Your agent receives the paid response like a normal HTTP result.

​
What your policy should handle

Your policy handles judgment. It decides whether the seller, route, amount, network, asset, and task context are allowed before the wrapper signs.
Policy areaDecision
Spend limitsMaximum price per request and maximum spend per task.
Seller accessAllowed sellers, domains, networks, and assets.
ApprovalThresholds that require a person or higher-level policy.
BlockingCategories, routes, or sellers the agent should never pay.
AuditReason codes, logging, and alerting for every paid request.

​
TypeScript fetch wrapper

import { wrapFetchWithPaymentFromConfig } from "@x402/fetch";
import { FourMicaEvmScheme } from "@4mica/x402/client";
import { privateKeyToAccount } from "viem/accounts";

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`);
const scheme = await FourMicaEvmScheme.create(account);

const fetchWithPayment = wrapFetchWithPaymentFromConfig(fetch, {
  schemes: [{ network: "eip155:84532", client: scheme }],
});

const response = await fetchWithPayment("https://api.example.com/research");
After the first paid retry succeeds, check the corresponding wallet activity in 4mica dashboard.

​
Signing rules

Before signing, validate the payment against your policy. The amount should fit the budget, the seller address should match the expected service, the route should match the task, and the network and asset should be approved. If the payment crosses an approval threshold, collect approval before signing. If the task budget has no room left, return a controlled error so the agent can pick another service, ask for approval, or stop. When a seller requirement does not clearly match policy, pause signing and ask for help.

​
Logging rules

Automatic payment should still be explainable. Each paid request should connect task ID, request ID, guarantee ID, seller domain, seller payTo address, route, amount, network, asset, policy version, reason for payment, and final result or error. These logs answer “why did the agent pay?” after the task is done.