Simulate a payment route before writing the policy.
Choose a sample payment context and failure class to see how provider capability checks and bounded fallback affect the route outcome. This is educational only; it does not process payments.
Search intent
Experiment with payment context and provider capability rules before designing route policies.
User job
Understand why a route picks Stripe, Square, Braintree, Mollie, Mason Simulator, or stops before provider calls.
Useful artifact
Interactive routing simulator plus route decision table.
Try a sample route decision.
Route outcome
Stripe
Primary selected
The primary eligible provider can process this sample payment context.
Evaluated providers
The operating rule before the tool.
Routing starts from payment context: country, currency, method, amount, capture mode, and provider account capabilities.
Providers that cannot support the context should be skipped before any provider call.
Fallback should happen only for configured soft failures and eligible backup providers.
Hard declines and provider-scoped token boundaries should usually stop the route.
Run the checks before shipping the workflow.
Payment context selected
Country, currency, method, and amount are known before route evaluation.
A route may pick a provider that cannot process the request.
Capability filtering applied
Unsupported providers are skipped before provider calls.
Avoidable failed provider calls add latency and noise.
Failure class known
Timeout, outage, hard decline, and unsupported method are handled differently.
Fallback may run for failures that should stop.
Signals, safe actions, and risks.
| Signal | Safe action | Risk |
|---|---|---|
| USD card in US | Stripe, Square, Braintree, or Mason Simulator may be eligible depending on policy. | Provider-scoped tokens still constrain fallback. |
| EUR local method in Europe | Mollie may be the preferred implemented adapter. | US-only accounts should be skipped. |
| Provider timeout | Fallback to next eligible provider if policy allows. | Late approval from the first provider must be reconciled. |
| Hard decline | Stop by default. | A second provider call may create customer confusion. |
Where this fits in MasonXPay.
Mason Simulator
The TEST-only Mason Simulator is useful for local routing, checkout, refund, projection, and benchmark workflows.
Route policy design
MasonXPay route policies should make provider order and fallback reasons explicit.
Provider adapters
Implemented adapters currently include Stripe, Square, Braintree, Mollie, and TEST-only Mason Simulator.
Common questions
Does this simulator make live routing decisions?
No. It is an educational page for understanding route-policy behavior.
Can this simulator process test cards?
No. It does not collect card data or call providers.
Use the tool, then inspect the payment path.
Compare orchestration with gateways, inspect route design, or review the open-source implementation.