Payment Rails for AI Agents
How money moves when software, not humans, is making the purchase decision
Why Traditional Rails Break
Traditional payment infrastructure was designed for a simple assumption: a human standing at a checkout counter, or a human sitting at a computer, initiates a payment. The entire system, from card networks to fraud detection to authorisation, is built around this assumption. Agentic commerce invalidates it.
The problems are structural, not incremental.
The Credential Trust Problem
In traditional commerce, possession of a credential (card number, CVV, billing address) is treated as a trust signal. If someone has your card details, the system assumes they are authorised to use them. Fraud systems look for anomalies, but the baseline is trust-by-possession.
In agentic commerce, the agent always has the credentials. It was given them deliberately. The question is not whether the agent can pay, but whether this specific transaction, at this specific amount, for this specific merchant, is what the consumer authorised. Credential possession tells you nothing.
The Micro-Transaction Problem
A single AI agent conversation can trigger hundreds of micro-activities: API calls, token processing, tool invocations, each with sub-cent costs. Traditional payment processors impose minimum fees per transaction (typically $0.05 to $0.15 plus a percentage). At those economics, micro-transactions are impossible. A $0.003 API call cannot bear a $0.30 processing fee.
This is not an edge case. It is the core economic model of agent-to-agent commerce. When agents negotiate with other agents, access paid APIs, or consume compute resources on behalf of users, the transaction volume is high and the individual amounts are tiny. Traditional rails were never designed for this.
The Speed Problem
AI agents need payment confirmation in milliseconds, not days. A 2-3 day ACH settlement cycle is meaningless to an agent that needs to confirm a purchase before proceeding to the next step in a workflow. Even real-time payment systems designed for human use cases operate at latencies that create friction in automated flows.
The Pull vs. Push Problem
Card payments use a "pull" model. The merchant pulls money from your account. This requires the merchant to have your credentials, and the system must verify authorisation on every pull. Stablecoin and crypto rails use a "push" model. The payer sends money directly. No credential sharing required. Early indicators suggest AI agents and stablecoins could displace 20 percent of traditional card-based settlement volume by the end of 2026.
Stripe Shared Payment Tokens
Stripe built Shared Payment Tokens (SPTs) in late 2025 specifically for agentic commerce. They have rapidly become the default primitive for agent-initiated payments, with adoption by Etsy, URBN (Anthropologie, Free People, Urban Outfitters), and expanding integration with every major payment method.
How SPTs Work
An SPT is a programmable, scoped, reusable token that lets an AI agent initiate a payment using a consumer's preferred payment method without exposing the underlying credentials. Here is the flow:
- The consumer authorises an AI agent to shop on their behalf and selects a payment method.
- Stripe issues an SPT that encodes the consumer's permission: which payment method, what spending limits, which merchants, what expiration.
- The AI agent presents the SPT to a seller's Stripe account when making a purchase.
- Stripe validates the SPT against the consumer's current permissions and processes the payment.
- The seller receives payment through their normal Stripe integration. No additional setup required.
Stripe designed SPTs to meet five requirements: programmable (sellers can limit by time or amount), scoped (permissions are specific, not blanket), reusable (one token can support multiple transactions), interoperable (works across different agent platforms), and secure (credentials never leave Stripe's infrastructure).
The Multi-Rail Expansion
In early March 2026, Stripe expanded SPTs to support four additional payment rails: Visa agentic network tokens, Mastercard agentic network tokens, Klarna BNPL, and Affirm BNPL.
This makes Stripe the first and only provider supporting both agentic network tokens and BNPL tokens through a single primitive. For merchants already on Stripe, these payment methods are automatically available in agentic flows without additional integration.
Stripe's multi-rail SPT strategy creates a powerful lock-in effect. If you are a merchant on Stripe, every new payment method Stripe adds to SPTs is automatically available to your agent-initiated transactions. The switching cost is not just Stripe's payment processing. It is access to the widest agentic payment ecosystem.
Agentic Network Tokens
Both Visa and Mastercard have developed their own agentic token infrastructure, deployed in partnership with Stripe.
How They Differ from SPTs
SPTs are Stripe's abstraction layer. They provide a unified interface regardless of the underlying payment method. Agentic network tokens are the network-level credentials that sit underneath. When an agent uses an SPT backed by a Visa agentic network token, two layers of infrastructure are working together:
The SPT handles the agent-to-merchant authorisation: is this agent allowed to buy from this merchant, up to this amount?
The network token handles the card-level authentication: is this a legitimate credential, issued by the right network, with valid authorisation from the issuer?
For merchants, the distinction is mostly invisible. You interact with SPTs. Stripe handles the complexity of provisioning network tokens behind the scenes. But for payments architects, understanding this layering is important for risk assessment and dispute resolution.
The Network Advantage
Network tokens carry the trust of the card networks themselves. Visa's agentic network tokens are backed by the same security, performance, and protections that merchants rely on for every other card transaction. This means established fraud detection, chargeback processes, and dispute resolution all apply. For merchants evaluating agentic payment risk, network tokens provide a familiar liability framework.
BNPL in the Agent Era
The integration of Klarna and Affirm into Stripe's SPT framework reflects a structural concern: AI agents, left to their defaults, route transactions through stored card credentials. BNPL providers are fighting to remain in the checkout.
The Exclusion Risk
Klarna's Chief Commercial Officer David Sykes framed the problem directly: AI shopping agents have been defaulting to card-on-file payments by design, effectively freezing out alternative payment methods including BNPL from automated checkout flows. If BNPL is not programmatically available in the agent's decision environment, it will not be offered to the consumer.
This is a distribution problem disguised as a technology problem. BNPL is now table stakes for online payments acceptance. But in agentic commerce, being "available" is not enough. You must be available in the protocol the agent speaks.
The Protocol Race
Klarna is pursuing a multi-protocol strategy: Stripe SPTs for AI agent checkout, Google AP2 for expanded partnership, and its own Agentic Product Protocol making products discoverable by AI agents. Affirm is pursuing a similar approach through Stripe SPTs and Google's AP2 and UCP protocols.
Both companies understand that protocols are the new distribution rails. Get embedded at the protocol level or get left out. For issuers and acquirers, the strategic implication is clear: if your payment option is not programmatically available in the agent's decision environment, it will not be presented to the consumer. Period.
Crypto Rails: The Agent-Native Alternative
Traditional card rails use a pull model designed for humans. Crypto rails use a push model that may be better suited to machine-to-machine commerce.
x402: Money as Native to HTTP
Coinbase's x402 protocol treats money as native to HTTP, the same protocol that powers the internet. When an agent calls a paid API, it sends payment atomically with the request. No account creation. No card details. No authorisation wait. The payment is embedded in the HTTP request itself.
Conditional logic is built into the transaction. A smart contract can hold funds in escrow and release them only when predefined conditions are met. This programmable money is impossible with card rails, which can only authorise fixed amounts at a single point in time.
Circle Nanopayments
Circle's Nanopayments enable gasless USDC transfers by bundling small payments into a single on-chain transaction. This reduces per-transaction cost to effectively zero, enabling payments as small as $0.000001. Settlement occurs on any Gateway-supported EVM chain following the x402 standard.
For AI agents transacting at high frequency in sub-cent amounts, Nanopayments eliminate the cost friction that makes traditional rails uneconomical. The use cases are specific: API marketplace payments, compute resource billing, data access fees, agent-to-agent service payments.
The Economics
The numbers make the case:
| Rail | Settlement Time | Cost Per Transaction |
|---|---|---|
| Blockchain (Layer 2) | Under 500 milliseconds | Below $0.001 |
| Traditional card processing | 1-3 days | $0.05 to $0.15 minimum |
Ethereum Layer 2 transaction costs have fallen from approximately $24 in 2021 to less than one cent today, a 2,400x reduction. Stablecoin transaction volumes reached $46 trillion last year, with network capacity at 3,400 transactions per second.
When to Use Which Rail
The choice of payment rail depends on the use case, transaction characteristics, and consumer expectations:
New Pricing Models
Agentic commerce does not just change how payments are processed. It changes how services are priced. Traditional subscription and per-license models do not align with agent consumption patterns.
Usage-Based Pricing
Cost-inferred, pay-per-request with margin built in. Example: $0.0003 per token plus 20 percent margin. The agent consumes exactly what it needs and pays for exactly what it uses. This is the dominant model for AI-to-AI services. Finance teams get precise tracking. Usage-based pricing is natural for crypto rails and micro-transaction infrastructure.
Outcome-Based Pricing
Charging for results rather than resources. The agent pays only when it achieves a specific, verifiable result: a completed booking, a resolved support ticket, a qualified lead. This aligns incentives between the agent service provider and the consumer. Requires robust measurement infrastructure but creates the strongest alignment.
Value-Based Pricing
Capturing a percentage of the ROI generated. If an agent saves a business $10,000 through automated procurement optimisation, the service takes a percentage of the savings. This model requires robust measurement infrastructure but creates the strongest alignment.
Credit Systems
Prepaid credit systems solve the reconciliation problem. Instead of processing hundreds of sub-cent charges, users purchase credits that agents burn down in real time. Finance teams get trackable recurring billing. Users get predictable spend with real-time burn rate monitoring. Credits can be reallocated across users, departments, or agents without renegotiating licences.
For your products and services, which payment rail would your agents naturally prefer to use, and what would you need to change to make that possible?
Key Takeaways
- Traditional rails break: Card infrastructure assumes human-initiated transactions. Credential-as-trust, minimum fees, slow settlement, and pull-model architecture all fail in agentic commerce.
- SPTs are the default: Stripe's Shared Payment Tokens are programmable, scoped, and reusable. They now support Visa/MC network tokens and Klarna/Affirm BNPL through a single primitive.
- BNPL must embed in protocols: AI agents default to card-on-file. Payment methods not programmatically available in the agent's environment will be excluded from checkout.
- Crypto enables micro-transactions: x402 and Circle Nanopayments enable sub-cent payments at machine speed. Best suited for agent-to-agent and compute markets.
- Pricing models are changing: Usage-based, outcome-based, and value-based pricing replace subscriptions. Credit systems solve the reconciliation problem.