---
title: "The next software buyer might be an agent. How can SaaS platforms sell to AI agents"
description: "Guide to SaaS for AI agents: discovery, provisioning, programmatic payments, vendors, pricing, security, and implementation steps."
canonical: https://i8.ro/en/blog/how-can-saas-platforms-sell-to-ai-agents
---

# The next software buyer might be an agent. How can SaaS platforms sell to AI agents

> Guide to SaaS for AI agents: discovery, provisioning, programmatic payments, vendors, pricing, security, and implementation steps.

Source: https://i8.ro/en/blog/how-can-saas-platforms-sell-to-ai-agents

> **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 could be an even more suitable category for agent-assisted or AI agent-executed buying.

SaaS products are already programmatic. They have APIs, plans, consumption 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 when an app needs a database, authentication, monitoring, and hosting. In some ecosystems, the 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 purchaser. The agent is a software delegate that can perform part of the process: discovery, evaluation, provisioning, payment, usage, and administration.

The realistic thesis is more accurate than the slogan: **agents already purchase software units like browser sessions, API calls, and cloud resources, and can create and configure SaaS service assemblies within delegated budgets. Fully autonomous contracting of a SaaS subscription remains rare, and in mature implementations, it’s limited by authentication, contract terms, risk policies, and human approvals.**

We’ll continue to use the technical term ‘provisioning’ for the automatic creation, configuration, and activation of a software resource.

## What does it actually mean to ‘sell to an agent’

A website optimized for humans explains the benefits, displays prices, and guides the visitor to a form or to completing checkout. A product purchasable by agents needs to provide the same information in a structured, executable format.

The agent must be able to answer concrete questions:

- What problem does the product solve and what capabilities does it offer?
- Can it be used in the required region, industry, and architecture?
- What is the total cost for the estimated usage?
- What data does the provider receive and how is it processed?
- Which plan, limits, SLAs, and retention policies apply?
- How is authorization granted and within what budget can the agent operate?
- How does it create the resource and receive purpose-limited credentials?
- How does it check the result, consumption, invoice, and receipt?
- How does it reduce capacity, cancel the service, or request a refund?
- When should it halt the flow and request human intervention?

Therefore, an agent-ready product doesn’t just mean an MCP server or payment endpoint. It means a full commercial pathway, machine-readable and human-controllable.

## Who buys and who is responsible

An agentic SaaS transaction involves multiple roles. Separating them is important for security and accountability.

| Role | Responsibility |
| --- | --- |
| Purchaser | The person or organization defining the objective, budget, and policy |
| Buying agent | Discovers the offering, compares, requests approvals, and executes permitted actions |
| Agent platform | Provides identity, execution environment, memory, controls, and logging |
| SaaS provider | Publishes the offer, checks authorization, delivers the service, and offers support |
| Payment provider or digital wallet | Tokenizes the instrument, enforces 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 sound design keeps this relationship verifiable from intent to invoice.

## Why SaaS is a suitable category for agentic commerce

### 1. The product is already accessible through software

An agent does not need to manipulate a physical object. It can call an API, create a project, install an integration, or modify a plan. Delivery can be confirmed via a structured response, a resource identifier, and a credential.

### 2. Demand can be anticipated

An application exceeding a traffic threshold needs additional capacity. A pipeline starting to process documents needs OCR, storage, or inference. These needs can be detected before the user opens a software catalog.

### 3. Consumption is measurable

API calls, processing minutes, event counts, data volumes, and sessions can all be tracked. This property enables budgets, caps, alerts, and unit pricing that an agent can evaluate.

### 4. Provisioning can be fast

With many cloud services, the result of a purchase is a resource created in seconds, not a delivery after several days. The agent can immediately check if the resource is functional and if it meets the initial requirement.

### 5. Many decisions can be reversible

A test period can be shut down, capacity reduced, and a key revoked. However, reversibility should not be assumed. Registering a domain, sending an email, transferring data, and some compute operations generate effects or incur costs that cannot be undone. The authorization policy must reflect the true risk of the action.

