Agentic payments for tools, APIs, and autonomous workflows

Agentic payments are policy-first machine payments: a human sets the budget, the approved tools, and the escalation threshold once, and the agent then transacts inside those bounds without asking again. The payment carries machine-readable context — which agent, which customer, which tool, which policy allowed it — so finance and support reconstruct any charge later.

They are not card-on-file credentials handed to a model, and they are not post-hoc expense reconciliation. If a payment cannot be attributed to an identity, checked against a balance, and explained by a policy, it is not an agentic payment in the sense this guide uses the term.

Most public discussion of agentic payments focuses on shopping: an agent booking a flight or ordering supplies, usually with per-order human confirmation. That pattern is real but occasional — a handful of high-value decisions per session.

Locus exists for the other pattern: high-frequency tool-call payments. A research agent may call search, extraction, enrichment, and model APIs hundreds of times per hour at fractions of a cent each. Confirming every call is impossible; confirming the policy once — budgets, allowlists, per-call ceilings — is what makes the workload safe. The rest of this guide describes that pattern.

Every Locus payment passes the same five checks before execution:

1. Identity. Personal Locus Pro connections authenticate with revocable browser OAuth; unattended enterprise services use scoped credentials, and tenant secrets stay on trusted servers. Pay With Locus agents transact from non-custodial ERC-4337 smart wallets on Base with scoped session keys.
2. Limits. Prepaid credit balances are checked before the call; on-chain wallets enforce allowances, per-transaction budgets, and policy-group caps.
3. Allowlists. Enterprise workspaces scope credentials to bundles of catalog tools, so an agent can only reach the capabilities its owner enabled.
4. Justification. The agent supplies its reasoning with the request, and the resulting record ties the charge to that justification.
5. Audit logs. Each burn or transfer lands in a durable usage record with customer, tool, provider, status, and remaining balance — the same record that powers customer-facing usage history.

Approval thresholds sit on top: Pay With Locus can require human approval above a configured amount while smaller transactions inside budget run autonomously. Read authentication and scopes.

Over the Model Context Protocol, payment rides inside tool invocation. The client connects to one hosted MCP server, the agent searches the catalog and estimates cost with compact meta-tools, then invokes the chosen tool. Locus verifies balance, scope, and policy, executes the provider call, and returns the result together with the charged amount and remaining balance. For the integration-oriented version, see MCP payments and the MCP marketplace.

HTTP 402 (Payment Required) lets a server quote a price instead of serving a request. Over x402, the agent's request receives a machine-readable payment challenge, pays it in USDC on Base, and retries with proof of payment. Stateless HTTP APIs become payable tools without accounts. See HTTP 402 payments for the protocol-oriented companion to this guide.

• Insufficient balance. Underfunded Locus Pro calls return HTTP 402 before provider execution — never a silent overdraft.
• Policy rejection. Calls outside credential scope, allowlists, or configured limits are denied before spend with a reason the agent can act on.
• Failed execution. Non-streaming failures and streams rejected before upstream acceptance release held credits automatically.
• Refunds. End-user top-ups, payouts, and ledger corrections follow the documented funding flow; start with funding and billing.