Solana Payment Channels: AI agents now pay once and call a million times — and the seller side is still the missing half

What Solana shipped on September 3 — and what a payment channel actually is

The Solana Foundation announced Payment Channels on September 3, 2026, in a post by Rishin Sharma, its head of AI growth, under the headline "1 million payments per second". The line worth keeping from that post is a different one: "Every call an agent makes needs a signature approval and settlement … gets more complicated when agents are making hundreds of small paid calls in a loop." That is the problem being solved. Not speed for its own sake — the cost of paying per call when the calls come in bursts.

A payment channel is an old idea in a new coat. The mechanics, from the Foundation's own description and the accompanying docs, run in four steps:

1. Open. The buyer deposits a ceiling amount — say 20 USDC — into an on-chain escrow account controlled by a program, not by the seller. The docs are explicit: funds are "held by an on-chain channel program, not by the server", and "the buyer can always recover the unspent remainder".
2. Meter. Each API call is authorized by a signed message — a voucher carrying a cumulative amount — rather than by a blockchain transaction. No fee, no block, no wait.
3. Settle. The seller submits one on-chain transaction with the latest voucher. The program checks that the cumulative amount is above what was already settled and at or below the deposit, then records it.
4. Distribute. Funds go to the recipients, and whatever was not consumed returns to the buyer's wallet.

Two modes ride on top. In x402 batch mode, many deliveries are settled together, and the upto scheme covers a single metered call whose cost is unknown until it runs. In MPP session mode, the buyer opens a channel, streams many metered deliveries under a running voucher, and settles once when the session idle-closes. The session method has its own draft spec, "Solana Session Intent for HTTP Payment Authentication", published September 9, 2026 by engineers at the Solana Foundation and Moonsong Labs. The program, a toolkit called pay-kit and a benchmark template are open source on GitHub.

That is the whole thing. It is a bar tab for machines: put money down, run up usage, pay once on the way out. The novelty is not the tab. It is that both agent-payment standards — x402 and MPP — now have a shared, non-custodial way to run one on Solana.

The benchmark, read carefully

The number everyone quoted is a million payments per second. Here is what stands behind it. The Foundation ran 100,000 unique wallets through one payment-channel proxy and measured more than 1,000,000 payments per second, which it extrapolated to "more than 80 billion payments in 24 hours". Its documentation reports a settlement cycle of about 203 seconds across the 100,000 channels and a cost of $0.0078 per million payments — the widely reported figure of $0.000000000776 per payment is simply that divided out.

Three caveats, none of which the Foundation hid. First, the hardware was not disclosed, so the throughput describes a proxy and a program under chosen conditions, not mainnet. Second, the payments in the test were off-chain vouchers; the chain only saw the settlement transactions, which is the entire point of the design and also why the number should not be compared to Visa's 65,000 peak TPS. Third, and most important: capacity is not demand. Forkast's September 5 analysis put it bluntly — the figure is "a proof of concept rather than a market reality". The same piece cited Artemis Analytics finding that roughly half of Solana's x402 transactions are artificial, self-dealing or wash activity, against a cumulative 35 million x402 transactions and about $10 million in volume on the chain, with real daily volume near $28,000 as recently as March.

None of that makes the launch unimportant. It makes it what it is: infrastructure shipped ahead of load. We covered the same pattern a week ago when Solana rebuilt its transaction format — a rail being upgraded in public, on a schedule, with the receipts posted. Payment Channels belong to that batch. The question for a business is not whether a million per second is real. It is whether you will ever need a thousand per second, and what you should do in the meantime.

Alibaba Cloud is the tell — the first partner is a seller

Every previous milestone in agentic payments we have written about was on the buyer side: AWS gave agents a wallet, Cloudflare gave them wallets and identities, Binance and MoonPay gave consumers an agent that can pay. The seller side — the API that actually returns a 402 and takes the money — has been thin, mostly indie developers and a handful of data vendors.

Payment Channels launched with Alibaba Cloud as the first live partner, and the partnership is seller-shaped: its inference API endpoints were payable through channels from day one. An agent approves a spending limit once and can then call those models repeatedly without opening an account, holding an API key, or approving each request. Inference is the perfect first workload for a channel, because it is billed by the token, the price of a call is unknown until it finishes, and a single agent task can fan out into hundreds of calls in seconds. It is exactly the loop the Foundation described.

That is the first hyperscaler to put paid endpoints, not just wallets, in front of agents on a public chain. It answers the objection that "nobody serious is selling to agents". Someone serious now is. It also sets the reference behaviour: agents that learn to buy inference this way will expect every other API to be reachable the same way — a price on the response, a stablecoin, no signup.

Channels solve the loop, not the call — who actually needs one

It helps to be precise about what a channel removes. Under plain per-call x402, each paid request carries a signed payment authorization that a facilitator verifies and settles on-chain. On Base that costs a fraction of a cent and takes about two seconds; on Solana, under half a second. For an agent making ten paid calls in a session, that overhead is invisible. For an agent making five hundred metered calls in ten seconds — an inference loop, a per-row data enrichment, a streaming feed — it is the dominant cost and the dominant latency. That is the case channels are built for.

So the honest map of who needs what looks like this:

• Metered-by-usage services with bursty loops — inference by token, compute by second, streaming market or telemetry data — benefit from channels. The upto scheme or a session voucher lets the price be discovered after the call.
• Priced-per-call services — a lookup, a conversion, a document parse, a search, a report — are already well served by per-call x402. A fixed price, one authorization, one settlement.
• Everyone not yet selling to agents at all — which is most of the API economy — has a prior problem: there is no paid URL for an agent to find.