## From documentation to purchase: six levels of maturity

The term “agentic” is used for very different products. A maturity scale prevents equating a chatbot that reads documentation with an agent capable of incurring expenses.

| Level | Agent capability | Current examples |
| --- | --- | --- |
| L0: discovery | Searches for, reads, and compares offers | Structured documentation, AWS Marketplace MCP read-only |
| L1: usage | Calls a service in an already-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, and a human approves payment or terms | Stripe Link wallet, upgrades to higher tiers requiring confirmation |
| L4: delegated spending | Purchases within pre-approved and logged limits | Stripe Projects and AgentCore Payments; MPP or x402 together with spending caps; prepaid credits |
| L5: autonomous contracting | Chooses the provider, accepts terms, and manages the contract without intervention | There is not yet a general, mature, and verifiable example |

By September 2026, the market had credibly reached L3 and L4 for certain products and risks. L5 is not a necessary condition to build a valuable channel. For most SaaS platforms, the near-term opportunity is to become easy to evaluate, provision, and purchase within a company-set policy.

## How we got here: a short timeline

| Period | Relevant development |
| --- | --- |
| April 2025 | Google introduces Agent2Agent, A2A, for agent interoperability |
| May 2025 | Coinbase launches x402, a payment model based on HTTP 402 response |
| September 2025 | OpenAI and Stripe publish Agentic Commerce Protocol, and Google introduces Agent Payments Protocol |
| March 2026 | A2A v1.0 becomes stable, and Stripe and Tempo launch Machine Payments Protocol |
| April 2026 | AP2 v0.2 adds user-not-present flows and is donated to FIDO Alliance |
| May 2026 | MPP introduces a subscriptions model, initially for stablecoin payments on Tempo |
| June 2026 | Stripe expands Projects, a discovery, provisioning, and spend control service for programming agents |
| July 2026 | Linux Foundation announces the operational launch of x402 Foundation |
| August 2026 | Amazon Bedrock AgentCore Payments becomes generally available and adds support for MPP |

The timeline highlights a major shift. Early projects solved agent connection to tools and other agents. The next wave adds offers, checkout, mandates, identity, payments, and spend control.

## The protocols do not solve the same problem

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 does not solve alone |
| --- | --- | --- | --- |
| Tools and context | MCP | Exposes functions, data, and resources to a model or agent | Commercial contract and payment |
| Agent collaboration | A2A | Discovery of capabilities, tasks, messages, and artifacts | Pricing, mandate, and settlement |
| Catalog and checkout | ACP, UCP | Products, cart, checkout, and commercial states | Full identity and payment infrastructure |
| Intention and authorization | AP2, mandates, internal policies | Proves what the purchaser approved and within what limits | Transfer of funds and service delivery |
| Agent trust | 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 call | The full SaaS contractual cycle |
| Metering and billing | Stripe Billing, Metronome, Orb, Lago, Zuora | Usage, credits, thresholds, invoices, and entitlements | Discovery and delegation to the agent |

A SaaS platform can use multiple of these layers within the same flow. For example, an agent might discover a capability via A2A, invoke a tool via MCP, present an AP2 mandate, and settle consumption via MPP. There is not yet a single universal protocol that covers the entire process.

## State of the art as of September 2026

### OpenAI and ACP: delegated checkout, but not yet a universal SaaS subscription

[Agentic Commerce Protocol](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol), developed by OpenAI and Stripe, describes how an agent and a merchant can build and update a checkout flow. Delegated payment authorization is limited to the merchant, amount, and period, and the merchant remains the merchant of record responsible for collecting payments, taxes, refunds, chargebacks, and support.

The protocol is open source, but the current specification is marked beta. Checkout can deliver digital products, but doesn't yet define a complete native object for SaaS subscriptions, entitlements, or recurring plan changes. Instant Checkout in ChatGPT is available to approved partners, not for direct integration by any provider.

