<MT />
Back to Blog
AI agentsAPI designSaaSMCPagentic paymentsx402developer experience

AI Agents Are Starting to Pay for Software Themselves. Is Your SaaS or API Ready?

T

Muhammad Tayyab

October 21, 2026·20 min read
A person holding a credit card while using a laptop, illustrating software that gets paid for online. Photo by rupixen on Unsplash.

Composio Instant gives AI agents a wallet for paid tools, and Exa 3.0 and RunInfra are pitching agents as customers. Here's where agent payment standards like MCP, x402, ACP, AP2 and MPP actually stand, plus a practical checklist for making your SaaS or API something an agent can find, pay for and use safely.

For most of the history of SaaS, the buyer was a person. Someone found your pricing page, made an account, picked a plan, typed in a card and copied an API key into a config file. An AI agent can't do most of that on its own, so every paid API has had a human checkpoint built in.

That checkpoint is starting to disappear. In the space of a few days this October:

  • Composio Instant launched on Product Hunt on October 20, 2026, pitched as "the easiest way for AI agents to pay for their own tools." It reached #2 for the day and #3 for the week, with 330 points when I checked on October 21.
  • Exa 3.0 (October 19, 2026) was framed around a big jump in usage from personal AI assistants, with cheaper per-request tiers and responses that use fewer tokens.
  • RunInfra launched on Product Hunt on October 20, 2026 with the tagline "Open models, built for agents," and an onboarding flow written for the agent to follow, not the human.

You don't need to rebuild your product around agents tomorrow. But if an agent turned up at your API today with a budget and a task, could it work out what you charge, pay, call you safely and stop when it should? Here's what launched, where the standards actually stand, and a checklist you can work through.

What actually launched

Composio Instant: a wallet for the agent

According to Composio's launch post, Instant gives your agent a wallet it can spend from across 100+ paid tools, with no separate accounts or API keys for each provider. The details that matter if you sell an API:

  • New users get $2 of starting credit, and Composio's Pro plan includes $29 a month in credit.
  • Failed calls aren't charged, every charge is visible, and your own connected accounts are used first.
  • Provider keys never reach the agent. Composio holds the credentials and the agent just spends from the wallet.
  • It works with Claude, ChatGPT, Codex, Cursor and other MCP clients. Composio says more than $1M has been loaded into wallets.

Composio's developer docs add an important caveat. Instant tools are off by default, and the docs say plainly: "There is no built-in dollar cap." If you want a budget, you build it in your app or turn Instant off. That's not a criticism. It's a good reminder that spend control is still mostly the builder's job.

Exa 3.0: search priced for agents

Exa's October 19 post introduces Exa Lite at $4 per 1,000 requests and Auto at $7 per 1,000. It makes Dynamic Highlights generally available, which Exa says uses up to 95% fewer tokens than returning full page text. It also adds coverage such as 1.27 billion ecommerce listings and 211 million+ local businesses. Most of the benchmark figures in the post are Exa's own. The direction is the useful part: price per request, keep responses small, and assume the reader is a model.

RunInfra: onboarding written for the agent

