Intelligent payment routing

"Intelligent" is an adjective; this page shows the mechanism instead. PAID's router is a thin, synchronous five-stage sequencer — every stage inspectable, every decision reproducible from its inputs.

The pipeline

payment intent
  → 01 context assembly      (merchant config, connected rails)
  → 02 jurisdiction resolve  (where this payment legally sits)
  → 03 candidate filtering   (drop rails that cannot execute it)
  → 04 ruleset hook          (merchant policy: narrow or refuse)
  → 05 cost evaluation       (price survivors, pick one plan)
  → execution plan

Stage by stage

• 01 — Context assembly. The intent is joined with the merchant's configuration and current rail state before any decision logic runs. Nothing downstream fetches data mid-decision.
• 02 — Jurisdiction resolution. Regulatory context is resolved up front, so filtering happens against where the payment actually sits — not against a global default.
• 03 — Candidate filtering. Rails that cannot execute this payment (wrong instrument, wrong direction, not connected) are removed from the candidate set.
• 04 — Ruleset hook. An optional merchant policy layer. It may pass all candidates through, narrow the set, or refuse the intent outright. With no ruleset configured, every stage-03 survivor passes through unfiltered — recorded as such, not silently.
• 05 — Cost evaluation. The only stage that does cost arithmetic: surviving candidates are priced and a single execution plan comes back.

Deliberate non-features

The router performs no retries, no caching, no sorting outside stage five, and spawns no goroutines — by design. Routing is a pure decision function: resilience lives in multi-rail structure, not hidden in retry loops inside the decision path.

Honest limits, today

• One live card acquirer. Card charges currently execute through Stripe — the only live card PSP — and checkout pins card charges to it. Cost-based selection between card providers begins when a second card PSP goes live; see multi-PSP for exactly what that takes.
• Where routing chooses today: within merchant rulesets on the one rail PAID offers — card payments through Stripe — not between rails or competing card acquirers.

Related

• Payment orchestration — the pillar overview
• Multi-PSP · Integrations
• Architecture — where routing sits in the full flow
• Developer docs