ACP is relevant for SaaS selling a well-defined digital bundle. For a recurring, configurable product, ACP must be supplemented with billing, provisioning, identity, license management, and a clear cancellation cycle.

### Stripe: one of the most complete current flows for software providers

[Stripe Projects](https://docs.stripe.com/projects) is one of the most concrete examples of the idea that an agent can purchase and configure software. The current documentation lists over 60 providers for hosting, databases, authentication, AI, observability, communication, and search. An MCP-compatible agent, including a programming agent, can search the catalog, create or connect an account, provision a resource, sync credentials, and change plan tiers.

An official example is setting up a Next.js app with Supabase, Vercel, and PostHog. Projects offers both global and per-provider limits, expense reports, separate environments, and limited-scope credentials.

Nonetheless, autonomy is bounded. The user must initially authenticate the Stripe account, link the providers’ accounts, and add the payment method. Some actions and commercial terms require confirmation. [Stripe Directory](https://docs.stripe.com/directory), a registry for discovering services by developers and agents, is in preview.

For programmatic consumption, [Machine Payments Protocol](https://mpp.dev/) defines a simple flow: the service responds with a payment request, the agent authorizes, repeats the call, and receives the resource along with a receipt. Stripe’s integration supports card payments using Shared Payment Tokens and stablecoins. Public examples include Browserbase, with per-browser-session payment, and Parallel, with per-API-call payment. These provide stronger evidence of agentic software purchases than a retail demo, as payment and delivery happen directly within the technical flow.

MPP offers one-time, usage-based, and subscription models. Actual support, however, varies depending on payment infrastructure and provider. Stripe documentation mainly details per-call payments, and MPP subscriptions started with stablecoins on Tempo. It is not accurate to assume that any recurring card subscription is already interoperable via the protocol.

### x402: native payment for APIs and digital resources

[x402](https://www.x402.org/) reuses the HTTP 402 code 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 started in the Coinbase ecosystem and later came under the x402 Foundation’s governance within the Linux Foundation.

The model fits API calls, data, content, inference, and MCP tools. [Cloudflare](https://developers.cloudflare.com/agents/tools/payments/) documents flows where agents discover, pay for, and consume resources protected via x402 or MPP. Its plugins for programming tools can detect a 402 response, pay, and replay the call, including automatically when policy allows.

Cloudflare has also announced Monetization Gateway for edge-billing of pages, data, APIs, and MCP tools. At the time of this analysis, the product is available via waitlist and early access, meaning it is a product direction rather than generally available.

However, x402 does not replace a complete commercial system. Current implementations are mainly tied to digital wallets, stablecoins, and facilitators. The protocol does not by itself resolve taxes, contracts, refunds, chargebacks, enterprise purchases, or provider verification. Additionally, HTTP status 402 is reserved in the standard, and x402 remains an application convention, not a finalized IETF extension of the HTTP protocol.

### Google: UCP, AP2, and A2A

[Universal Commerce Protocol](https://github.com/Universal-Commerce-Protocol/ucp) describe discovery, checkout, and post-purchase operations. This applies especially to retail and marketplaces, but catalog primitives, capability negotiation, and identity linking can also inspire software products with standardized offerings.

[Agent Payments Protocol](https://ap2-protocol.org/) is not a payment infrastructure. It provides verifiable proof of intent and authorization. Version 0.2 uses Checkout Mandates and Payment Mandates, open or closed. These can restrict beneficiaries, instruments, amount, cumulative budget, date, frequency, and number of recurrences. They are suitable primitives for renewals, add-on licenses, and automatically activated capacity.

AP2 remains a developing standard, currently in the FIDO Alliance process. The catalog, business negotiation, settlement, and legal rules for disputes are outside its scope. In a SaaS architecture, AP2 can prove authorization, but a separate processor or infrastructure actually moves the money.

[A2A](https://a2a-protocol.org/) is stable at version 1.0 and lets agents 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 it’s still at version 0.1 and not part of basic A2A compatibility.

### AWS: governance and payments in agent infrastructure

[Amazon Bedrock AgentCore Payments](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments.html) is generally available from August 18, 2026. The service offers integration with digital wallets, spending limits, and payment observability for APIs, MCP servers, and other agents, supporting both x402 and MPP. AgentCore enforces payment policy near the agent’s runtime, where budgets can be imposed per session and transactions can be audited.

AWS Marketplace MCP, on the other hand, has only read-only commercial tools for discovery, comparison, and proposals. It should not be presented as standalone checkout. A custom agent may separately receive IAM permissions for Marketplace actions, but this is client-constructed delegation, not a capability of the MCP server itself.

### Visa, Mastercard, and PayPal: identity, tokenization, and acceptance

Payment networks build the trust layer that lets a merchant accept an agent without confusing it for an abusive bot. [Visa Trusted Agent Protocol](https://developer.visa.com/capabilities/trusted-agent-protocol) aims to identify and verify agents. Visa Intelligent Commerce extends tokenization and credential control into agent flows.

[Mastercard Agent Pay](https://www.mastercard.com/news/press/2025/april/mastercard-unveils-agent-pay/) uses tokens and registered agents. 2026 announcements also include machine-to-machine flows, but significant public examples remain controlled pilots, not universal availability for any SaaS platform.

[PayPal Agentic Commerce](https://developer.paypal.com/docs/agentic-commerce/) connects merchants to multiple agentic surfaces, keeping checkout and processing within a known infrastructure. The value of these providers is interoperability with existing payments, card data protection, and risk mechanisms. None eliminates the need for a technical catalog, provisioning, or SaaS-specific product policies.

### Metering and billing: the less visible foundation

An agent can’t optimize a cost the provider can’t measure. Platforms like [Stripe Billing](https://docs.stripe.com/billing/subscriptions/usage-based), [Metronome](https://docs.metronome.com/), [Orb](https://docs.withorb.com/), [Lago](https://doc.getlago.com/) and [Zuora](https://knowledgecenter.zuora.com/) offer combinations of metering, prepaid credits, thresholds, commitments, alerts, and usage-based billing.

These systems alone do not make a product agent-purchasable. What they do enable, however, is a crucial promise: the agent can view marginal cost, balance, usage, and limit before extending consumption.

By 2026, the ecosystem has outgrown lab demos: there are real payments, agentic provisioning, and controlled transactions in production infrastructure. Still, “in production” does not automatically mean universal availability. Access may depend on region, partner, payment method, agent certification, and provider integration.

## Real-world examples and their limits

### Vercel Marketplace CLI

Vercel lets agents discover, install, and manage Marketplace integrations from the CLI. An agent can add Neon, Upstash, or other services, creating and linking the resource 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.

### Supabase and Neon

MCP servers can create projects, databases, and branches via OAuth and APIs. Supabase even exposes tools for estimating and confirming cost. Its official recommendation is to keep human approval for sensitive operations. These integrations demonstrate L2—provisioning on an authorized account—not necessarily the purchase of a new subscription.

### Replit Agent Services

Replit brokers third-party services, such as search or media generation, without the user configuring every API key. Consumption is deducted from Replit credits at provider rates. The model shows how a platform can aggregate agent demand and turn multiple APIs into a single prepaid budget.

### Cloudflare, Browserbase, and Parallel

Cloudflare documents automated payment for x402 and MPP resources, once the user has configured their digital wallet and policy. Browserbase sells browser sessions via MPP, while Parallel sells API calls. These cases closely resemble the native form of a software marketplace between agents: structured offering, unit pricing, authorization, instant delivery, and receipt.

## Ways a SaaS can sell to agents

Not all products need the same infrastructure. The choice depends on transaction value, frequency, reversibility, and client type.

| Method | Suitable for | Advantage | Main limitation |
| --- | --- | --- | --- |
| Existing checkout, agent-initiated | Standard subscriptions and plans | Reuses current PSP, fees, and billing | Often requires human confirmation |
| Marketplace with centralized billing | Complementary integrations and infrastructure | Trust, reach, and a single invoice | Dependence on platform rules |
| MPP | APIs, sessions, jobs, and digital resources | Cards or stablecoins, receipts, and HTTP/MCP integration | New ecosystem, different support across payment infrastructures |
| x402 | API micropayments and digital content | Simple, automated flow, no separate account for each service | Currently relies mainly on digital wallets and stablecoins |
| Prepaid credits | Repeat consumption and strict budget control | Known maximum cost, reduced overage risk | Provider manages balance and expiration |
| Enterprise contract with delegated orders | Expensive or regulated services | Negotiated terms, list of approved vendors, and consolidated billing | Slower initial integration |

For many B2B companies, the most realistic path isn’t a new payment for each call. The company approves the vendor and contract once, then the agent can create resources or consume within the agreement’s limits. Operational autonomy increases, while legal procurement remains controlled.

## Pricing models suitable for agents

An agent can more easily compare offers that have a clear unit, calculable price, and explicit limits.

### Pay per call

Suitable for data, search, checks, and atomic functions. The pricing must define exactly what counts as a successful call, how retries are handled, and whether failed responses are charged.

### Pay per session or job

Works for browsing, rendering, analysis, or document processing. The unit is closer to the desired result than a single technical call.

### Pay as you go

Tokens, compute seconds, gigabytes, events, or minutes. The agent needs estimates before execution and near real-time telemetry, otherwise it can’t stick to a budget.

### Prepaid credits

The buyer allocates a balance, and the agent spends it without accessing the payment instrument for every operation. It’s a simple model for testing environments, teams, and workloads with controllable risk.

### Subscription plus overage

The plan covers an included volume, and excess usage is charged. The agent needs to automatically compare upgrading vs overages and shouldn't change the plan without the right policy.

### Pay per result

Attractive but more challenging. Provider and client must define a verifiable result, attribution, and situations involving partial results. Without a deterministic definition, disputes arise that the agent can’t resolve alone.

Regardless of the model, the offer should display the actual price, currency, known fees, limits, quote expiration date, and the maximum authorized amount. Phrases like “contact us” or “starting at” block automatic comparison.

## The commercial contract needs to become machine-readable.

The pricing page remains useful for people, but the agent needs structured data. A complete offer should include at minimum:

- the provider’s identity and the version of the offer;
- capabilities, input and output formats, and dependencies;
- plans, units of measurement, currencies, fees, and discounts;
- rate limits, quotas, regions, and availability;
- SLA, support, retention, residency, and data usage;
- trial period, isolated test environment, and verifiable examples;
- authentication method and requested permissions;
- maximum value, frequency, and authorization expiration;
- provisioning, upgrade, downgrade operations, and key rotation;
- idempotency keys to prevent duplicate orders;
- receipts, billing events, and reconciliation;
- cancellation, refund, revocation, and escalation to a human;
- the version of accepted terms and the identity of the buying party.

There is not yet a universal format for such an offer. Today, information can be published via OpenAPI, JSON Schema, structured documentation, MCP resources, A2A Agent Cards, or a marketplace’s schemas. What matters is that the commercial offer and technical contract don’t contradict each other.

## Reference flow for an agent-driven SaaS purchase

A robust flow can be divided into ten steps:

1. **Intention:** the buyer defines the outcome, budget, allowed providers, and actions requiring approval.
2. **Discovery:** the agent searches for offers in directories, marketplaces, or supplier catalogs.
3. **Evaluation:** it compares capabilities, total cost, region, security, SLA, and compatibility.
4. **Quotation:** the provider returns an offer with an identifier, maximum price, and validity term.
5. **Authorization:** a person approves the transaction or the agent presents an already granted mandate.
6. **Payment or reservation:** the processor, digital wallet, or marketplace verifies limits and authorizes funds.
7. **Provisioning:** the provider creates the resource through an idempotent operation.
8. **Delivery:** the agent receives the identifier, limited-scope credentials, and receipt.
9. **Usage and measurement:** consumption is reported almost in real time, with alerts and cut-off at thresholds.
10. **Administration:** the agent can renew, resize, cancel, or request intervention, as per policy.

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 only executes orders within the agreement.

## Minimum Architecture for an Agent-Ready Product

### 1. Technical Catalog

Publish capabilities, schemas, versions, and examples in a format that an agent can query. Use stable names and descriptions that do not depend on marketing interpretations.

### 2. Estimate or Quotation Endpoint

Before any paid operation, the agent must be able to obtain the estimated cost, maximum cost, period, and conditions. An expired quote must be rejected, not silently recalculated at a higher price.

### 3. Identity and Delegation

Separate the purchaser’s identity, the agent’s identity, and the platform’s identity. Use OAuth, tokens with limited permissions, short expiration, and policies based on resource, value, and action.

### 4. Idempotent Provisioning

A retry must not create two subscriptions or two clusters. Operations should accept idempotency keys and return the state of any existing order.

### 5. Purpose-Limited Secrets

An agent shouldn’t receive a master key when it only needs write access to a project. Credentials must have defined permissions, duration, and environment, and should be capable of being rotated or revoked.

### 6. Metering and Usage Entitlements

The system must know what the customer purchased, how much has been consumed, and what remains available. Balance and limits must be available programmatically, not just in a dashboard.

### 7. Spending Policies

Implement limits per transaction, day, agent, project, and provider. Add rate thresholds, allow-lists, anomaly-based locking, and extra approvals for irreversible actions.

### 8. Receipts and Audit

Every decision must be reconstructable: the initial request, the quote presented, terms version, approval, instrument used, resource delivered, and consumption. Technical logs aren't sufficient if they can't be linked to the commercial transaction.

### 9. Reversal and Support

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.

## Specific risks and required controls

### Prompt Injection and Malicious Descriptions

A document, website, or even a tool description may attempt to convince the agent to ignore policy and purchase a service. Provider content must be treated as untrusted data. Payment decisions must be validated by deterministic code, not just a language model.

### Confused Deputy

The agent has legitimate access to money and resources, but is induced to use them for purposes other than those approved. Scopes must be tied to recipient, resource, value, and time window.

### Spending Loops

An automatic retry, faulty scaling mechanism, or two agents reactivating each other can quickly accumulate costs. Cumulative limits, frequency caps, circuit breakers, and alerts ahead of budget exhaustion are necessary.

### Replay and Duplicate Charging

Payment messages can be replayed, and timeouts may cause the agent to repeat the command. Use nonces, expiration, signatures, idempotency keys, and reconciliation between payment and delivered resource.

### Price or Plan Drift

The agent may evaluate one offer and execute another if the price or terms change between steps. The quote must be versioned and locked for a clear period. Any material difference requires new authorization.

### Secret Leakage and Weak Isolation

An agent working for multiple projects may send a credential in the wrong context. Use vaults, ephemeral tokens, environment separation, and explicit tenant checks.

### Fake Providers and Manipulated Reputation

An open catalog may include services that mimic a brand or promise non-existent capabilities. Identity verification, metadata signing, review provenance, and independent testing become part of distribution.

### Opaque Renewals and Cancellations

An agent may easily enable a trial period but fail at cancellation. The offer must describe recurrence, next charge date, and closure steps in the same format used for the purchase.

These risks are in line with [the NIST document on identity and authorization for software and AI agents](https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd) as well as [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/). Identity and delegation standards are still evolving, so local policy control remains mandatory.

## A four-stage implementation plan

### Stage 1: agent-readable

- Publish structured documentation, OpenAPI specs, and schemas for the main objects.
- Provide a calculable pricing structure and cost examples.
- Expose limits, regions, data policy, and cancellation terms.
- Build a sandbox that doesn’t require unnecessary manual intervention.

### Stage 2: agent-operable

- Add OAuth and granular permissions.
- Automate resource creation, configuration, and deletion.
- Implement idempotency, webhooks, key rotation, and order states.
- Return structured errors with remediation steps.

### Stage 3: agent-purchasable

- Introduce signed quotes and approval policies.
- Integrate the appropriate marketplace, Shared Payment Tokens, MPP or x402, depending on the model.
- Add credits, consumption limits, programmatic receipts and refunds.
- Test retry, expiration, double order, and cancellation flows.

### Stage 4: enterprise-ready

- Offer an allow-list of vendors, SSO, SCIM, roles, and multi-level approvals.
- Tie every action to a cost center, project, and purchase owner.
- Comply with residency, retention, DPA, and fiscal invoicing requirements.
- Export audit logs to security and FinOps systems.
- Define human escalation and accountability for exceptions.

You don’t need to start with a new payment protocol. For many products, the biggest initial improvement comes from structured pricing, secure provisioning, and API-based cancellation.

## How to measure an agent sales channel

Classic conversion metrics are not enough. Also track:

- discovery-to-trial rate;
- time to first functional resource;
- provisioning success rate;
- task completion rate for which the service was purchased;
- percentage of transactions requiring human intervention;
- difference between estimated and actual cost;
- cost per outcome, not just per call;
- retries, duplicate operations, and reconciliation errors;
- budget overruns, refunds, and disputes;
- successful rotation or revocation of credentials;
- time and success rate for downgrade and cancellation;
- retention by purchase owner, agent, workload, and distribution platform.

An integration can have many calls and little value. The right criteria is whether the agent solves the client’s goal faster and more securely, at a predictable cost.

## Potential for SaaS platforms

### The API becomes the digital shelf

In a traditional marketplace, the product page captures attention. In an agentic ecosystem, the schema, price, and success rate can determine selection. Documentation and telemetry become part of merchandising.

### Stacks can be assembled dynamically

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 right at the moment of need.

### Niche products can have better distribution

A very good but little-known API can be chosen if it’s easy to discover, test, and purchase. Directories and marketplaces for agents can reduce the exclusive advantage of branding, but will increase the importance of technical reputation and measured reliability.

### Pricing shifts toward units and outcomes

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 will coexist with budgets allocated to agents and workloads.

### Procurement and FinOps are converging

When the agent sees the cost before acting, it can pick a plan, delay a task, or use an already-approved provider. Procurement is no longer just a pre-usage process but an ongoing policy executed continuously.

### A new intermediation risk emerges

If most customers reach you via a directory, programming agent, or marketplace, that platform controls ranking, data, and payment relationships. SaaS providers need to gain agentic distribution without losing the direct relationship with the purchasing owner.

## What is still unsolved

Despite the rapid pace, some issues remain open:

- there is no universal identity for agents or their delegation chain;
- support for the same protocol differs between providers and payment methods;
- AP2, ACP, and some commercial extensions are still in beta or standardization;
- payment does not solve acceptance of terms, taxes, DPA, or right of cancellation;
- refunds and disputes are harder in infrastructures without card protections;
- there is no universal register for provider reputation and result quality;
- a cheap purchase can later incur high costs via consumption, egress, or lock-in;
- models can be manipulated, and authorization needs to be verified deterministically;
- not all digital actions are reversible, even if the resource can be deleted.

This list doesn’t invalidate the opportunity. It defines the product to be built around payments.

## Our recommendation

SaaS platforms shouldn't wait for a 'universal agent shopping browser' to appear. The immediate advantage comes from a simpler foundation:

1. Make your offer easy for an agent to understand.
2. Make costs calculable before use.
3. Enable provisioning and cancellation via safe and idempotent operations.
4. Separate agent identity from the authorization of the purchasing owner.
5. Introduce limits, receipts, audit, and automatic stop mechanisms.
6. Choose commercial infrastructure based on risk, not just on popularity of protocol.
7. Require human approval for new terms, large amounts, and irreversible effects.

The goal is not maximum autonomy. The goal is useful delegation: the agent can act quickly where the rules are clear, and stops where human decision is needed.

## Conclusion

The next software buyer might be an agent—but the agent won’t buy like a human. It won’t be swayed by a catchy title and won’t patiently fill out a sales form. It will look for verifiable capabilities, calculable prices, explicit authorization, programmatic provisioning, and evidence that the service delivered the promised result.

The necessary infrastructure already exists in pieces: 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 that blindly signs any contract, but an agent that buys and manages software within set boundaries, with traceability and intervention capability.

For a SaaS provider, now is the right time to become agent-ready. Companies that structure their offerings, automate provisioning, and build in spend controls will be easier to choose for both humans and the software working on their behalf.

## Primary sources and official documentation

### Stripe and OpenAI

- [Stripe: Agentic commerce for software providers](https://stripe.com/guides/agentic-commerce-primer-software-providers)
- [Stripe Projects](https://docs.stripe.com/projects)
- [Stripe Directory](https://docs.stripe.com/directory)
- [Stripe: Machine Payments Protocol](https://stripe.com/blog/machine-payments-protocol)
- [Stripe: Machine payments](https://docs.stripe.com/payments/machine)
- [MPP: protocol and documentation](https://mpp.dev/)
- [Agentic Commerce Protocol](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol)
- [OpenAI: checkout specification](https://developers.openai.com/commerce/specs/checkout)
- [OpenAI: payment specification](https://developers.openai.com/commerce/specs/payment)

### Google, A2A and AP2

- [Google: Agent Payments Protocol](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol)
- [AP2 v0.2: specification](https://ap2-protocol.org/ap2/specification/)
- [AP2: Payment Mandate](https://ap2-protocol.org/ap2/payment_mandate/)
- [A2A: specification](https://a2a-protocol.org/latest/specification/)
- [A2A x402](https://github.com/google-agentic-commerce/a2a-x402)
- [Universal Commerce Protocol](https://github.com/Universal-Commerce-Protocol/ucp)

### x402, Cloudflare and AWS

- [Coinbase Developer Platform: x402](https://docs.cdp.coinbase.com/x402/welcome)
- [x402 Foundation: official repository](https://github.com/x402-foundation/x402)
- [Cloudflare: payments for agents](https://developers.cloudflare.com/agents/tools/payments/)
- [Cloudflare: Monetization Gateway](https://blog.cloudflare.com/monetization-gateway/)
- [AWS: AgentCore Payments](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments.html)
- [AWS: AgentCore Payments now generally available](https://aws.amazon.com/about-aws/whats-new/2026/08/bedrock-agentcore-payments-ga/)
- [AWS Marketplace MCP Server](https://docs.aws.amazon.com/marketplace/latest/developerguide/marketplace-mcp-server.html)

### SaaS and ecosystem examples

- [Vercel: coding agents and Marketplace integrations](https://vercel.com/kb/guide/using-coding-agents-to-procure-vercel-marketplace-integrations)
- [Supabase MCP](https://supabase.com/docs/guides/ai-tools/mcp)
- [Neon MCP](https://neon.com/blog/bringing-mcp-to-the-cloud)
- [Replit integrations and agent services](https://docs.replit.com/features/integrations/overview)
- [Visa Trusted Agent Protocol](https://developer.visa.com/capabilities/trusted-agent-protocol)
- [Mastercard Agent Pay](https://www.mastercard.com/news/press/2025/april/mastercard-unveils-agent-pay/)
- [PayPal Agentic Commerce](https://developer.paypal.com/docs/agentic-commerce/)

### Security and governance

- [NIST: Software and AI Agent Identity and Authorization](https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd)
- [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)