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: across rails — cards, ACH
debit, and USDC on the same checkout — and within merchant rulesets, not
between competing card acquirers.
Related