Providers and Capabilities

Providers and Capabilities

Each provider adapter publishes a manifest: what it can analyze, how well, and what it cannot do. The providers page is generated from these manifests and is always current. The README table is generated from the same data.

Capability statuses

Status	Meaning
supported	implemented and covered by tests
limited	works, with documented gaps listed on the provider page
experimental	implemented but not fully covered, or the documentation is thin
unsupported	not available

Capabilities are rated separately:

Capability	Question it answers
errorDecoding	Are error, decline and response codes decoded?
paymentResponses	Are synchronous API responses understood?
webhookParsing	Are webhooks, notifications or postbacks understood?
timeline	Can events be ordered reliably (timestamps, event ids)?
correlation	Can related events be linked by documented identifiers?
diagnosticRules	Do provider-specific rules apply, or only the general ones?

A provider's overall status is supported only when every capability is supported.

Research status (roadmap)

Research status	Meaning
released / tested	an adapter exists and is tested
documentation_verified	official documentation was checked; an adapter can be built
research_only	candidate; documentation is partial or not yet reviewed in full
blocked	no public developer documentation, so no honest adapter is possible

Planned and research providers are listed on the providers page but are not analyzed and are never counted as supported.

Research for every implemented general provider is in docs/providers/research/. Every roadmap provider with public developer documentation is implemented. Pavilion Payments and Epoch publish no developer documentation and stay blocked.

Analyzable providers (as of 0.8.0)

Provider	Status	Group
Stripe	supported	general
Adyen	supported	general
payabl.	limited	general
Checkout.com	limited	general
PayPal	limited	general
Braintree	limited	general
Mollie	limited	general
Square	limited	general
Worldpay	limited	general
Cybersource	limited	general
Authorize.net	limited	general
Nuvei	limited	general
Paysafe	limited	general
Airwallex	limited	general
Rapyd	limited	general
dLocal	limited	general
EBANX	limited	general
BlueSnap	limited	general
PayU India	limited	general
Razorpay	limited	general
Paystack	limited	general
Flutterwave	limited	general
CCBill	limited	high-risk
Segpay	limited	high-risk
Verotel	limited	high-risk
NETbilling	limited	high-risk
PXP Financial	limited	high-risk
Trust Payments	limited	high-risk
emerchantpay	limited	high-risk
Ecommpay	limited	high-risk
Paymentwall	limited	high-risk
NMI	limited	high-risk
MiFinity	limited	high-risk
AstroPay	limited	high-risk
Skrill	limited	high-risk
eZeeWallet	limited	high-risk
Finrax	limited	high-risk
Inpay	limited	high-risk
DECTA	limited	high-risk
Trustly	limited	high-risk

The exact per-capability status and the list of limitations of each provider are on its page, for example providers/stripe.

Why most adapters are "limited"

"Limited" is an honest label, not a quality problem. Typical reasons:

• the provider sends no event id or timestamp, so duplicates and ordering cannot be checked;
• some formats are XML or only documented behind a merchant login;
• fields are configurable per merchant, so only the documented defaults can be read;
• refunds or chargebacks carry no link to the original payment.

How a provider gets added

1. Research from first-party documentation only, with every source recorded.
2. A qualification gate decides whether an honest adapter is possible.
3. The adapter is written against the research, with synthetic fixtures and tests.
4. Cross-detection tests check that it does not claim other providers' payloads.
5. It ships in a release, and the providers page and README update automatically.

See Contributing and High-Risk Providers.