Payment Orchestration Router
Selects eligible payment routes and coordinates real-time execution and fallback.
Decides how a payment should move: whether the intent is consented and inside its mandate, which rails are eligible under policy, and what each route costs in fees, risk and time. Chooses only policy-eligible routes, processes duplicates safely, and steps down to a slower rail rather than failing the payment when a processor drops.
Authority
Execute within policy
Team role
Routes work to specialists
Handoffs
Named collaborators
The role
What it owns and where its authority ends
Desk
Routing, Authorization & Credentials
Desk workflow
Validate intent and credentials, choose an eligible route, apply authentication and authorization controls, send once, observe the response under retry policy, then hand accepted items to clearing.
Collaboration
Calls several specialists in parallel
Decision boundary
Acts only inside a defined mandate and action boundary.
Systems and capabilities involved
Rail and processor adapters
Authorization decision agent
Route optimization agent
Token and credential service
Rail health feed
Handoffs
What this role gives and receives
Capabilities offered
Policy-bound payment routing
Selects and executes an eligible route for a signed payment intent with safe fallback.
- Receives:
- Signed intent, consent, credentials, participants, route options, policy, and runtime health
- Returns:
- Selected route, execution state, response, trace, and any safe-retry action
Delegates
Obtain a policy-bound authorization outcome for the proposed transaction. Trigger: Identity, credential, intent, and minimum transaction data validate. Returns: Approve, decline, step-up, or refer outcome with reason and controls.
Delegates
Rank eligible routes across success, cost, latency, customer, and risk objectives. Trigger: More than one policy-eligible route remains. Returns: Ranked routes, predicted outcomes, confidence, and constraints.
Delegates
Resolve ambiguous timeout, duplicate, reject, or partial-state outcomes. Trigger: Execution does not reach a safe terminal state within retry policy. Returns: Resolved state, repair action, customer status, and ledger impact.
Handoff to
Receives from
Receives from
Context
What the role needs to do the work
- Current work
- Signed intent, route candidates, authorization state, latency, health, cost, risk, and retry budget.
- Prior interactions
- Recent route outcomes, timeouts, reversals, duplicates, and participant health.
- Policies and reference
- Rail eligibility, routing policy, consent, retry, fallback, and data-residency rules.
- Working method
- Not specified for this role.
Illustrative workflow
How the work moves
Starting point
A business sends an urgent supplier payment while its preferred instant rail is degraded.
- 01
Validate signed intent, beneficiary reachability, amount, consent, credentials, and eligible fallback rails.
- 02
Obtain authorization and rank eligible instant and same-day routes under health and cutoff constraints.
- 03
Execute the best eligible fallback once and correlate its response through clearing.
Result
Authorized payment routed on a safe fallback with customer-visible timing and complete trace.
Checks and boundaries
What must be tested or reviewed
- 01Chaos tests cover rail outages, processor degradation, late responses, duplicate callbacks and retry surges.
- 02Invariant tests require exactly-once business effect, valid consent, route eligibility, trace continuity, and no unsafe fallback.
- 03Optimization may never override sanctions, authorization, data-residency, customer, or rail-policy constraints.
Human authority
- Policy owners approve rail eligibility, fallback, retry, amount, geography, and exception thresholds; out-of-policy payments require authorized operations review.
Keep exploring