Multi-PSP payments
Most "multi-PSP" claims count logos. PAID counts something stricter: a
provider is live only when four independent pieces all exist. This page
explains the model and publishes where each provider actually stands.
The four-part gap model
"An adapter exists" means nothing on its own. A PSP is live and
merchant-connectable only when all four columns are satisfied:
- Adapter — a provider plugin implementing authorize / capture / refund / cancel, with a fail-closed guard when the provider is unreachable.
- KYB matrix — a machine-readable row describing exactly what KYB/KYC data that provider demands, so eligibility can be computed instead of guessed.
- Registry seed — the provider registered in the live provider registry, so the self-serve connect flow can see it.
- Credentials — real production keys.
Anything missing from that list means the provider is built but dark — real code, unreachable in production. We track and publish that state
instead of blurring it; see integrations for the
current table.
Where each provider stands
- Live: Stripe (cards — the only live card acquirer today), Circle (USDC — real on-chain disbursement, OFAC wallet-screened, fail-closed without a key), Plaid (bank link + ACH debit for money in).
- Built but dark: Dwolla (ACH payouts — adapter, KYB matrix, and registry seed complete; production credentials missing, so ACH payouts are not live yet), PayPal (complete adapter with live webhook handler; needs its KYB row, registry seed, and credentials).
Rather than fabricate an enrollment it cannot complete, onboarding refuses in
production when a rail's gap is open. Failing closed is a feature.
Why the KYB matrix is the interesting part
The four-part model is what makes automatic provisioning honest. PAID can
pull a merchant's already-verified business data from a rail they already
use, evaluate it against each provider's KYB matrix, and provision every
rail whose requirements the data already satisfies. The eligibility engine
answers "does this merchant already qualify for this PSP?" from the matrix —
not from a salesperson's optimism.
What multi-PSP changes for a merchant
- One integration; rails and providers change underneath by configuration, not re-integration.
- Adding a rail adds resilience: a buyer whose card fails can pay another way. See failover.
- Routing decides per payment, deterministically. See intelligent routing.
Related