Routing Rules

The Routing Rules page (/routing-rules) is where you define your organization’s routing rules — records that target either every transaction (a global rule) or a specific merchant and, optionally, terminal from the shared catalog.

Caution

Routing rules are stored, not yet applied. CPS validates and persists them, and SVE/SME fetch and cache them alongside the rest of an org’s engine config, but no service currently evaluates a rule against a live transaction — there is no engine-selection or precedence logic behind this page yet. Treat what follows as the shape of the data you’re authoring, not a working routing pipeline: creating, editing, or deactivating a rule has no observable effect on transaction handling today.

What a routing rule is

Each rule has a scope, an expression, and an active flag:

• Scope is either global (matches every transaction for the org) or merchant (matches a specific merchant and, optionally, a specific terminal).
• Expression is the match target: for a merchant-scoped rule, the ISO 8583 card-acceptor identifiers (merchant_id, and optionally terminal_id) the rule is keyed to, picked from the shared catalog rather than typed by hand. A global rule carries no merchant or terminal target.
• Active marks whether the rule is meant to be in effect. The page’s toggle hint describes an inactive rule as “kept but not applied by the engine” — accurate in intent, though as the caution above notes, no engine applies any rule, active or not, at this time.

Row-Level Security scopes every read and write to your organization — you can only see and change your own org’s routing rules.

Global vs. merchant/terminal scope

• A global rule has no merchant or terminal target; it is meant to apply organization-wide.
• A merchant rule targets one catalog merchant. You may optionally narrow it further to one of that merchant’s terminals; leaving the terminal picker on “Any terminal” means the rule is meant to match every terminal under that merchant.

Because no evaluation logic exists yet (see the caution above), there is currently no defined precedence for what happens when a global rule and a merchant/terminal-scoped rule could both match the same transaction — that behavior has not been implemented or specified. Don’t rely on any assumed ordering between rules.

Create and edit

• Add rule opens a form scoped to your org. Choose Global or Merchant first — merchant scope reveals the merchant picker (required) and an optional terminal picker, narrowed to that merchant’s terminals from the shared catalog.
• Edit reopens the same form pre-filled for an existing rule, including its Active state.
• There is no delete action — deactivate a rule you no longer want in effect instead.

Listing rules needs the engine:read scope; creating and editing need engine:rules:write. A user with only read access sees the list without any “Add rule” or “Edit” controls, rather than a form whose save comes back 403.

See also

• Initiating a test transaction over REST documents how a transaction actually reaches Switchbench today — independent of the routing rules on this page.
• Behaviours is the mechanism that does affect live transaction handling today (forced approve/decline/timeout/etc. by network and BIN-prefix) — don’t confuse it with routing rules.