DEV Community

oded-unipaas
oded-unipaas

Posted on • Originally published at paas.build

I scanned 53 platforms to see if an AI agent can actually pay on them. The AI companies scored worst.

Disclosure first, because it matters for how you read this: I'm the CTO of UniPaaS, an FCA-authorised payment institution, and we build paas.build. We also built the index this post is about, and yes, our own site sits at the top of it. So read everything below with that in mind. To make it fair I'm publishing the full rubric and every site's evidence, so you can check the math or disagree with it. I'll also point out where our own scoring is weak.

The question

AI agents are starting to buy things. Not "soon", now: people are wiring up assistants that book, subscribe and pay. So I got curious about a boring but important question. If an agent lands on a website, can it actually figure out what the site does, find the thing to buy, and pay? Or does it hit a wall of JavaScript and marketing copy?

There's already solid work on the retail side of this. Digital Commerce 360 and ReFiBuy rank the top 1000 stores for AI shopping readiness, and a few others score individual ecommerce sites. I wanted to look one layer down, at the infrastructure: the app builders, the payment providers, and the AI companies themselves. If the tools and the rails aren't agent-ready, the stores sitting on top of them can only get so far.

So I scanned 53 of them: AI app builders, payment providers, and the big AI companies. Then I turned it into a public leaderboard, the Agentic Checkout Index.

How the scan works

Every site gets the same objective checks, no opinions, grouped into five buckets worth 100 points:

  1. Discoverability (25): robots.txt, sitemap.xml, and especially llms.txt / llms-full.txt, the plain-text summary files agents read.
  2. Structured data (20): JSON-LD, typed schema (Organization, Product, FAQ), OpenGraph.
  3. Agent endpoints (25): an OpenAPI spec, a .well-known/ai-plugin.json, and an MCP server. This is how an agent actually calls you instead of guessing.
  4. Content clarity (15): a real h1, semantic HTML, and whether the page is readable without running JavaScript.
  5. Payments signals (15): is a payment provider detectable, is there a pricing page, is there a visible checkout path.

Each check shows its evidence, the exact URL requested and what came back, so nothing is hand-wavy. It's HTTP GETs, no JS execution, which is roughly how a lot of agents read the web today.

What came back

The average score across 53 sites was 52 out of 100. Twenty-one of them, nearly 40 percent, scored an F.

The part I did not expect: the AI companies were at the very bottom.

  • perplexity.ai: 10
  • openai.com: 33
  • anthropic.com: 37

The companies building the agents have almost nothing an agent can mechanically read on their marketing domains. No llms.txt, no structured data an agent can parse, content that only appears after JavaScript runs. Now, a fair caveat: these are heavy single-page apps, and my scan reads the served HTML, not the JS-rendered version. But that's also kind of the point. If your value only exists after a full browser renders it, a lightweight agent fetch sees a near-empty page.

The AI app builders landed in the middle: Lovable, Base44 and Cursor at 62, Adalo at 67, while Bolt (49) and Bubble (37) trailed. So the tools people use to build apps are only partly ready for agents to transact inside those apps.

Payments was a mixed bag. Among payment companies, Dodo Payments (67) came out ahead of Stripe's marketing site (57) and Paddle (52). Interestingly, docs.stripe.com scored lower (40) than Stripe's homepage, and for a developer product the docs are the surface an agent actually hits.

Two sites got an A: render.com (82) and paas.build (89). Render earns it with clean structure and real endpoints. Ours scores high because we deliberately built for this: llms.txt, JSON-LD, an OpenAPI spec, a live MCP server, server-rendered pages. That's not a coincidence and I'm not going to pretend it is. It's the whole thesis of the product.

Where my own scoring is weak (so you can judge it)

  • It reads homepages and well-known paths, not the full site. A great checkout buried three clicks deep won't be seen.
  • No JavaScript execution penalizes SPAs, which is partly fair (agents often don't render) and partly harsh.
  • "Payment provider detectable" only looks at script and link tags on the homepage, so a site that loads its checkout later looks empty.

I'd rather state those plainly than pretend the number is gospel. If your site scored low and you think it's wrong, the evidence is right there on your page and you can ask for a rescan.

The actual takeaway

If you want an agent to be able to buy from you in 2026, the boring checklist is: publish an llms.txt, put real JSON-LD on the page, expose an OpenAPI spec and ideally an MCP endpoint, make sure the page says what it is without JavaScript, and keep a clear pricing and checkout path. None of that is exotic. Most sites just haven't done it yet, which is why the average is 52.

The full leaderboard and every site's evidence is here, updated as sites get rescanned:

https://paas.build/score/

If you work at one of the sites near the bottom, this is a genuinely fixable afternoon of work, and I'd love to watch the score move.

Top comments (0)