Every provider you process through,
on one connection model.
A debit company is a connection to a processor or acquirer, card rails and alternative payment methods alike. Configure the providers you work with, orchestrate traffic across them, and reconcile what each one actually settled.
One connection model, many providers
Every processor speaks its own protocol and returns its own codes. The debit company record absorbs that difference, so the rest of the platform routes, prices and reconciles the same way whichever provider handled the transaction.
A connection per provider
Each provider gets its own record holding the credentials, endpoints and integration parameters that provider needs. Even the credential field labels are configurable, so a processor that calls it a merchant ID and one that calls it an acceptor reference each read correctly to the operator entering them. Onboarding a similar provider starts by cloning an existing record rather than from an empty form.
Terminals under the provider
A provider is not one pipe. Terminals sit under the debit company, each with its own buy and sell rate, limits, 3-D Secure setting and status, which is what makes a single provider usable across merchants on different commercial terms. Reporting margin is tracked per terminal so the cost side stays attached to the route that produced it.
Normalised reply codes
Every processor returns its own response codes, and comparing them raw is how routing decisions go wrong. Each provider’s codes are mapped to the platform’s normalised set, so a decline means the same thing whoever returned it. That is what lets a cascade decide whether to retry elsewhere, and what makes decline analysis across providers meaningful rather than a column of vendor jargon.
Guardrails per provider
Providers are not equally safe to send everything to. Set a monthly chargeback limit, overall and per scheme, with the people to notify by email and SMS when it is approached. Restrict by country with an allow or block list, bound the amounts, and set how long a pending transaction waits before it is declined rather than left hanging. Refunds, partial refunds and dynamic descriptors are capability flags, because not every provider supports them.
Settlement and reconciliation per provider
Each provider settles on its own schedule in its own format, and the platform reconciles each one back against what it recorded. Fees and payout rules are configured per provider, each carries its own balance as a system account, and the processing monitor watches its declines so a provider going bad is an alert rather than a discovery.
How debit cycles run
- Submit
Terminals are created under the provider, each with its own buy and sell rate, limits and 3-D Secure setting.
- Track
Approved, declined and settled volume is visible per provider and per terminal, with declines mapped to normalised codes.
- Reconcile
Each provider file is matched against what the platform recorded, and anything unmatched is queued for an operator.
Frequently asked questions
Which debit companies are integrated?
The platform connects to 500+ acquirers, PSPs and alternative payment providers through the debit company module. Which of them are live for you depends on your deployment and your commercial agreements, so it is worth confirming the specific providers you have in mind.
What does a debit company actually represent?
A connection to one payment processor or acquirer, holding everything the platform needs to send traffic there: credentials and endpoints, the terminals underneath it, its fee and payout rules, its reply-code mapping and its notification settings. It covers card processing and alternative payment methods equally.
Can we run several providers at once?
That is the point of the model. Traffic is orchestrated across the providers you have configured, and because each one’s responses are normalised to the same set of reply codes, routing and cascading can compare them on equal terms rather than on vendor-specific strings.
How do we add a new provider?
A new provider is a new debit company record with its credentials, terminals and reply-code mapping. Where the new one resembles an existing provider you can clone that record and adjust it, which is usually faster than starting from an empty form.
How do provider fees reach the merchant statement?
Fees and payout rules are configured per provider, and the cost they produce flows into the settlement engine like any other transaction cost, ending up on the merchant statement with the rest of the breakdown rather than as a separate reconciliation.
Where is data hosted?
Hosting, retention and data residency are set per deployment rather than fixed, and each brand is served from its own domain. Tell our team what your regulator and your customers require and we will confirm the arrangement in writing.