Connections

Integrate once.
Change providers without a rebuild.

Payout rails, screening, identity, messaging and evidence services sit behind canonical contracts inside the platform. Your integration is with Payzone; the provider behind a corridor is an operational decision, not a change to your code.

Read this before the table

An adapter being built is not the same as a rail being open.

Every route is gated twice: the adapter has to exist, and the exact country and method has to be certified and enabled in the registry for your entity. A provider listed as Built · not enabled has an authenticated, reconciled contract implemented and tested, and is held disabled until certification and commercial activation complete. We list it that way rather than counting it as coverage.

Payout rails

Getting the money to the beneficiary.

ProviderCapabilityState
Thunes Money Transfer v2 — quote create and read, transaction create, confirm and read, against the executed contract version. Built · not enabled
Dahabshiil Unified Remittance — token, account validation, send and transaction-detail polling, over allowlisted egress. Built · not enabled
Pilot simulator A rail that moves nothing, for proving the operation end to end. A simulating provider may only serve a simulated remittance and a live provider may only serve a real one — guarded in both directions, against a classification that cannot be edited after the fact. Moves no money

Settlement between principals is a separate thing from paying a recipient. How positions are netted and settled is on Clearing and settlement.

The registry

Onboarding a partner is not a deployment.

Payout partners are data, not a list compiled into the platform. Adding one is a record; it does not require a migration, a review and a release for what is a commercial fact about the world rather than a change to how the software works.

No closed vendor list

A fixed set of provider names in the schema is a hardcoded vendor list wearing a constraint. Every provider interface here stays open, so the partner a group brings with it can be added rather than argued about.

Retired, never erased

A partner that once carried payouts stays in the record permanently and is retired by status. It cannot be deleted while anything references it, because the transaction it executed still has to be explainable years later.

Compliance and identity

Deciding whether a transfer may proceed.

ProviderCapabilityState
Celmus Sanctions and PEP screening, compliance holds, case management and MLRO decisions. Screening runs before authorisation and fails closed. Implemented
Amazon Cognito Invite-only workforce identity and fresh reauthentication. Operational authority remains derived from current database assignments. Implemented
Entrust Production evidence retrieval bound exactly to workflow, agent, country and write-once storage. Implemented
Customer communication

Telling the customer, on the record.

ProviderCapabilityState
Amazon SES Transactional email with durable consent, budget, delivery and reconciliation controls. Implemented
Twilio SMS notification with the same consent, budget and delivery reconciliation boundary as email. Implemented
Amazon Connect Customer contact handled as a compliance record rather than as a separate support silo. Implemented
Why it is built this way

A provider is a dependency, not an architecture.

Each category has one canonical contract inside the platform. A provider implements it, is reconciled against it, and can be disabled without touching the transfer lifecycle or your integration.

Never a silent substitution

Which provider executed a payout is recorded on the transaction. A route change is visible in the record, not hidden behind an abstraction.

Never an inferred outcome

An unknown provider outcome stays unknown until reconciled. Nothing is marked settled because a request returned 200.

Need a rail we do not list?

Tell us the country, the method and the provider. We will tell you what implementing and certifying it involves, and what it does not.