Rules you configure
Routing is a stored rule set evaluated in priority order, not a fixed table in code. Rules are added and reordered without a deploy.
Infrastructure · RoutingWhere each payment
Where each payment
is routed, and why.
Routing is an infrastructure layer, not a setting. Every transaction is scored against currency, region, card brand, merchant category, risk tier and amount band, matched to a rule set you control, and sent to a processor that is passing its health check — with the whole decision runnable as a simulation first.
What the decision reads
CurrencyThe currency of the transaction
RegionWhere the transaction originates
Transaction typeCheckout, transfer, payout, subscription, refund
Card brandWhere the instrument is a card
Merchant categoryThe merchant category code
Risk tierThe risk level assigned to the transaction
Amount bandMinimum and maximum, in minor units
MerchantRules can be scoped to one company
Rules are matched on these attributes in priority order. Any of them may be left unset, in which case the rule matches every value.
RulesStored and hot-editable
SelectionWeighted and deterministic
HealthChecked before every use
FallbackOrdered, and recorded
The decision
One request. An ordered set.
Routing does not produce a single answer — it produces a ranked set, and uses the first member of it that is healthy. The rest stay in order behind it, which is what makes a failover instant rather than a recovery.
TransactionA payment to be routedCarrying its currency, region, type, brand, category, risk and amount
Rule matchRules evaluated in priority orderTies divide by weight, seeded on the transaction so retries pin
- FirstSelectedHighest priority, passing its health check
- SecondStandbyUsed if the first cannot be reached
- ThirdStandbyAnd so on, down the matching set
ResultThe processor used, and whyRecorded against the transaction, with each failover its own record
A processor only enters the set while its configuration is enabled and its health check is passing. A decline is an answer and stops here; an infrastructure fault moves down the set.
Per transaction
Four steps, every time.
The same sequence runs for a card acceptance, a transfer and a payout. What changes between them is which rules match, not how the decision is made.
- TransactionAttributes readCurrency, region, type, brand, category, risk and amount.
- MatchRules in priorityThe configured rule set is evaluated in priority order.
- SelectWeighted and gatedA weighted split among equal rules, health-checked before use.
- ExecuteFailover on faultAn infrastructure fault moves to the next healthy processor.
What the router does
Built to be inspected.
A routing layer that cannot be explained after the fact is a liability. Every choice here is made from stored rules, recorded as it happens, and reproducible.
Deterministic splitting
Where several rules tie on priority, traffic divides by weight. The draw is seeded on the transaction, so a retry lands on the same processor as the original attempt.
Health-gated selection
A processor is eligible only while its configuration is enabled and its health check is passing. An unhealthy processor is skipped rather than attempted.
Failover chain
The remaining matching rules form an ordered fallback. Each failover is written as its own record, so the path a payment actually took can be read back.
Simulation before rules
The same decision runs as a simulation that touches nothing — the routing a rule change would produce can be inspected before it is live.
Safe retries
Each attempt carries its own idempotency key, derived per processor, so a failover can never present as a second charge.
Operational detail
How it behaves.
The rules the engine follows, stated plainly — including where a decision stops and a deployment setting takes over.
BINK does not publish routing latency, throughput or success-rate figures. Nothing on this page is a performance claim.
- Rule model
- Stored routing rules, each with a priority and a weight. Highest priority wins; equal priorities divide traffic by weight.
- Tie-breaking
- A deterministic draw seeded on the company, user, amount and currency — the same transaction always resolves to the same processor.
- Eligibility
- Selection reads the processor configuration and its current health status. Only enabled, healthy processors are considered.
- Fallback
- When no configured rule matches, the request falls through to a built-in default per currency and transaction type.
- Failure handling
- An infrastructure fault — a timeout or an unreachable connector — moves to the next processor in the chain. A decline is an answer, not a fault, and is never retried elsewhere.
- Connector timeout
- Each attempt against a connector is bounded, so a slow processor cannot hold a transaction open indefinitely.
- Execution mode
- The routing decision is computed and recorded for every acceptance transaction. Whether the selected processor is then called outbound is a per-deployment setting.
Integration
What this looks like to build against.
Routing is deliberately not part of your request payload. The point of an orchestration layer is that the integration does not change when the path does.
- You do not choose
- There is no rail parameter to set on a request. You submit a payment; the engine resolves the processor from the rules that apply to it.
- The choice is returned
- The decision is recorded against the transaction, so the processor a payment used — and the reason it was chosen — can be read back afterwards.
- Rules are operated
- Adding, reordering, weighting and disabling rules happens in the admin console, behind role permissions, with each change attributable.
- Try before you ship
- The same decision runs as a simulation that touches nothing, so a rule change can be inspected against real attributes before it goes live.
In practice
What the attributes are for.
Each of these is a rule scoped to something the engine already matches on — not a feature to be requested.
Keep a corridor local
Scope a rule to a currency and region so payments in that corridor resolve to the processor you have chosen for it, without touching anything else.
Move traffic gradually
Give two rules the same priority and different weights to shift a proportion of volume, with retries pinned so a payment never changes processor mid-attempt.
Separate by value
Route above and below an amount differently, using the minimum and maximum bounds a rule can carry.
Isolate a merchant
Scope a rule to a single company where a commercial arrangement or a risk profile calls for its own path.
In the platform
What routing hands to.
A routing decision is the first step of a longer path. These are the surfaces that take over once a processor has been chosen.
Infrastructure
Every surface.
Routing ·How a transaction is matched to a processor.FX engineRates, locked quotes and currency conversion.Real-time SettlementThe lifecycle from captured to settled.Liquidity networkPer-currency pools and the movements against them.ReconciliationChecks that the books agree with the ledger.BankingThe regulated foundation the platform runs on.
Routing
Stop writing rail logic.
One integration, and the path is decided for you — on rules you can read, change and simulate.