Payment Routing and Settlement Operators
This note narrows routing-and-defaults and the payment-relevant slice of control-surfaces to hosted checkout, payout middleware, settlement-route infrastructure, and operator-run payment stacks.
Questions worth asking:
- Who chooses the default payment path, payout rail, or settlement sequence?
- Where do merchant onboarding, grant servers, treasury policy, or PSP menus become the real choke point?
- Is the user choosing a payment method, or inheriting a hidden route stack?
Canonical comparison set
- Grant and wallet-mediated payment initiation: open-payments and walletconnect-pay
- Checkout, deposit-route, and payout orchestration: bridge-xyz and coinflow
- Large operator default-path case: stripe
- Canonical asset and issuer-controlled settlement layer beneath many flows: circle-usdc and cctp
Keep the boundary clean
- This note is about who routes, retries, packages, and settles payments once a buyer has already decided to pay.
- If the important object is the reusable permission or paid-request envelope itself, that belongs in payment-auth.
- If the important object is the issuer rail or bridge attestation beneath the checkout shell, keep that layer separate too.
Useful traversal questions
- Where does the hidden payment state live: merchant dashboard, PSP config, wallet grant, or issuer rail?
- When a route fails or is disallowed, who decides the fallback?
- Is the payment surface really wallet-native, or operator-native with a wallet veneer?