RunInfra is a Y Combinator-backed provider of open models behind an OpenAI- and Anthropic-compatible API (https://api.runinfra.ai/v1), with plans from $10 to $99 a month. The interesting part is its setup prompt for agents. The agent has to show a plan and wait for a "yes" before it installs anything, changes settings or spends money. Sign-in uses a browser device code, and the instructions say "Never paste an API key into the chat." That's a sensible pattern to copy: let the agent do the work, but keep the human approving anything that costs money or touches credentials.

Where the standards stand (October 2026)

There's no single "agent payments standard" yet. There are several overlapping efforts at different stages. Here's the short version, with status and dates.

Discovery and docs

  • MCP (Model Context Protocol): the de facto way to expose tools to agents. The latest spec version is 2026-07-28.
  • llms.txt: a proposal from Jeremy Howard for a Markdown file at /llms.txt that points models to your most useful docs. The current v2 page at llmstxt.org was updated on August 10, 2026 and adds <link rel="alternate"> and rel="describedby" hints. It's a convention, not a formal standard.
  • OpenAPI: still the most widely supported machine-readable description of an HTTP API, and what many agent frameworks turn into tools.

Paying per request

  • x402 (HTTP 402 Payment Required): started by Coinbase and now under the x402 Foundation. The server replies 402 with a PAYMENT-REQUIRED header, the client retries with PAYMENT-SIGNATURE, and the server confirms with PAYMENT-RESPONSE. v2 is the recommended version (spec dated December 2025). Its payment schemes include exact, upto and batch-settlement. The spec leaves client-side budget management out of scope.
  • MPP (Machine Payments Protocol): co-authored by Stripe and Tempo, announced March 18, 2026. It uses the same 402 challenge-and-retry idea. On Stripe it can accept stablecoins, plus cards and buy now, pay later through Shared Payment Tokens. Stripe's "machine payments" docs currently label the feature Frontier, support both MPP and x402, and settle into your normal Stripe balance. The minimums are $0.50 for card payments through SPTs and 0.01 USDC for stablecoins.

Agent checkout and authorization

  • ACP (Agentic Commerce Protocol): maintained by OpenAI and Stripe, Apache 2.0, still beta. The latest stable spec is dated 2026-04-17. It powers ChatGPT Instant Checkout, which is open to approved partners.
  • Stripe Shared Payment Tokens: let an agent pass a scoped payment credential to a seller. They're in public preview (US, Canada and select EU countries), with usage limits such as max_amount and expires_at. Stripe Issuing for agents is in private preview.
  • AP2 (Agent Payments Protocol): announced by Google Cloud on September 16, 2025. It uses signed "mandates" that prove what the user authorized. v0.2.0 (April 28, 2026) added "Human Not Present" flows, and Google donated AP2 to the FIDO Alliance.
  • Visa Trusted Agent Protocol: announced October 14, 2025 with Cloudflare. It lets merchants cryptographically recognize registered agents and tell them apart from malicious bots, building on HTTP Message Signatures and Web Bot Auth.
  • Mastercard Agent Pay: expanded on September 30, 2026 with an Agent Pay Trust Framework and an AI-initiated transaction probability score, which is so far only being tested in the US.

What this means in practice: if you take payments through Stripe, the lowest-effort path is probably what Stripe already supports. If you want to accept stablecoin micropayments directly, x402 is the most documented open option. In either case, the checklist below matters more than which protocol wins.

The agent-ready checklist

1. Make pricing machine-readable

An agent can't squint at a pricing page with three tiers and a "Contact sales" button. Publish prices in a form a program can read, and keep the numbers in sync with what you actually bill.

  • Put a per-unit price on every billable endpoint or tool (per request, per 1,000 tokens, per GB).
  • Expose it in your docs, your OpenAPI description and your MCP tool descriptions. Composio, for example, lets developers inspect tool pricing with include_pricing=true.
  • Return the actual cost of each call in the response or a header, so the agent can track spend as it goes. Composio returns an instant_charge field for this.
  • Say clearly what isn't billed: failed calls, retries, cache hits.

There's no standard pricing file yet, so treat this as an illustrative shape, not a spec:

// Example only: a pricing endpoint shape, not a standard
{
  "currency": "USD",
  "updated": "2026-10-21",
  "items": [
    { "operation": "POST /v1/search", "unit": "request", "price": 0.004 },
    { "operation": "POST /v1/extract", "unit": "page", "price": 0.01 }
  ],
  "not_billed": ["4xx errors", "5xx errors", "cached responses"]
}

2. Issue scoped, usage-based API keys

Agents leak context. Prompts get logged, tools get chained, and a key pasted into a chat can end up anywhere. Design keys assuming that will happen.

  • Support many keys per account, one per agent or integration, so you can revoke one without breaking the rest.
  • Scope each key to specific operations and environments (read-only, a single project, test mode).
  • Add expiry and make rotation easy.
  • Prefer OAuth or a device-code flow over asking a human to paste a secret. RunInfra's "never paste an API key into the chat" rule is worth copying.
  • Bill on usage. Stripe's usage-based billing supports metered prices, and its token billing for LLM usage is in public preview through Metronome.

3. Build spend limits and budgets into the product

This is the gap the launches above keep pointing at. x402 leaves client budgets out of scope, and Composio's docs say there's no built-in dollar cap. If your product doesn't enforce limits, a looping agent can turn into a surprise invoice and a support ticket.

  • Let customers set hard caps per key and per account (per day and per month).
  • Support per-call maximums so one request can't cost more than expected.
  • Send alerts at thresholds like 50%, 80% and 100%.
  • When a cap is hit, fail closed with a clear, machine-readable error, not a silent overage.
  • Offer prepaid credits as an option. A balance that can run out is the simplest budget there is.

4. Write docs agents can actually use

  • Publish a complete, accurate OpenAPI description and keep it in CI so it can't drift from the code.
  • Ship an MCP server for your core actions, with tool descriptions that state cost, side effects and required scopes.
  • Add an /llms.txt that points to your quickstart, auth, pricing, errors and rate limits, and offer Markdown versions of key pages. Stripe's docs, for example, have "View as Markdown" and "Copy for LLM" on every page.
  • Keep examples copy-pasteable and current, because agents will copy them.
# Example only: /llms.txt for a small API
# Acme Search API

> Pay-per-request web search for apps and agents. Prices in USD.

## Docs
- [Quickstart](https://acme.example/docs/quickstart.md): first request in 2 minutes
- [Authentication](https://acme.example/docs/auth.md): scoped keys and OAuth device flow
- [Pricing](https://acme.example/docs/pricing.md): per-request prices and what isn't billed
- [Errors and rate limits](https://acme.example/docs/errors.md)

## Optional
- [OpenAPI spec](https://acme.example/openapi.json)
- [MCP server](https://acme.example/docs/mcp.md)

5. Return clear errors and rate limits

A human reads an error page. An agent reads your response body and decides whether to retry, wait, change its request or give up. Make that decision easy.

  • Use RFC 9457 Problem Details (application/problem+json) with stable type values the agent can branch on.
  • Use status codes precisely: 401 for bad credentials, 403 for missing scope, 402 when payment is required, 429 when rate limited.
  • Send Retry-After (RFC 9110) on 429 and 503. The IETF RateLimit header fields are still an Internet-Draft, but they're a reasonable way to tell clients their quota before they hit it.
  • Say whether a request is safe to retry, and support idempotency keys on anything that charges money.
# Example only: a budget-exceeded response
HTTP/1.1 402 Payment Required
Content-Type: application/problem+json

{
  "type": "https://acme.example/errors/budget-exceeded",
  "title": "Daily spend cap reached",
  "status": 402,
  "detail": "Key ak_live_...9f2 has spent $25.00 of its $25.00 daily cap.",
  "cap_resets_at": "2026-10-22T00:00:00Z",
  "retryable": false
}
# Example only: rate limited, using RFC 9110 Retry-After
# and the draft IETF RateLimit fields
HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 30
RateLimit-Policy: "default";q=100;w=60
RateLimit: "default";r=0;t=30

{
  "type": "https://acme.example/errors/rate-limited",
  "title": "Too many requests",
  "status": 429,
  "retryable": true
}

If you adopt x402 or MPP, a 402 also becomes a payment challenge the client can answer automatically. Keep "you must pay" and "you've hit your budget" as clearly different type values so an agent doesn't try to pay its way past a cap the human set.

6. Plan for abuse and fraud

Agents make it cheap to try things at scale, both for legitimate customers and for attackers.

  • Apply per-key and per-account rate limits on top of spend caps, and limit free tiers and trial credit by identity, not just by email address.
  • Watch for card testing and credit farming. If you settle through a processor like Stripe, its existing fraud tools still apply to machine payments.
  • Treat any content you return as untrusted input for the agent reading it. Don't put instructions in responses that could be mistaken for commands.
  • Keep the actions that are expensive, destructive or irreversible (big purchases, deletes, sending messages) behind explicit confirmation or a separate scope.
  • Keep an eye on agent identity signals. Visa's Trusted Agent Protocol and Web Bot Auth let you tell registered agents from anonymous bots, and Mastercard is testing a score for AI-initiated payments.

7. Record which agent acted for which human

When something goes wrong, "the API key did it" isn't a good enough answer for you or your customer.

  • Tie every key to a human or organization owner, and let customers label keys by agent or integration.
  • Accept an optional agent identifier (a header or OAuth client) and log it with every billable action.
  • Keep an audit log customers can view and export: who, which agent, what action, what it cost, and when.
  • Where payment protocols carry proof of authorization, like AP2 mandates or Shared Payment Token limits, store a reference next to the charge.
// Example only: an audit event for a paid agent action
{
  "event": "usage.charged",
  "at": "2026-10-21T07:24:11Z",
  "account_id": "acct_123",
  "owner": "user_456",
  "api_key": "ak_live_...9f2",
  "agent": { "client_id": "research-assistant", "label": "Weekly market report" },
  "operation": "POST /v1/search",
  "amount_usd": 0.004,
  "request_id": "req_789",
  "idempotency_key": "3b1f..."
}

8. Update your terms of service

Many terms were written assuming a human is clicking "I agree." Review yours with an agent buyer in mind, and talk to a lawyer for anything binding.

  • State that the account holder is responsible for actions and charges made by agents using their keys or credentials.
  • Spell out what automated use is allowed, and what isn't (scraping, reselling, sharing keys between customers).
  • Explain your refund and dispute policy for agent-initiated charges, including mistakes from loops or bad prompts.
  • Mention data handling for anything your API returns to a third-party model or tool platform. Composio's docs, for example, note that tools on shared provider accounts exclude private data and don't imply zero data retention.

Corrections and caveats

A few claims around these launches don't hold up, or need context:

  • Composio Instant's Product Hunt numbers move fast: I couldn't confirm a figure of about 167 votes. The Product Hunt page showed 330 points on October 21, 2026, so date any number you quote. Composio's own launch blog post is dated October 8, 2026, ahead of the October 20 Product Hunt launch.
  • Exa 3.0 is dated October 19, 2026 on Exa's blog, not October 18 as one report said. I couldn't confirm a Product Hunt launch for it, and its benchmarks are self-reported.
  • RunInfra's cache-hit figure varies across its own pages (99.5%, 99.3% and 98%), so treat it as approximate.
  • Most of the payment pieces aren't GA: ACP is beta, Shared Payment Tokens are public preview, Issuing for agents is private preview, Stripe machine payments are labelled Frontier, and Mastercard's AI-initiated score is only being tested in the US.
  • The RateLimit headers are a draft and could still change before becoming an RFC.

Quick checklist

  • Publish per-unit prices in your docs, OpenAPI and MCP tool descriptions, and return the cost of each call.
  • Issue many scoped, expiring, revocable keys, and prefer OAuth or device-code sign-in over pasted secrets.
  • Enforce per-key and per-account spend caps, per-call maximums and alerts, and fail closed when a cap is reached.
  • Keep OpenAPI accurate, ship an MCP server and add an /llms.txt with Markdown docs.
  • Return RFC 9457 errors with stable types, precise status codes, Retry-After and idempotency keys.
  • Rate limit by key and account, guard free credit, and gate irreversible actions.
  • Log which agent acted for which human, and let customers export it.
  • Update your terms for agent use, refunds and data handling.
  • Decide whether Stripe's agent tools, x402 or simply better keys and budgets are the right first step for you.

If you're working out how to make your SaaS or API easier for agents to use and pay for, and want a second opinion, get in touch.

About the author: Muhammad Tayyab is a full stack and mobile developer based in Lahore. He builds DripScore, an AI outfit rating app live on the App Store, under dawnapps.co. Find him on GitHub, LinkedIn, and X, or say hello at /#contact.

Sources

Back to all posts
Thanks for reading 🙏