That third group is the largest by a wide margin, and the data says so. The first full audit of 2026 x402 payments, published September 6 by Bitquery, found that most of the money was a bridge and the median seller had earned about $2.50. The sellers who stayed were the ones with a real endpoint, a sensible price and a reason for an agent to come back. None of them was constrained by settlement throughput. They were constrained by being findable and payable.

What a seller has to run to accept channel payments

Read the docs and the draft spec with a seller's eye and the work becomes visible. To take channel payments you need to:

• Deploy or point at the channel program on-chain and publish its address, a recent blockhash and slot, a grace period and optional distribution splits in your 402 response's method details.
• Run a verifier that checks each incoming voucher's signature and cumulative amount against the open channel before serving the request.
• Meter honestly — in upto mode the operator signs the actual amount after the call, so your metering is part of the trust model.
• Submit settlements with the settle instruction, close cooperatively with settleAndSeal, and run distribute; the draft also expects the server to act as rentPayer, sponsoring transaction fees so buyers only need stablecoin.
• Handle edge cases: idle-close timing, a buyer who stops responding mid-session, a voucher that arrives after settlement.

All of this is open source and well documented, and for a team already selling inference at scale it is a reasonable week. For a five-person API business it is a project — against a spec published on September 9 that expires as a draft in March 2027. This is the same shape as every agentic-payments launch this year: the protocol is finished, the SDKs exist, and the missing piece is a seller with the time to wire it up.

How Payzum fits — the zero-code seller side, available today

Payzum does not run Solana payment channels. What it does run is the part almost every API seller is missing: a paid x402 URL in front of an endpoint you already have, with no code and no protocol to implement. You configure a path, the HTTPS URL of your existing endpoint, a price per call in USDC and the address that should receive the money. Payzum publishes the x402 URL, returns the 402 with your price, verifies the agent's signed payment through an external facilitator — currently Coinbase's — and proxies the paid request to your origin with your own API key. Your service keeps answering ordinary requests exactly as before.

The settlement asset is USDC on Base, and it settles non-custodially to the address you set. Payzum is the middleware, not the facilitator, and it never holds the funds. You can also mark an endpoint discoverable so it is listed in the catalog and, through the Coinbase facilitator, in the wider x402 Bazaar where agent builders look for services. The cost side is built for the audit's reality that most sellers start small: a free allowance of roughly a thousand calls a month, then a flat per-call fee plus gas .

Two things to be clear about. First, this is per-call x402, the exact scheme — the right tool for priced-per-call services, which is the bulk of the market, and enough to become reachable by every agent stack that speaks x402: AWS AgentCore, Cloudflare Wallets, Coinbase for Agents, Binance's Agentic Wallet. Second, if your workload is a genuine channel case — inference by token, streaming data — Payzum today gets you paid per call while the channel tooling matures, and our roadmap follows the standards, not the other way round. On the ordinary stablecoin-acceptance side, Solana is one of the nine chains Payzum settles on, with confirmations around 0.4 seconds, so a Solana-native customer base is not a problem.

How it works, step by step

1. Create the mapping. In the Payzum dashboard, add a path, the HTTPS URL of your existing endpoint, a per-call price in USDC and the Base address that receives payments. Optionally mark it discoverable.
2. Publish the x402 URL. Payzum returns an address for the paid version of your endpoint. Share it, list it in the catalog, or add it to your docs. Your origin is untouched.
3. An agent calls, gets a 402, pays. The first request receives the price and payment details; the agent signs a USDC authorization on Base and retries. Payzum verifies it through the facilitator.
4. The paid call is proxied, the USDC lands in your wallet. Payzum forwards the request to your origin with your key, returns the response, and the payment settles to your address — no custody, no payout schedule. Signed webhooks tell your systems it happened.

Three kinds of API business, and what changes for each

The launch reads differently depending on what you sell.

• A data or lookup API (company enrichment, geocoding, tax rates, document parsing). Your calls are priced, not metered. Per-call x402 is the right fit today; a channel would add complexity without saving you anything. Expose the two or three endpoints agents actually want, at a price under the card-fee floor, and be findable.
• A model or compute host (fine-tuned models, embeddings, GPU jobs). You are the channel use case, and Alibaba Cloud just showed the shape of the demand. Start with per-call pricing on a coarse unit — per request, per thousand tokens rounded up — to be reachable now, and plan the channel integration for when one buyer's loop is worth the engineering.
• A SaaS with an API nobody buys separately. Agents are a new customer segment that will never fill in your signup form. A paid x402 URL on one useful endpoint is a low-risk way to find out what an agent will pay for, with the money landing in your own wallet and a free monthly allowance while you learn.

Per-call x402 vs Solana Payment Channels vs API keys with card billing

Fair objections

"If channels are the future, isn't per-call x402 a dead end?"

No — channels are built on x402 and MPP, not instead of them. The 402 handshake, the price in the response and the stablecoin settlement are the same; a channel changes how many calls one authorization covers. A seller reachable per call today is reachable by every agent stack that speaks the protocol, and adds a channel when a specific buyer's loop justifies it. Nothing about the URL, the price or the wallet changes.

"Half the volume is wash trading. Why sell to agents at all?"

Because the wash volume tells you where the speculation is, not where the buyers are. The Bitquery audit and the Artemis data both point to the same conclusion: the sellers who earned real money had a real endpoint, a sensible price and a reason for repeat calls. The cost of finding out whether your API is one of them is a dashboard mapping and a free monthly allowance, with the money landing in your own wallet rather than a processor's balance.

"Alibaba Cloud can afford the engineering. I can't."

That is precisely the gap this launch exposes, and why the seller side stays thin. You do not need the channel program to be payable by agents. You need a paid URL, a price and an address. That is a configuration, not a project.