Checkout.com is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Checkout.com API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.
SCORED UNDER RUBRIC 1.2 · A full re-launch under Discry Score 2.5 — a new behavioral instrument, not comparable to these scores — is in progress.
Discovery
45% of score · 67/100Comprehension
55% of score · 96/100What we found
- An agent discovering Checkout.com would land in unusually agent-ready territory: a first-party Checkout.com MCP Server is documented directly in the developer docs and the API is also listed on Pipedream's MCP registry — so an agent can find and bind tooling without reverse-engineering the REST API.
- An agent reading the docs gets near-perfect comprehension (96/100): every core flow ships as a numbered end-to-end guide (create payment session → mount Flow → handle webhook → test) with realistic copy-pasteable examples (Jia Tsang / jia.tsang@example.com / amount 1000 GBP / ps_… and pay_… IDs) across curl, JSON, Node, HTML, and JS.
- Self-correction is well supported: dedicated Idempotency and Rate Limits pages give explicit recovery steps (retry with Cko-Idempotency-Key, wait 30s on a 409, exponential backoff with jitter on a 429) rather than just listing codes — exactly what an agent needs to recover from failures.
- The OpenAPI spec is a standout discovery win: api-reference.checkout.com offers a one-click download in JSON, YAML, AND Markdown, so an agent can ingest the full machine-readable contract — and the Markdown variant is purpose-built for LLM consumption.
- Discovery is held back (67/100) by missing agent-native signals: no AGENTS.md in any of the public SDK repos, no llms-full.txt, no .well-known/mcp.json, and the public sitemap.xml indexes only marketing pages — the /docs documentation tree is absent, so a crawler relying on the sitemap would never reach the integration guides.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add a docs sitemap (or include the /docs tree in the existing sitemap.xml) so crawlers and agents can discover the integration guides — currently only marketing pages are indexed, leaving the strongest content invisible to sitemap-based discovery.
- 02Publish an AGENTS.md in the primary SDK repos (checkout-sdk-node, -python, -java, -go, -net) so coding agents get build/test/auth context — these are popular, actively maintained repos and an AGENTS.md is a low-effort, rising-standard win.
- 03Ship an llms-full.txt containing the concatenated Markdown of the core API guides (the docs already convert cleanly to Markdown and the API reference offers a Markdown export, so the source material exists) to give agents a single comprehensive ingest target.
- 04Refocus llms.txt to lead with developer/API resources (docs, API reference, OpenAPI download, MCP server) rather than product-marketing pages — the current file is well-structured but predominantly links to /products/* landing pages instead of the documentation an agent actually needs.
- 05Add a concise capability/overview page (or top-of-llms.txt summary) that lets an agent grasp the core payment, payout, and issuing capabilities in under ~5,000 tokens, improving token efficiency for first-contact agents.
Execution coverage · INFORMATIONAL, UNSCORED
Whether an agent can actually complete a call and recover from errors is the deeper Audit layer — documented here, but not part of the Discry Score.
Checkout.com thoroughly documents execution characteristics: API key authentication with granular key scopes (public pk_ / secret sk_), idempotency via the Cko-Idempotency-Key header with a documented 24-hour window and 409-conflict behavior, adaptive rate limits (100 RPS read/write) with explicit 429 exponential-backoff-with-jitter guidance, and a machine-parseable error/response-code reference. Pagination was not directly observed in the scanned pages.