How we verify.

A directory restates what vendors say. This registry checks it and shows its work. Every capability carries a status, and every status change ships with a reproducible evidence trail. Today every capability is claimed — sourced from the provider’s own docs. Verification is in progress; this page is the method we hold every provider to.

The status ladder

Each capability carries exactly one status. The ladder can say no — a registry that only returns "verified" is a press release, not a measurement.

Status	Meaning
claimed	The vendor’s docs assert it. Backed by a verbatim quote and a source link.
verified	We executed the claim and observed the documented outcome. Backed by a full evidence trail.
failed	We executed it and it did not do what was claimed. Backed by the same evidence trail.
unverifiable	We could not test it — no sandbox, gated access, or a documentary claim with no way to run it.

Two kinds of claims

Not every capability is proven the same way.

• Executable claims (execution, auth, discovery, returns, sandbox, protocols, regions, status) are verified by doing it: we make the documented call and observe the documented result.
• Documentary claims (pricing, coverage counts) cannot be run. We verify them by archival — capturing a timestamped snapshot of the source. That confirms the vendor published it on a date, not that it is empirically true. We label these differently for that reason.

How we test

Three environments, cheapest and safest first. We test each provider on the terms it actually supports — a provider is never marked failed for a scenario outside its stated scope.

Sandbox	The provider’s own test environment. Confirms the API contract and protocol handshakes. No money. Most verification lives here.
Controlled storefront	Stores we own, in test-payment mode, for site-agnostic providers. Confirms a real checkout completes on a store the provider has never seen. Reproducible, no money.
Real-world spot check	A fixed basket of real products, used sparingly to calibrate and to score providers limited to their own merchant set.

What counts as a pass

Each executable claim becomes one binary, observable test. One clean success marks it verified — the capability exists. Measuring how reliably it works across many runs is the benchmark, a separate effort.

• execution — a confirmed order returns with the correct item and variant.
• auth — the documented auth call succeeds and a bad credential is rejected.
• discovery — the documented input resolves the correct product.
• returns — a return request is accepted against a test order.
• sandbox — the documented test environment exists and accepts a documented call.
• protocols — the claimed protocol endpoint responds per its spec.
• regions — an order to a claimed region succeeds, or out-of-region is rejected as claimed.

What we publish as evidence

Every verified or failed result ships with enough to reproduce it:

• The sanitized request and response (keys, tokens, and personal data redacted).
• Order or return IDs, timestamps, and the provider’s doc version at test time.
• A screenshot of the merchant confirmation for browser-driven checkouts.
• An archived snapshot of the source document.
• A re-runnable snippet so a third party with their own key can reproduce the result.

All testing uses a dedicated synthetic buyer and the provider’s test payment instruments, so evidence can be published without exposing anyone’s data.

Verification changelog

No verifications published yet. As results land, each status change appears here with a link to its evidence.

Current status

The registry is independent, and this method is applied identically to every provider listed. As of today, every capability is claimed and verification is in progress. As results land, each capability on its agent page will carry its status and a link to the evidence behind it.