How these pages are verified

Where the facts come from

Every factual statement on an integration page is a fact in the page's data file, and every fact carries a source URL, a source type, a confidence level, and the date the source was last checked. Sources are ranked: official documentation, a vendor's pricing page and release notes rank highest; an app-store or marketplace listing next; a plugin's public repository after that; a vendor's partner directory after that. Community forums are used only for gotchas, and only where something higher-ranked corroborates them.

Anything with a number in it — a fee, a limit, a version, a timing — must come from a top-ranked source or it is not shown. A fact is marked high-confidence when its source states the claim and medium when the source only implies it; a page's status must rest on a high-confidence fact, and a row that rests on a medium one is worded as the inference it is. Facts marked low-confidence stay in the data for follow-up and never render. A field that could not be sourced is left out rather than filled with a guess.

What the capability table's words mean

Each fact also records what its source speaks to: this exact gateway-on-this-platform pairing, the connector itself, the gateway in general, the platform in general, or a different pairing altogether. Those labels decide what a row may say.

• Yes means a source about this pairing or its connector confirms the capability. Evidence about the gateway in general is never enough for a Yes.
• Limited means it works, but this integration itself restricts it: only one of the page's connectors or apps has it, only one checkout type, a platform plan tier, only certain orders. Limits that belong to the method itself (ACH is a US product) do not make a row Limited.
• Not verified here means the gateway supports it, but no source confirms this integration exposes it.
• No means a source says it is unavailable here. Every No cites a fact that says no; where the source is a list the capability is simply absent from, the row says "not listed" rather than pretending to a stronger statement. A Yes is never allowed to rest on a source that says no, and a build fails if one does.
• External only means the overall solution offers it, but not from inside this platform's own connector.
• N/A means the capability cannot apply to this pairing.

A capability with no source either way is left off the table: omission means nothing is known, never that the capability is supported. Where a gateway is really a family of products — Fiserv's Clover, Commerce Hub, Fiserv Checkout and CardPointe — each page names the product it is about and inherits nothing from the others.

What "sandbox-verified" means

A gateway with a self-serve test environment is eligible for a canonical card flow, run against it through the UAT-Ops workbench: create a customer or token where the gateway needs one, authorize, capture, partially refund, authorize again, void. The workbench records each step's request shape, HTTP status and duration, and the redacted result — no keys, no object ids, no request or response bodies — is published on the gateway's hub page with the date of the run.

Each step reports one of five results. Pass: the call succeeded. Expected rejection: the gateway refused the step for a precondition it enforces by design, such as a refund attempted before the transaction settles; the reason is stated and cites the gateway's own documentation. Blocked: the sandbox could not be reached or refused the credentials, which says nothing about the capability. Unexpected failure: the step failed for a reason the flow did not anticipate, and the status is recorded as it came back. Not run: the step was never attempted, usually because an earlier one stopped the flow.

The run as a whole then reads one of three ways, and the difference matters. A run is verified only when every step passed: every capability in the flow was demonstrated end to end. It is tested when no step failed but at least one was an expected rejection, which means the flow reached the gateway and proved the rest, while a capability the gateway declined to exercise was not demonstrated and the page does not claim it was. Anything else is incomplete: a step was blocked, failed unexpectedly, or was never attempted, and the page says the sandbox "was run" with those counts rather than claiming any of it was verified. Whichever word applies, the counts behind it are printed beside it, so "2 passed, 1 expected rejection" stays visible rather than being summarised away.

Those three words describe a flow that happened. A gateway with no flow behind it says so instead: Not run where UAT-Ops has not run one yet, and Blocked where the test environment is only issued through a sales or implementation contact, with the reason given.

The run is at the gateway level. It exercises the gateway's API, not the platform connector that sits in front of it, so every integration page says so in its "UAT-Ops testing" line and never implies the connector itself was executed.

Human review

No page publishes until a person has read it. On an integration page that means the verdict, the capability table, the gotchas and the testing notes, with the sources behind the claims that matter spot-checked; on a page like this one it means the text you are reading. That review, not the automated checks, is what the page's reviewed date attests. Gotchas drawn from first-hand experience are phrased as experience, not as vendor fact. Every page shows the date its newest source was last checked and, once a person has reviewed it, the date of that review. The review is bound to the page's content: a change made after it puts the page back into review, and the page does not publish again until a person has read the change.

Referral links and independence

Some vendors run referral programs. At the time of writing no such program has been applied for, and no link on this directory is a referral link. If one is ever used, it will go through a redirect on this domain, carry rel="sponsored", be visibly labelled, and the page will show a one-line disclosure — and the verdict and gotchas will not change because of it. See the disclosure.

Corrections

If something on a page is wrong or out of date, write to the address in the footer with the page URL and the source that contradicts it. Corrections that check out are applied at the next build, with the verified date updated.