Most payment integrations start with one provider and one happy path. That works until approval rates dip, a provider has a regional incident, or the business needs different payment behavior by market, currency, amount, or method.
MasonXPay route policies let merchants change payment paths from the dashboard without deploying application code.
What a Route Policy Controls
A route policy is a versioned payment routing configuration. Instead of hardcoding if Stripe fails, try X in application code, the merchant can define:
- conditions that match payment context
- ordered provider-account steps
- account capability checks
- outcome actions for retry, fallback, or stop
- audited publish and archive behavior
The important part is that policies target concrete provider accounts, not just provider brands. A merchant can route to Stripe US Primary, then Stripe US Backup, then another provider account if the credential boundary allows it.
Why Simulation Matters
Routing rules are easy to misconfigure when they are only visible as JSON or code. MasonXPay includes dry-run simulation so a policy can be tested before it becomes active.
A merchant can simulate inputs such as:
amount: 14200
currency: USD
country: US
payment method: card
capture method: automatic
The simulator shows which route matched, which account steps were considered, and why a provider account was skipped. That makes policy review more like operating a system and less like guessing at a config file.
Capability Checks Before Provider Calls
MasonXPay checks account capabilities before attempting a payment. This prevents avoidable provider calls when an account cannot support the requested method, currency, country, capture mode, or reusable token type.
That matters for local payment methods and multi-region operations. A provider brand may support a method somewhere, but a specific merchant account may not support it for the current payment.
Audited Publishing
Draft route policies can be edited and simulated. Published policies become the active runtime configuration for a merchant and mode. Archive and publish actions are audit-backed, so teams can answer:
- who changed the routing policy
- when it changed
- what version was active
- which conditions and steps were published
This keeps routing operational without turning payment execution into an uncontrolled dashboard toggle.
Built for Conservative Fallback
Route policies work with MasonXPay outcome handling. Provider timeouts and outages can move to another route step. Hard declines and invalid payment method outcomes stop by default.
For card payments, MasonXPay also respects credential portability. Provider-scoped tokens stay on the provider account that created them. Cross-provider fallback requires a portable instrument or customer re-authorization.
That boundary is what makes route policies useful without making them reckless.