One integration in front of every provider you use.
Capture, tokenization, routing, risk scoring, recovery, and reporting built as one system — so a decision made in the fraud prevention engine can change the route before the transaction is ever authorized.
- Integration surface
- One API
- Providers
- Bring your own MID
- Decision point
- Pre-authorization
- Deployment
- Your brand, your domain
Four planes, one API surface.
Each plane is independently useful. Together they close the loop: what the risk plane learns changes what the routing plane does, and both are visible in the data plane.
Capture & vault
Hosted fields, drop-in cashier, mobile SDKs, and a server-to-server API feeding a PCI-scoped vault. Universal tokens plus network tokens, owned by you and portable across providers.
Decision
The risk engine and the routing engine, evaluated together before authorization. One produces a score and a coverage decision; the other turns that into a route and a cascade ladder.
Connectivity
Adapters to the processors and alternative rails you already contract with. Adding one is a configuration entry, not an engineering project.
Data
Normalized ledger, settlement reconciliation, decline analytics, and merchant-hierarchy reporting — in the dashboard, over the API, and as scheduled exports.
The pieces are worth more when they share a decision path.
Bolting four vendors together gives you four integrations and no shared context. Built as one system, each component acts on what the others already know.
Risk informs routing
A marginal score does not have to mean a decline. The fraud prevention engine can send the transaction to a stricter MID or step it up to 3-D Secure instead of discarding a customer who was going to pay.
Routing informs recovery
The router already knows every path the transaction has not tried. A soft decline becomes a second attempt on a healthy MID inside the same checkout session, before the customer sees an error.
Outcomes inform both
Chargebacks, disputes, and approval rates flow back automatically. Models retrain against your real losses, and route weights shift toward the providers actually performing.
Everything lands in one ledger
Every attempt, score, route, fee, refund, and dispute is written to the same normalized record, regardless of which provider handled it.
However your portfolio is arranged, the platform routes around it.
Directly held MIDs, nested sub-merchants, and mixed portfolios all sit in the same hierarchy, with routing rules scoped to whichever providers each merchant belongs to.
| Structure | How the platform handles it |
|---|---|
| Bring your own MID | Connect the processing relationships you already hold and route across every one of them from a single integration. |
| Nested sub-merchants | Merchants inherit platform routing defaults and override only what you allow, with reporting scoped to their own volume. |
| Mixed portfolios | Merchants on different structures run side by side, each with rules limited to the providers available to them. |
| Multi-region | Route by issuer geography and currency, with per-region provider sets and per-region reporting. |
profile: us-cards-default version: 14 rules: - when: "brand == 'visa' and amount > 20000" route: [mid_01, mid_03, mid_07] - when: "issuer_country != 'US'" route: [mid_05, mid_03] - when: "risk.score > 0.62" action: challenge_3ds route: [mid_09_strict] cascade: on: [soft_decline, timeout, provider_error] max_attempts: 3 skip_when: "mid.cap_consumed >= 1.0"
Rules you can read out loud in a meeting.
Routing logic is the most consequential configuration in a payments stack, and it should not live in a black box or a support ticket. Rule sets are versioned, diffable, testable against live traffic in evaluation mode, and reversible in one action.
Bring your own MID. We will bring everything else.
Early access is opening to platforms running real volume. Tell us your stack and we will tell you plainly where the technology moves your numbers.