External PSP sandboxes are useful, but they are not always the best way to test payment operations. They can be slow, inconsistent, hard to reset, and sometimes blocked behind account onboarding.
MasonXPay includes Mason Simulator so teams can test routing, checkout, captures, refunds, outbox behavior, projections, and benchmarks without depending on an external provider.
What Mason Simulator Does
Mason Simulator behaves like a TEST-only payment provider inside the normal connector system. It exercises the same provider path as other connectors:
- provider account configuration
- route policy selection
- payment confirm
- capture
- refund
- webhook/outbox flows
- dashboard visibility
Because it is a normal provider adapter, simulator tests are closer to real runtime behavior than a mocked service call.
Preview Runtime
The preview stack enables the operational infrastructure used by the high-throughput track:
- Kafka outbox publication
- webhook consumers
- payment projection consumers
- Redis hot path
- Prometheus
- Grafana
- projection backfill controls
Run it with:
docker compose -p masonxpay-preview --env-file .env.preview -f docker-compose.yml -f docker-compose.preview.yml up --build
This is still a laptop environment, not a production durability test. It is useful for validating workflow, observability, and operational behavior before deploying.
Failure-Rate Testing
Mason Simulator can be configured for synthetic success and failure behavior. That makes it useful for checking:
- route fallback
- provider degradation behavior
- dashboard metrics
- retry visibility
- benchmark scenarios
Instead of waiting for a real PSP incident, teams can create predictable degraded conditions locally.
k6 Benchmarks
The benchmark profile covers create, confirm, refund, get, list, and idempotency replay flows. Results can be compared between the default Postgres-only mode and the optional Kafka/Redis infrastructure profile.
That gives operators a practical way to see whether infrastructure changes are helping the payment path or just adding moving parts.
Why Local Simulation Matters
Payment operations are not only about a successful card authorization. They are about what happens when the system is under pressure:
- provider latency rises
- a connector fails
- idempotency replays arrive
- projection workers lag
- webhooks need retry
- dashboard views need to stay useful
Mason Simulator exists so those cases can be tested deliberately instead of discovered in production.