Integrations
This is the honest provider table. "Live" here means all four requirements are satisfied — adapter, KYB matrix, registry seed, credentials — and that the rail keeps PAID from ever holding or moving a customer's money: PAID holds no money-transmitter licence. It is not a logo wall.
Live today
| Provider | Rail | What it does in PAID |
|---|---|---|
| Stripe | Cards | Card authorization, capture, refunds, charged on the merchant's own Stripe account; Stripe holds the funds and pays them out. The only payment method PAID offers today. |
| Plaid | Bank link | Verifies a merchant's payout bank account and its holder. It moves no money. |
Not offered
Code exists for these, but PAID does not offer them today, and none of them moves money for a merchant. They are listed so that nobody counts them as "supported":
| Provider | Rail | What exists / what is missing |
|---|---|---|
| Circle | USDC | Not offered. PAID does not send, hold or pay out USDC. |
| Plaid | ACH debit | Not offered. No ACH debit runs. |
| Dwolla | ACH payouts | Not offered. PAID cannot pay a merchant out over ACH. |
| PayPal | Wallet | Not offered. |
What "live" means — the four requirements
A provider only counts as live when its adapter, its KYB requirements matrix, its registry seed, and real credentials all exist. The full model — and why the KYB matrix is what makes automatic provisioning honest — is on multi-PSP.
Connecting a provider
Merchants connect providers through the self-serve connect flow; PAID can also pull already-verified business data from a rail you already use and provision every rail whose KYB requirements that data satisfies. When a gap is open, onboarding refuses rather than fabricating an enrollment. Wiring details: developer docs.
Related
- Payment orchestration — the pillar overview
- Intelligent routing · Failover
- Sub-processors — the data-processing view of these providers