How we verify.

This page defines how a capability moves from claimed to verified. Each capability is sourced from the provider’s own documentation and carries a status; a verified or failed result is backed by reproducible evidence. The same method applies to every provider.

The status ladder

Each capability carries exactly one status. Failed and unverifiable are first-class outcomes; a negative result is published with the same evidence as a verified one.

Status	Meaning
claimed	Stated in the vendor’s documentation; not yet executed. Backed by a quote and a source link.
verified	Executed; the documented outcome reproduced. Backed by reproducible evidence.
failed	Executed; the documented outcome did not reproduce. Backed by the same evidence.
unverifiable	Not testable — no accessible sandbox, endpoint, or documented method.

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 execution: the documented call is made and the documented result observed.
• Documentary claims (pricing, coverage counts) cannot be executed. They are verified by archival — a timestamped snapshot of the source. This records that the vendor published the claim; it does not test the claim's accuracy. These are labeled accordingly.

How we test

Three environments, lowest cost and risk first. Each provider is tested 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 real charges. 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.
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 a single pass/fail test. One successful run marks it verified. Measuring reliability 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 includes 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 are published, each status change appears here with a link to its evidence.

Live status

Every capability's status — and the evidence behind it — is shown on the registry and in the JSON API, and updates as verification proceeds. A capability is presented as verified only when it carries the verified status and linked evidence.