Payment Router

Overview

A payment router is the component that sends a payment request to a selected provider, processor, acquirer, bank, wallet, network, or internal route. It applies routing decisions while preserving identifiers, request integrity, idempotency, timeouts, responses, and provider-specific operational behavior.

The routing decision should preserve eligible candidates, exclusions, input signals, selected route, fallback order, decision version, attempt identity, and final outcome. For Payment Router, this point supports the definition’s focus on payment router is the component that sends a payment request to a selected provider, processor, acquirer, bank, wallet.

Payment Router should remain distinct from Payment Gateway, because the two records can carry different authority, timing, and financial effects.

Important failure modes include loops, duplicate attempts, stale performance data, route concentration, unsupported currencies or geographies, provider outages, and optimization that ignores settlement or fraud outcomes. For Payment Router, this point supports the definition’s focus on payment router is the component that sends a payment request to a selected provider, processor, acquirer, bank, wallet.

Controls should prevent unsafe retries, distinguish business declines from technical failures, enforce provider and network eligibility, and record why a route was selected or skipped. For Payment Router, the authoritative record and completion rule should be documented before any irreversible operational, customer, or accounting action is released. Teams using Payment Router should preserve the evidence behind each decision so retries, corrections, support reviews, and audits can reproduce the final outcome. Changes affecting Payment Router should be versioned, tested under normal and degraded conditions, and reconciled after incidents or manual intervention.

Access to manual changes for Payment Router should be restricted, logged, and periodically reviewed, with reconciliation required after any intervention that changes financial or customer-facing state. For Payment Router, ownership should be assigned to a named team, and every exception should retain its source evidence, decision reason, approval, resolution, and closing timestamp. Configuration or rule changes affecting Payment Router should be versioned, reviewed, tested in normal and degraded conditions, and deployable with a documented rollback procedure.