01
Integration categories
| Category | Purpose | Examples of scope |
|---|---|---|
| Payment providers | Acceptance and transaction operations | Authorisation, capture, refund, status, webhooks |
| Payout providers | Individual and batch disbursement | Beneficiary, payout, status and return handling |
| KYC / AML services | Verification and screening | Checks, decisions and operational review states |
| Client systems | Merchant and transaction exchange | API, webhooks, back-office and reporting feeds |
| Finance systems | Reconciliation and accounting handoff | Provider reports, ledger exports and exception files |
02
What “supported” should mean
A provider logo is not enough. The required methods, countries, transaction operations, asynchronous events, refunds, payouts, reports and certification steps all need to match the intended flow. PulsePay confirms those details before committing an integration to scope.
03
How a new connector is assessed
- API and documentation quality
- Required payment and payout operations
- Authentication, signatures and network controls
- Webhook, retry and idempotency behaviour
- Sandbox, certification and production-access process
- Reconciliation files and operational reporting
04
Start with the real flow
The fastest way to confirm fit is to share the providers already contracted or shortlisted, the methods and geographies required, and the exact transaction lifecycle. PulsePay can then identify existing coverage, gaps and the work needed for production readiness.
FAQ
Frequently asked questions
- How many provider integrations does PulsePay have?
- Connector availability changes as deployments evolve, so the current set is confirmed during discovery. PulsePay does not present a large logo count as a substitute for validating the exact methods and operations a client needs.
- Can PulsePay build a new provider connector?
- Yes, subject to API access, provider cooperation, technical feasibility and an agreed implementation scope.