Payment Route Plan

Overview

Payment Route Plan is a versioned routing strategy that defines eligible route candidates, decision priorities, fallback order, constraints, and actions for uncertain outcomes. The plan filters candidates, scores or orders them, selects a primary route, and specifies when another route may be attempted after rejection, timeout, degradation, or outage. The relationship with Payment Route matters because one payment can appear as multiple requests, events, provider references, and ledger entries.

Its boundary with Payment Route Candidate must remain explicit so related records do not collapse into one status. The implementation must state responsibility, affected services, and the payment state it can change. The record should retain plan ID and version, scope, candidate definitions, priorities, weights, health inputs, retry and fallback conditions, attempt limits, approvals, and effective dates. Testing should cover success, rejection, timeout, duplicate delivery, partial completion, recovery, and the resulting accurate accounting records.

Controls should separate retry from reroute, define terminal and unknown states, cap attempts, require health evidence, simulate failures, version changes, and reconcile all attempted paths. It is the policy and contingency design; the payment route is the path actually used for one payment.

Important risks include unsafe failover, duplicate submission after timeout, cost-only optimization, circular fallback, stale provider assumptions, and plans that ignore settlement or reconciliation. When Payment Network Outage is involved, the link must be auditable so operators can decide whether retry, repair, return, rerouting, or adjustment is safe.

Changes to Payment Route Plan need controlled deployment and explicit ownership. 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.