EN
Română (Romanian)
Last checked: September 24, 2026. The field is evolving rapidly. In this article, we explicitly separate stable standards, available products, preview features, and areas that are still experimental.
Retail has become the first visible example of agentic commerce: a user asks an assistant to find a product, compare options, and prepare the purchase. But software may be an even better category for buying with the help or execution of AI agents.
SaaS products are already programmatic. They have APIs, plans, usage limits, credentials, recurring billing, and activation processes that can be automated. Many purchases are predictable, measurable, and can be canceled or resized. A programming agent can identify that an app needs a database, authentication, monitoring, and hosting. In certain ecosystems, that same agent can already compare providers, create resources, retrieve credentials, and pay within a delegated budget.
This doesn't mean the agent automatically becomes the contracting party or can accept any contract on behalf of the company. The individual or organization remains the holder of the purchase. The agent is a software delegate that can perform part of the process: discovery, evaluation, provisioning, payment, usage, and management.
A realistic thesis is more precise than a slogan: agents already buy units of software, such as browser sessions, API calls, and cloud resources, and can create and configure ensembles of SaaS services within delegated budgets. Fully autonomous contracting of a SaaS subscription is still rare, and in mature implementations is limited by authentication, contract terms, risk policies, and human approvals.
From here on, we use the technical term 'provisioning' for the creation, configuration, and automatic activation of a software resource.
A website optimized for people explains the benefits, displays prices, and steers the visitor toward a form or checkout—a process often called checkout. A product that can be bought by agents needs to provide the same information in a structured, executable form.
The agent needs to answer specific questions:
Therefore, an agent-ready product is not just an MCP server or a payment endpoint. It means a complete commercial flow, machine-readable and human-controllable.
An agentic SaaS transaction involves several roles. Their separation is crucial for security and accountability.
| Role | Responsibility |
|---|---|
| Purchase holder | The individual or organization defining the goal, budget, and policy |
| Purchasing agent | Discovers offers, compares, requests approvals, and performs permitted operations |
| Agent platform | Provides identity, execution environment, memory, controls, and logging |
| SaaS provider | Publishes the offer, verifies authorization, delivers the service, and provides support |
| Payment provider or digital wallet | Tokenizes the instrument, applies limits, and moves funds |
| Billing system | Measures usage, applies pricing, credits, and usage rights |
The agent can initiate the transaction but should not be confused with the account holder, contract signatory, or economic beneficiary. A healthy design keeps this link verifiable from intent to invoice.
An agent doesn’t need to manipulate a physical object. It can call an API, create a project, install an integration, or change a plan. Delivery can be confirmed by a structured response, a resource ID, and a credential.
An app exceeding a traffic threshold requires extra capacity. A pipeline starting to process documents needs OCR, storage, or inference. These needs can be detected before the user even opens a software catalog.
API calls, processing minutes, number of events, data volume, and sessions can all be metered. This enables budgets, caps, alerts, and unit pricing that an agent can evaluate.
In many cloud services, the result of a purchase is a resource created within seconds, not something delivered in days. The agent can immediately check if the resource works and meets the initial requirement.
A trial period can be closed, capacity reduced, and a key revoked. Still, reversibility shouldn’t be assumed: domain registration, sending email, moving data, and certain computations have effects or costs that cannot be undone. The authorization policy should reflect the real risk of the action.
The term “agentic” is used for very different products. A maturity scale helps prevent equating a chatbot that reads docs with an agent that can incur expenses.
| Level | Agent capability | Current examples |
|---|---|---|
| L0: discovery | Searches, reads, and compares offers | Structured docs, AWS Marketplace MCP (read-only) |
| L1: usage | Calls a service in a pre-configured account | Numerous MCP servers for email, databases, or observability |
| L2: provisioning | Creates projects, databases, branches, or integrations | Supabase MCP, Neon MCP, Vercel Marketplace CLI |
| L3: approved purchase | Prepares the transaction, a human approves the payment or terms | Stripe Link wallet, plan upgrades requiring confirmation |
| L4: delegated spend | Purchases within preapproved and logged limits | Stripe Projects and AgentCore Payments; MPP or x402 with spend limits; prepaid credits |
| L5: autonomous contracting | Chooses provider, accepts terms, and manages contract without intervention | No general, mature, verifiable example yet |
By September 2026, the market has credibly reached L3 and L4 for some products and risk levels. L5 isn’t required to build a valuable channel. For most SaaS platforms, the immediate opportunity is to become easy to evaluate, provision, and buy under a set company policy.
| Period | Notable development |
|---|---|
| April 2025 | Google introduces Agent2Agent (A2A) for interoperability between agents |
| May 2025 | Coinbase launches x402, a payment model based on HTTP 402 response |
| September 2025 | OpenAI and Stripe release the Agentic Commerce Protocol and Google introduces Agent Payments Protocol |
| March 2026 | A2A v1.0 becomes stable; Stripe and Tempo launch Machine Payments Protocol |
| April 2026 | AP2 v0.2 adds user-not-present flows and is donated to the FIDO Alliance |
| May 2026 | MPP introduces a subscription model, initially for stablecoin payments on Tempo |
| June 2026 | Stripe expands Projects, a service for discovery, provisioning, and spend control for programming agents |
| July 2026 | Linux Foundation announces the operational launch of the x402 Foundation |
| August 2026 | Amazon Bedrock AgentCore Payments becomes generally available and adds support for MPP |
The timeline shows a crucial shift. Early projects focused on connecting agents to tools and each other. The next wave adds offers, checkout, mandates, identity, payments, and spend control.
Confusion arises when MCP, A2A, ACP, AP2, MPP, and x402 are presented as direct alternatives. In reality, they operate at different layers.
| Layer | Examples | What it solves | What it doesn’t solve alone |
|---|---|---|---|
| Tools & context | MCP | Exposes functions, data, and resources to a model or agent | The commercial contract and payment |
| Inter-agent collaboration | A2A | Capability discovery, tasks, messages, and artifacts | Price, mandate, and settlement |
| Catalog & checkout | ACP, UCP | Products, cart, checkout, and commercial states | Full identity and payment infrastructure |
| Intent & authorization | AP2, mandates, internal policies | Proves what the purchase holder approved, and within what limits | Fund transfer and service delivery |
| Trust in agent | Visa TAP, certification mechanisms | Helps the merchant distinguish a legitimate agent from abusive automation | SaaS catalog and billing |
| Programmatic payment | MPP, x402, payment tokens | Negotiates and executes payment for a resource or API call | The full SaaS contract life cycle |
| Metering & billing | Stripe Billing, Metronome, Orb, Lago, Zuora | Usage, credits, thresholds, invoices, and rights | Discovery and delegation to agent |
A SaaS platform can use multiple layers in a single flow. For example, an agent may discover a capability via A2A, invoke a tool with MCP, present an AP2 mandate, and pay for usage with MPP. There is still no single universal protocol covering the whole process.
Agentic Commerce Protocol, developed by OpenAI and Stripe, describes how an agent and merchant can build and update a checkout. Delegated payment authorization is limited by merchant, amount, and period; the merchant remains the merchant of record—responsible for collecting payment, handling taxes, refunds, chargebacks, and support.
The protocol is open source, but the current spec is marked beta. Checkout can deliver digital goods but doesn’t define a native, complete object for SaaS subscriptions, usage rights, or recurring plan changes. Instant Checkout in ChatGPT is available to approved partners, not as a direct integration for any provider.
ACP is suitable for SaaS that sells a well-defined digital package. For a recurring, configurable product, it needs to be supplemented with billing, provisioning, identity, license management, and a clear cancellation process.
Stripe Projects is one of the most concrete examples of the idea that an agent can buy and configure software. The current documentation lists over 60 providers in hosting, databases, authentication, AI, observability, communication, and search. An agent compatible with MCP—including programming agents—can search the catalog, create or connect an account, provision a resource, sync credentials, and switch plan levels.
An official example is setting up a Next.js app with Supabase, Vercel, and PostHog. Projects provides global and per-provider limits, expense reports, separate environments, and purpose-limited credentials.
However, autonomy is still bounded. The user initially authenticates the Stripe account, connects provider accounts, and adds the payment method. Some actions and commercial terms require confirmation. Stripe Directory, the registry for service discovery by developers and agents, is marked as preview.
For programmatic consumption, Machine Payments Protocol defines a simple flow: the service responds with a payment request, the agent authorizes, repeats the call, and receives the resource with a receipt. The Stripe integration supports cards via Shared Payment Tokens and stablecoins. Published examples include Browserbase (pay-per-browser-session) and Parallel (pay-per-API-call). These are stronger proof of agentic software purchasing than a typical retail demo, because payment and delivery happen directly in the technical flow.
MPP supports one-time, usage-based, and subscription payments. Concrete support, however, varies based on payment infrastructure and provider. Stripe docs focus mainly on per-call payments; MPP subscriptions started with stablecoins on Tempo. It’s incorrect to assume any recurring card subscription is already interoperable via protocol.
x402 reuses HTTP code 402 as a commercial signal. The server describes the required payment, the client attaches proof, a facilitator verifies and settles, and the server delivers the response. The protocol originated in the Coinbase ecosystem and later moved under the governance of the x402 Foundation, part of the Linux Foundation.
The model suits API calls, data, content, inference, and MCP tools. Cloudflare documents flows where agents discover, pay for, and consume protected resources via x402 or MPP. Its plugins for developer tools can detect a 402 response, pay, and retry the call, including automatically when the policy allows.
Cloudflare has also announced Monetization Gateway for edge charging of pages, data, APIs, and MCP tools. At the time of this analysis, the product is available via waitlist and early access, so it should be seen as a product direction, not general availability.
x402 does not, however, replace a full commercial system. Current implementations are mainly tied to digital wallets, stablecoins, and facilitators. The protocol does not itself solve for taxes, contracts, refunds, payment disputes, enterprise purchases, or supplier verification. Moreover, status 402 is reserved in the HTTP standard, and x402 remains an application-level convention, not a finalized IETF extension to the HTTP protocol.
Universal Commerce Protocol describes discovery, checkout, and post-purchase operations. It's especially relevant for retail and marketplaces, but catalog primitives, capability negotiation, and identity binding can also inspire software products with standardized offerings.
Agent Payments Protocol is not a payment infrastructure. It provides verifiable proofs of intent and authorization. Version 0.2 uses Checkout Mandates and Payment Mandates, open or closed. These can restrict recipients, instruments, amount, cumulative budget, date, frequency, and recurrence count. They're suitable primitives for renewals, add-on licenses, and automatically-enabled capacity.
AP2 remains a developing standard, currently in the FIDO Alliance process. Catalog, commercial negotiation, settlement, and legal dispute rules are out of scope. In a SaaS architecture, AP2 can prove authorization, but money is moved by a separate processor or infrastructure.
A2A is stable at version 1.0 and allows agents to publish functions, exchange tasks, and deliver artifacts. Its core does not define pricing or payments. The A2A x402 extension adds an optional commercial flow, but is still at version 0.1 and is not part of A2A's core compatibility.
Amazon Bedrock AgentCore Payments is generally available starting August 18, 2026. The service provides integration with digital wallets, spend limits, and observability for payments to APIs, MCP servers, and other agents, and supports both x402 and MPP. AgentCore enforces payment policy close to the agent's runtime environment, where session-level budgets can be enforced and transactions audited.
AWS Marketplace MCP, by contrast, only provides read-only commercial tools for search, comparison, and proposals. It should not be presented as stand-alone checkout. A custom agent may be granted IAM permissions for Marketplace operations separately, but this is a client-built delegation, not a current MCP server capability.
Payment networks are building the trust layer needed for a merchant to accept an agent without confusing it with an abusive bot. Visa Trusted Agent Protocol is focused on agent identification and verification. Visa Intelligent Commerce extends tokenization and credential control into agent flows.
Mastercard Agent Pay uses tokens and registered agents. The 2026 announcements also include machine-to-machine flows, but major public examples remain controlled pilots, not universal availability on any SaaS platform.
PayPal Agentic Commerce connects merchants to multiple agentic surfaces, keeping checkout and processing within a familiar infrastructure. The value these providers offer is interoperability with existing payments, card data protection, and risk mechanisms. None eliminate the need for a technical catalog, provisioning, and SaaS product-specific policies.
An agent cannot optimize a cost the provider cannot measure. Platforms like Stripe Billing, Metronome, Orb, Lago and Zuora offer combinations of metering, prepaid credits, thresholds, commitments, alerts, and usage-based invoicing.
These systems alone do not make a product agent-purchasable. But they make a critical promise possible: the agent can see marginal cost, balance, usage, and limit before extending consumption.
By 2026, the ecosystem has moved beyond lab demonstrations: real payments, agentic provisioning, and controlled transactions exist in production infrastructure. Still, 'in production' does not automatically mean general availability. Access may depend on region, partner, payment method, agent certification, and supplier integration.
Vercel lets agents discover, install, and manage Marketplace integrations via CLI. An agent can add Neon, Upstash, or other services, create the resource, and attach it to a project. For paid plans or first-time acceptance of terms, user authorization may be required. This is an example of mature provisioning with governed purchase, not fully autonomous contracting.
MCP servers can create projects, databases, and branches via OAuth and APIs. Supabase even exposes tools to estimate and confirm costs. Its official recommendation is still to keep human approval for sensitive operations. These integrations demonstrate L2—provisioning on an authorized account, not necessarily purchasing a new subscription.
Replit brokers third-party services, like search or media generation, without the user configuring every API key. Usage is deducted from Replit credits at the provider’s rates. The model shows how a platform can aggregate agent demand and turn multiple APIs into a single prepaid budget.
Cloudflare documents automatic payment for x402 and MPP resources, after the user configures the digital wallet and policy. Browserbase sells browser sessions via MPP, while Parallel sells API calls. These cases closely approach the native form of a software marketplace between agents: structured offering, unit price, authorization, immediate delivery, and receipt.
Not every product needs the same infrastructure. The choice depends on transaction value, frequency, reversibility, and client type.
| Method | Suitable for | Advantage | Main limitation |
|---|---|---|---|
| Existing checkout, agent-initiated | Subscriptions and standard plans | Reuses current PSP, fees, and billing | Often requires human confirmation |
| Marketplace with centralized billing | Integrations and complementary infrastructure | Trust, distribution, and a single invoice | Dependency on platform rules |
| MPP | APIs, sessions, jobs, and digital resources | Cards or stablecoins, receipts, HTTP/MCP integration | New ecosystem, inconsistent support across payment infrastructures |
| x402 | API micropayments and digital content | Simple, automated flow, no separate account at each service | Today mainly uses digital wallets and stablecoins |
| Prepaid credits | Repetitive usage and strict budget control | Known max cost, reduced overage risk | Provider manages balance and expiration |
| Enterprise contract with delegated orders | Expensive or regulated services | Negotiated terms, approved vendor list, consolidated invoicing | Slower initial integration |
For many B2B companies, the most realistic path is not a new payment for every call. The company approves a vendor and contract once, and the agent gets the right to create resources or consume within those limits. Operational autonomy increases, while legal procurement stays controlled.
An agent can more easily compare offers with a clear unit, calculable price, and explicit limits.
Suitable for data, search, verification, and atomic functions. The price should clearly define what constitutes a successful call, how retries are handled, and whether failed responses are billed.
Works for browsing, rendering, analysis, or document processing. The unit is closer to the desired result than a single technical call.
Tokens, CPU seconds, gigabytes, events, or minutes. The agent needs estimates before execution and near-real-time telemetry, otherwise it cannot respect a budget.
The purchaser allots a balance, and the agent consumes it without accessing the payment instrument every time. It’s a simple model for test environments, teams, and workloads with controllable risk.
The plan covers an included volume, with extra usage billed. The agent must be able to automatically compare upgrade versus overage, and not change plans without proper policy.
Attractive but more difficult. Both provider and client need a verifiable outcome definition, clear attribution, and clarity on partial results. Without a deterministic definition, disputes arise that an agent cannot resolve alone.
Regardless of the model, the offer should expose the effective price, currency, known fees, limits, quote expiration date, and maximum authorizable cost. Terms like “contact us” or “from” block automatic comparison.
The pricing page is still useful for humans, but agents need structured data. A complete offer should include at least:
There’s no universal format for such offers yet. Information can be published today via OpenAPI, JSON Schema, structured docs, MCP resources, A2A Agent Cards, or a marketplace’s schema. What matters is that the commercial offer and technical contract don’t contradict each other.
A robust flow can be broken down into ten steps:
The order may vary. For micropayments, payment and delivery happen in the same HTTP exchange. For enterprise, the contract and provider are pre-approved, and the agent executes only orders within the agreement.
Publish capabilities, schemas, versions, and examples in a format an agent can query. Use stable names and descriptions that do not rely on marketing interpretation.
Before a paid operation, the agent must be able to obtain the estimated cost, maximum cost, period, and terms. An expired quote must be rejected—not silently recalculated at a higher price.
Separate the purchaser's identity, the agent's identity, and the platform's identity. Use OAuth, tokens with limited permissions, short expiration, and resource-, value-, and action-based policies.
A retry must not create two subscriptions or two clusters. Operations must support idempotency keys and return the state of an existing order.
The agent should not receive a master key when it only needs to write to a project. Credentials must have defined permissions, duration, and environment, and must be rotatable or revocable.
The system must know what the customer purchased, how much they have consumed, and what they can use. Balances and limits must be programmatically available, not just in a dashboard.
Implement limits per transaction, per day, per agent, project, and provider. Add rate limits, allowlists, blocking after anomalies, and extra approvals for irreversible actions.
Every decision must be reconstructable: the initial request, the offer seen, version of terms, approval, instrument used, delivered resource, and consumption. Technical logs aren't enough unless they can be linked to the business transaction.
Expose clear operations for cancellation, downgrade, revocation, and refund. When automation can't decide, the agent must be able to open a case and transfer context to support.
A document, website, or even a tool description can attempt to persuade the agent to ignore policy and buy a service. Provider content must be treated as untrusted data. The payment decision must be validated by deterministic code, not just a language model.
The agent has legitimate access to money and resources, but is induced to use them for a purpose other than approved. Scopes must be tied to beneficiary, resource, value, and time window.
An automatic retry, a faulty scaling mechanism, or two agents reactivating each other can quickly generate costs. Cumulative limits, rate limits, circuit breakers, and alerts before budget exhaustion are necessary.
Payment messages can be retransmitted, and timeouts may make the agent repeat the order. Use nonces, expiration, signatures, idempotency keys, and reconciliation between payment and delivered resource.
The agent may evaluate one offer and execute another if the price or terms change mid-process. The quote must be versioned and locked for a clear period. Any material difference requires new authorization.
An agent working for multiple projects may send a credential in the wrong context. Use vaults, ephemeral tokens, environment separation, and explicit tenant checks.
An open catalog may include services imitating a brand or promising capabilities they don't have. Verify identity, sign metadata, track evaluation provenance, and conduct independent tests as part of distribution.
An agent may easily activate a trial, but may fail to cancel. The offer must describe recurrence, next charge date, and closure steps in the same format as purchase.
These risks align with the NIST document on software and AI agent identity and authorization and with the OWASP Top 10 for Agentic Applications 2026. Identity and delegation standards are still forming, so local policy control remains mandatory.
There is no need to start with a new payment protocol. For many products, the biggest early improvement comes from structured pricing, secure provisioning, and the ability to cancel via API.
Classic conversion metrics are not enough. Also track:
An integration can have many calls and little value. The right measure is whether the agent enables the client to achieve their goal faster and more safely, at a predictable cost.
In a traditional marketplace, the product page wins attention. In an agentic ecosystem, the schema, price, and success rate can drive selection. Documentation and telemetry become part of merchandising.
A programming agent can select a database for a small project, an authentication service for current needs, and observability for the production environment. If integration is secure and reversible, providers can win customers exactly at the moment of need.
A very good API, though not widely known, can be chosen if it is easy to find, test, and purchase. Directories and marketplaces for agents may reduce the exclusive advantage of a brand, but will increase the importance of technical reputation and measured reliability.
Agents favor comparable offers. This can accelerate the move from rigid per-user licenses to consumption, credits, and units tied to outcomes. The per-user model won’t disappear, but it will coexist with budgets allocated to agents and workloads.
When the agent sees the cost before taking action, it can choose a plan, postpone a task, or use an already approved provider. Procurement is no longer merely a pre-usage process, but an ongoing policy in execution.
If most customers arrive through a directory, a programming agent, or a marketplace, that platform controls ranking, data, and the payment relationship. SaaS providers must win agentic distribution without surrendering the relationship with the purchase holder entirely.
Despite the rapid pace, several issues remain open:
This list does not negate the opportunity. It defines the product that must be built around payments.
SaaS platforms should not wait for a 'universal agent shopping browser' to appear. The immediate advantage comes from a simpler foundation:
The goal is not maximum autonomy. The goal is useful delegation: the agent can act swiftly where rules are clear and stop where a human decision is needed.
The next software buyer might be an agent, but the agent won’t buy like a person. It won’t be convinced by a headline, nor will it patiently fill out a sales form. Instead, it will seek verifiable capabilities, calculable pricing, explicit authorization, programmatic provisioning, and proof that the service delivered the promised outcome.
The necessary infrastructure exists in pieces already: MCP and A2A for interaction, ACP and UCP for commercial experiences, AP2 and network schemes for authorization and trust, MPP and x402 for programmatic payments, plus mature billing and metering systems. State of the art is not an agent freely signing any contract. It’s an agent that buys and manages software within set boundaries, with traceability and the possibility for human intervention.
For a SaaS provider, now is the right time to become agent-ready. Companies that structure their offerings, automate provisioning, and build spend control will be easier to choose both for humans and for the software working on their behalf.
If you run a SaaS platform and want to assess how ready it is for software buyers, contact us. We can review the offer, APIs, provisioning, authorization, and cost controls, then define a realistic sequence of implementation steps.