Skip to main content
PRODUCT OVERVIEW

The payment layer for AI agents.

Four building blocks. One coherent product. Use what you need, ignore the rest.

HOW THE SURFACES COMPOSE

Four parts. One coherent system.

Each surface owns one concern. The seams between them are explicit, documented, and stable.

Agent wallets - the ledger

Owns the USDC balance, the on-chain address, and the transaction history. Every payment your agent receives or makes lands here. Non-custodial, so the keys stay with the wallet provider you connected (Coinbase Wallet, Rainbow, MetaMask, or any EVM wallet via RainbowKit/Reown). The other three surfaces all read from or write to this ledger; they never replace it.

Payment API - the actuator

Turns ledger entries into actions your agent code can react to. A small set of routes to send payments, settle invoices with on-chain proof, read transactions, and manage agents. Four webhook events to notify your agent the moment money lands or leaves. Signed payloads, idempotency keys, and per-agent API keys keep the surface safe under high concurrency. Without the API, the wallet is a passive inbox; with it, the wallet becomes part of your agent's runtime loop.

Agent identity - the trust signal

Renders the wallet and its activity as a public, indexable web page at wallet.blockchain0x.com/a/{slug}. Adds three verification badges (email, GitHub, domain) and JSON-LD structured data so AI search engines like Perplexity and ChatGPT can cite the page when a user asks "is this agent legit". Without identity, your agent is an address. With it, your agent has a presence on the internet.

Spending controls - the governor

Enforces an owner-set spend permission - an allowance per period plus a per-transaction cap - on the backend, not in the agent's code. Your agent cannot exceed the limits even if its logic tries to, even if it gets prompt-injected, even if the LLM hallucinates a different cap. Permissions are set in the dashboard and read-only over the API, so the agent's own key can never widen them. Spending controls are the difference between an autonomous agent and a runaway agent.

ARCHITECTURE

The shape of a single agent payment.

What happens between "agent calls a paid tool" and "USDC lands in the wallet".

Architecture diagram: agent payment flow from POST /v1/payments to USDC settled on Base

The four surfaces show up as labelled boxes here: Payment API is the entry point, Spending controls gate every outgoing payment, the Agent wallet is the on-chain destination, and Agent identity passively reflects the wallet's activity to anyone who visits the public page. If you remove the Payment API box, the rest still works (the agent just receives passively at the public page). If you remove Spending controls, you lose the API-level safety net but the wallet still functions as a non-custodial address. Each surface is detachable from the rest.

IGNORE WHAT YOU DO NOT NEED

Modular by design, not by accident.

We deliberately built each surface so it can be removed without the others breaking. That is unusual in payment products, where vendors usually want every account, API call, and notification to flow through their stack. Modularity costs us some short-term lock-in. It buys us trust from developers who want to know they can leave.

Just need a public page to accept tips?

Use Agent wallets + Agent identity. Skip the Payment API and the spending controls. The Free plan covers this fully. Your agent receives USDC at a wallet address shown on its public page. Total setup time: 5 minutes.

Just need programmatic payment requests, no public profile?

Use Agent wallets + Payment API + Spending controls. Toggle the public page to private in the dashboard so the agent's transactions are not indexable. The hosted payment URL still works for one-off recipients; nothing about the agent leaks to crawlers.

Running 20 agents for clients and need per-agent isolation?

Use all four surfaces, on the Business plan. Per-agent spend policies, per-agent audit logs, per-agent verification badges, per-agent API keys, per-agent billing. Add team seats to grant the right operators access to the right agents.

Want to write your own API on top of just our wallets?

Possible, though not common. Connect a wallet, ignore our Payment API, write your own HTTP layer that monitors the chain directly. You lose webhook reliability, idempotency, and signed payloads, but you own the abstraction. Useful for advanced teams with a specific reason to skip our API surface.

FREQUENTLY ASKED

Five questions about how it fits together.

Do I have to use all four surfaces, or can I pick one?

Each surface works on its own. You can use just Agent wallets to receive USDC at a public page, never touch the Payment API, and ignore the verification badges. Or you can wire the Payment API into your agent code and skip the public page entirely. The pricing model is per agent, not per feature, so you are not paying for things you do not use. Most teams start with Agent wallets + Spending controls, add the Payment API once their agent code is ready to request payment programmatically, and turn on Agent identity verification when they have customers asking for a trust signal.

Can I migrate from a raw Coinbase Wallet or MetaMask setup?

Yes. Blockchain0x is non-custodial, so you connect your existing EVM wallet via RainbowKit or Reown. The wallet's USDC balance, transaction history, and address all come with you. We add the public page, the API, the verification, and the policy layer on top. You can stop using us at any time and your wallet keeps working as before with no lock-in and no data egress hurdle.

How is this different from just using Stripe?

Stripe is built for human checkout: a buyer fills out a card form, completes 3DS, gets a receipt. AI agents cannot complete that flow because they cannot fill in forms, create accounts, or remember passwords. Blockchain0x is built for the opposite shape: an agent encounters a 402 Payment Required response, parses a hosted URL, pays in USDC, and continues. Use Stripe for your human customers; use Blockchain0x for the payments your agents make and receive programmatically. They are complementary, not competing.

What chains do you support?

Base mainnet and Base Sepolia testnet today, with native USDC issued by Circle (not bridged). Other chains - Solana, Ethereum mainnet, Polygon, Arbitrum - are on the roadmap, not committed to dates, and not live yet, so do not design around them. The adapter architecture means adding one later would not change the public API, webhook contracts, SDKs, or this product page, so building against Base now does not lock you out. Base fits agent payments well: low transaction costs, fast confirmation, native Circle USDC, and the EVM tooling ecosystem.

Is there a free tier? What is the catch?

Yes. Every agent starts on Free with no monthly cost, and a transaction fee on incoming USDC covers infrastructure. Free has read-only API access and no webhooks; you upgrade an agent to a paid plan - a lower fee plus full API and webhooks - when it earns enough that the upgrade pays for itself. Many agents stay on Free because their volume does not justify moving up. The current fees and plan tiers live on the pricing page rather than here, so the numbers stay in one place.

Give your agent a wallet.

Free to start. Upgrade an agent to a paid plan once it earns. Ship in minutes.