One provider is a single point of failure. Several, unmanaged, are a maintenance burden.

Orchestration puts a routing and management layer between your systems and your providers. You integrate once, add or replace providers by configuration, and let rules — not engineers — decide where each transaction goes.

Routing profiles you can read.

A routing profile is an ordered list of rules. Each rule matches on transaction attributes and names a primary provider plus an optional cascade chain. Profiles are assigned per merchant, group or tenant, and versioned so you can see what changed and when.

Shown: a readable representation of the rule model. The exact schema is documented in the API reference.

// rule 1 — EU-issued cards, low valuematch: { issuer_region: "EU", amount_lt: 25000, method: "card" }
primary: "acquirer_a"cascade: ["acquirer_b"]
cascade_on: ["issuer_unavailable", "timeout", "do_not_honor_soft"]

// rule 2 — high-value, require 3DS challengematch: { amount_gte: 25000 }
require: { three_ds: "challenge" }
primary: "acquirer_a"// health policy — applies to all ruleshealth: { demote_when_error_rate_gt: 0.08, window: "5m", recover_after: "10m" }

Not every decline should be retried. Hard declines (stolen card, closed account) are final and retrying them harms your reputation with issuers. The engine maps each provider's response codes to a shared taxonomy and cascades only on retry-eligible outcomes.

Connectors we maintain, so you don't.

Each connector normalises authentication, request formats, response codes, 3DS flows and settlement files for a given provider. When a provider changes its API, we update the connector — your integration with AQ Pay doesn't change. We don't publish a provider logo wall; we'll confirm coverage for the providers you actually need during scoping.

See every route's performance — and act on it.