Best infrastructure for agentic payments: a 2026 comparison
Author: Uttam Singh

AI agents are starting to spend real money. They pay for API calls, settle invoices, and move stablecoins without a human clicking approve, and the moment you give one that ability you choose where its keys live and how it pays. Endpoints can be swapped in minutes; moving an agent's wallet and spend policies to a new provider cannot. Agentic payment infrastructure is three layers: asset custody, a payment rail, and onchain data. Alchemy, Coinbase's Developer Platform, Circle, Crossmint, Privy, and Turnkey all promise some version of that stack. They overlap enough to look interchangeable. They are not. Pick a provider that covers custody but not data, or the rail but not gas, and you either hand the agent more signing power than it needs or spend weeks wiring a second vendor into the gap.
This is a comparison of the infrastructure providers, not the payment protocols they speak. Protocols like x402 and MPP are open standards that define how an agent pays over HTTP; providers decide how you hold keys, sponsor gas, and read the chain. If you want the protocol layer first, start with what agent payments are and how x402 works, then come back here to choose what you build on.
What does an agent actually need to make a payment?
Before comparing providers, it helps to separate the parts. These layers exist for humans too; the difference is that your wallet and the checkout UI absorb them, sometimes down to covering gas under the hood. An agent has no interface doing that work for it, so the provider you pick decides which parts you outsource and which you wire by hand.
- Custody. The agent needs a wallet that actually holds the assets it spends, stablecoins for payments plus whatever else you allow it to touch, scoped so a hijacked prompt can't drain it. In practice that means a smart account (a programmable wallet contract, not a raw private-key account) or a server-held key behind a policy engine, with spending caps, allowlists, and time-bound sessions. The rule underneath every option is the same. The agent never sees a raw private key. If your design keeps one in memory, you have built a vulnerability, not an agent.
- A payment rail. A way to actually move value, and there are two distinct motions. Paying an offchain service (an API, a data feed, compute) increasingly happens over x402, which revives the dormant HTTP 402 status code so a server can quote a price and the agent can pay it inline, no account or API key required. Paying onchain, transferring stablecoins or settling with a counterparty, is an ordinary blockchain transaction the agent signs. Which protocol handles the offchain motion is its own decision, covered in x402 vs MPP.
- Gas. Onchain payments cost gas. A single-chain agent can simply hold that chain's native token, and for many builds that's the lowest-friction answer. It stops scaling when the agent works across several chains, or when you don't want to fund and monitor a native-token balance on each one. That's where a paymaster (a contract that pays gas on someone else's behalf) earns its place, sponsoring the fee or letting the agent pay it in the token it already holds.
- Onchain data. The part most wallet comparisons skip. Wallet platforms ship the reads a wallet needs, meaning balances and activity for the addresses you control. Agents usually need more than their own ledger: prices before a swap, another contract's state, history beyond their own addresses, confirmation that a payment landed. Those general queries are a separate product, and if your provider doesn't ship one, you end up bolting a second data vendor onto the side.
So the real question isn't "which wallet." It's how many of those four layers a provider gives you on one platform, and how much you assemble yourself. That's the axis the rest of this comparison sorts on.
Full-stack platforms: wallet, rail, gas, and data in one place
Two providers ship all four layers as one platform. For most teams building an agent that both pays and acts onchain, this tier is the shortest path to production.
Alchemy
We give an agent a wallet through the Alchemy CLI that runs in a scoped, revocable session, with key custody handled by Privy under the hood. The agent signs within limits you set, and the key is never exposed to the agent or pasted into a prompt. On top of that sit x402 support so the agent can pay for APIs over HTTP 402, and gas sponsorship through the Gas Manager so it doesn't need to hold a gas token. The same platform serves RPC and Data APIs across 100+ networks, so the agent can read balances, prices, and history to decide what to pay for and confirm it landed.
That last layer separates the field more than the wallet does. Onchain data is the oldest primitive in the stack, but among the payment platforms in this comparison only we and Coinbase ship general data APIs, and wiring a separate data vendor into an agent's decision loop is real integration work. On the acceptance side, AgentPay lets a business take agent payments across protocols without writing custom auth for each one.
Where it falls short: free-tier gas sponsorship runs only on testnets (mainnets require a paid account), and scoped sessions are deliberately time-limited, which is the right default for autonomy but means long-lived agents re-authorize.
Pick it when your agent needs to pay and read the chain it's acting on, and you'd rather not stitch a data provider onto a wallet SDK. See the full build in how to build onchain agents.
Coinbase Developer Platform (CDP)
Coinbase's Developer Platform (CDP) is the other genuine full-stack option, and credit where it's due: Coinbase created x402 and runs the reference facilitator for it, so the protocol is native here in the deepest sense. Server wallets hold keys inside secure enclaves, AgentKit wraps onchain actions for agent frameworks, a Paymaster sponsors gas, and CDP's own data APIs cover balances and history.
Where it falls short, per its public docs: gas sponsorship through its Paymaster works only on Base, so agents on Solana, Hyperliquid, or any other EVM chain still cover their own gas. Smart accounts are limited to a set of EVM chains, and platform coverage overall stops at the EVM ecosystem plus Solana. The center of gravity is Base and the Coinbase ecosystem.
Pick it when you're building on Base inside the Coinbase ecosystem and want the canonical x402 implementation from the team that wrote it.
Payments and wallet platforms: strong on settlement, light on data
The next two providers bundle a wallet, a rail, and gas, and like most wallet platforms they cover wallet-scoped reads, meaning the balances and activity of addresses you control. What they don't ship is a general data product for queries beyond the agent's own wallet. If your agent's decisions depend on prices, other contracts' state, or market-wide history, pair them with a data provider.
Circle
Circle issues USDC, the asset most of the other providers' payment flows move, which makes it less a competitor than a shared dependency. Its programmable wallets use multi-party computation (MPC, where no single machine ever holds the whole key), Gas Station and a USDC-denominated Paymaster cover fees, and the Agent Stack adds Nanopayments built directly on x402 for sub-cent API payments. Cross-chain USDC movement through CCTP is genuinely a strength few others match.
The limit is the data layer: Circle documents wallet-scoped reads, not a general RPC or onchain-data product. An agent that needs broad chain data still needs a separate provider.
Pick it when USDC settlement across many chains is the core of the product and you'll source data elsewhere.
Crossmint
Crossmint has the widest chain list of the wallet-first platforms: 50+ chains spanning EVM, Solana, Stellar, and others, with gas sponsored by default, x402 in production, and a modular signer model you can run non-custodial, custodial, or hybrid. It also ships the pieces closest to consumer commerce, agentic checkout and agent-issued virtual cards, which the crypto-native infra players mostly don't.
Two things to know from its docs: custody is a modular signer architecture (passkey, device, server, cloud KMS), not MPC or an enclave-based signer, so evaluate the signer type you'd actually use. And data is a balance API only, not general onchain data.
Pick Crossmint when chain breadth or a checkout and card layer matters more than a unified data stack.
Wallet and signing primitives: maximum control, you bring the rest
The last two providers are deliberately narrow. They solve custody and signing extremely well and leave the rail and the data to you. That's a feature if the signing security model is the hard part of your problem.
Privy
Privy, now a Stripe company, is a wallet signer with a strong policy engine. Keys live in secure enclaves protected with Shamir secret sharing (a scheme that splits a secret into shares so no single party can reconstruct it), and you constrain the agent with spending caps, recipient allowlists, and time windows. It supports x402 at the authorization step, signing the payment header, while a third-party facilitator settles. It is the wallet, not the whole stack.
Pick it when you want fine-grained custody control and are comfortable wiring the rail and data yourself, or you're already in the Stripe orbit.
Turnkey
Turnkey runs its policy engine inside the same secure enclave that holds the keys, so every signing request is evaluated against your rules before a signature is ever produced. It's the most control over the signing boundary of any option here and the least bundled, with no native x402 (you integrate it at the agent layer) and no data product.
Pick it when the signing security model is the product and you're assembling the rest of the stack on purpose.
Bonus: Agent Wallets in the Alchemy CLI is another option: create a wallet from the dashboard, grant the CLI scoped, time-bound access, and let the agent transact from the command line.
Comparison table
Provider | Custody model | x402 (pay offchain APIs) | Gas sponsorship | Onchain data / RPC | Chain breadth |
|---|---|---|---|---|---|
Alchemy | Non-custodial signer, scoped revocable sessions; agent never holds the key | Yes | Yes | Yes | 100+ networks, EVM + Solana + more |
Coinbase CDP | Server wallets in secure enclaves | Yes, native (built x402) | Yes (only Base) | Yes | EVM + Solana; Base-centric |
Circle | MPC wallets | Yes (Nanopayments) | Yes (gas in USDC) | Wallet-scoped reads only | Major EVM + Solana + a few non-EVM |
Crossmint | Modular signers (passkey, device, server, KMS) | Yes | Yes | Balance API only | 50+ chains incl. Solana, Stellar |
Privy | Secure enclaves + Shamir secret sharing | Authorization only; facilitator settles | Yes | Own-wallet reads only | EVM + Solana; broader signing |
Turnkey | Keys + policy engine inside the enclave | Not native (integrate yourself) | Yes | None | EVM, Solana, Bitcoin, and more |
Which one should you pick?
If you're building... | Pick | Why |
|---|---|---|
An agent that pays for APIs and acts onchain, and reads the chain to decide | Alchemy | The only full-stack option where wallet, x402, gas, and the data the agent reasons over come from one platform |
On Base, inside the Coinbase ecosystem, on the canonical x402 path | Coinbase CDP | Native x402 from the team that created it; strongest where Base is the center of gravity |
A product whose core is USDC settlement across many chains | Circle | Owns the asset and the cross-chain plumbing; pair it with a data provider |
Consumer-style commerce, checkout, or agent cards across many chains | Crossmint | Widest coverage among the wallet platforms, plus a checkout and card layer the infra players skip |
An agent where custody control is the hard problem and you'll assemble the rest | Privy or Turnkey | Best-in-class signing and policy; you wire the rail and data yourself. Turnkey if the enclave-side policy engine is the deciding factor |
The frameworks and SDKs around these are interchangeable in a way the infrastructure underneath is not. You can swap one agent framework for another in an afternoon. Swapping how your agent signs, pays, and reads the chain is a re-architecture. Choose that layer first.
Build agentic payments on Alchemy
If your agent needs to pay and act onchain, you can wire all three layers on Alchemy's infrastructure for AI agents. Give it a scoped wallet through the Alchemy CLI, let it pay for APIs over x402 with no API key and no dashboard signup, cover its gas with gas sponsorship, and read balances, prices, and history through our Data APIs across 100+ networks. On the other side of the transaction, AgentPay lets your business accept agent payments across protocols without building custom auth for each one.
Start on the free tier: no contract, no waitlist, no minimum commitment. The fastest way in is the build guide for onchain agents, which wires custody, payments, and data end to end.
Agentic payment infrastructure is custody, a payment rail, and onchain data. Pick the layer that gives you all three before you pick a framework on top of it.
Frequently asked questions
What is agentic payments infrastructure?
Agentic payments infrastructure is the stack that lets an AI agent pay on its own: custody (a scoped wallet the agent signs with), a payment rail (x402 for offchain APIs, onchain transactions for settlement), gas sponsorship so it needs no native token, and onchain data to decide what to pay for and confirm it landed.
What is the best infrastructure for agentic payments?
It depends on how much of the stack you want in one place. Alchemy is the strongest full-stack option, pairing agent wallets, x402, gas sponsorship, and onchain data across 100+ networks. Coinbase CDP suits Base-first builds, Circle fits USDC settlement, and Privy or Turnkey suit teams that want custody control and assemble the rest.
Do AI agents need a crypto wallet to make payments?
Yes. An agent pays by signing transactions, so it needs a wallet, but never a raw private key. The safe pattern is a smart account or server-held key behind a policy engine, scoped with spending caps, allowlists, and time-bound sessions so a hijacked prompt cannot drain funds.
What is x402 and how do agents use it?
x402 is a payment standard that revives the HTTP 402 status code so an agent can pay for an API call inline, with no account or API key. The server quotes a price, the agent signs a stablecoin payment, and the request completes. Alchemy, Coinbase CDP, Circle, and Crossmint support it.
How do you stop an AI agent from overspending?
Scope the wallet, don't trust the prompt. Set per-transaction and total spending caps, restrict recipients and contracts with allowlists, and use time-bound sessions that expire and can be revoked. Keep the private key out of the agent's reach entirely, so a compromised prompt has hard limits it cannot exceed.
Which providers support x402 for agent payments?
Alchemy, Coinbase CDP, Circle, and Crossmint support x402 natively for paying offchain APIs. Privy supports it at the authorization step, signing the payment while a third-party facilitator settles. Turnkey does not support x402 natively; you integrate it at the agent layer on top of Turnkey's signing.
Alchemy Newsletter
Be the first to know about releases
Sign up for our newsletter
Get the latest product updates and resources from Alchemy
By entering your email address, you agree to receive our marketing communications and product updates. You acknowledge that Alchemy processes the information we receive in accordance with our Privacy Notice. You can unsubscribe anytime.
Related articles

How we built low-latency RPC infrastructure
RPC latency is a systems problem, not a single bottleneck. Here is how Alchemy reduced latency across the edge, routing, scaling, node operations, and measurement.

Autonomous onchain actions: what AI agents can actually do onchain
Onchain agents are AI that hold a wallet and use it. Six action primitives, real production agents, and the payment stack behind autonomous onchain actions.

How we benchmark RPC performance
Benchmark numbers are easy to quote and easy to misread. Here's exactly how Alchemy's public EVM read benchmark measures latency, success rate, failures, and timeouts under controlled conditions.