MasonXPay keeps payments moving when providers do not.
A self-hostable payment operations platform for teams that need provider choice, deterministic routing, billing workflows, and day-two payment visibility without stitching together a pile of tools.
Current authorization
$142.00 USD
Checkout
$142.00
Policy
US · card
Stripe US
timeout
Square
approved
Ops board
Next action
Keep Square active for US cards until Stripe latency returns under threshold.
Provider coverage
Useful payment orchestration resources
Guides and toolsLess feature catalog. More payment control room.
The product story is simple: get paid, route intelligently, and operate the mess that happens around payment providers.
Route around provider trouble
Send traffic through explicit route policies, capability checks, and account-level fallback instead of hardcoding one PSP path.
Keep billing close to payments
Customers, subscriptions, invoices, payment methods, and off-session payment attempts stay inside the same operating surface.
Know what happened
Signed webhooks, delivery replay, read models, metrics, and dashboards make payment operations inspectable after checkout.
The dashboard is built for the work after checkout.
MasonXPay is not just a payment form. It gives merchants the operating surface for customers, invoices, subscriptions, webhooks, route changes, and recovery work.
Payments
Search by ID, status, provider, date, and mode from projected read models.
Customers
Store merchant-scoped profiles and safe reusable payment-method references.
Invoices
Generate periods, run off-session attempts, write off, retry, or collect manually.
Webhooks
Rotate secrets, inspect deliveries, replay events, and keep payloads signed.
A real gateway core you can inspect.
The open-source repo includes the Spring Boot backend, Next dashboard, browser and server SDKs, simulator, monitoring assets, benchmarks, and deployment references.
64
logical payment shards
5
provider adapters
S1-S5
billing track delivered
$99
managed flat plan
A deliberately high stress gate for the payment core.
Most merchants will never sustain 100 payment charges per second. MasonXPay uses that load as a proof gate: if the core can clear it on constrained local infrastructure, normal merchant traffic has room for bursts, retries, provider latency, and operational workflows.
100 TPS
stress gate, not expected merchant baseline
190 TPS
directional local knee before saturation
0%
system errors in passing 100/s sweeps
Disclosed local rig
2 backend nodes at 2vCPU 4Gb each, isolated Postgres at 4vCPU 8Gb.
- A measured charge includes both create and confirm, not a single cheap endpoint.
- The simulator injects p50 120ms / p99 380ms provider latency, so the platform must preserve headroom under a realistic PSP tail.
- The current bottleneck is connection-pool hold time across provider latency, which gives a concrete next optimization target.
This is not a claim that every deployment should run at 100 TPS. It is a high-water test that makes the payment architecture, bottlenecks, and scaling path inspectable.
Read the full capacity proofBuilt for the 1000+ provider payment ecosystem.
MasonXPay starts with implemented adapters for today's supported providers and a catalog model for mapping PSPs, gateways, acquirers, wallets, BNPL, bank rails, local methods, and payout providers by market.
492
catalog entries
5
supported now
1000+
ecosystem target
Stripe
supported now
Square
supported now
Braintree
supported now
Mollie
supported now
Adyen
Ecosystem
Checkout.com
Ecosystem
PayPal
Ecosystem
Klarna
Ecosystem
Razorpay
Ecosystem
Mercado Pago
Ecosystem
Flutterwave
Ecosystem
Xendit
Ecosystem
Run locally, connect providers, publish routes.
Start with Docker Compose and Mason Simulator, then add real PSP credentials when you are ready to test provider-specific flows.
# local quickstart
$ git clone https://github.com/majianbing/masonxPay
$ cp .env.docker.example .env
$ docker compose up --build
Choose source code or managed operations.
Open Source
Free
Self-hosted MIT project with Docker Compose, source code, simulator, dashboard, SDKs, and docs.
View on GitHubManaged Pro
$99/mo
A flat managed plan for teams that want MasonXPay operated for them without transaction-volume pricing.
Get ProEnterprise
Custom
Private deployment, security review, dedicated support, and infrastructure matched to your operating needs.
Contact usFrom the blog
190 Charges/s on 2-vCPU Nodes: Benchmarking a Payment Core Honestly
How we load-tested the MasonXPay payment core with open-model k6, a log-normal PSP latency simulator, and injected faults — and why the bottleneck analysis matters more than the headline number.
Route Policies: Change Payment Paths Without Shipping Code
A practical look at MasonXPay route policies: account-level steps, conditions, capability checks, dry-run simulation, and audited publishing.
Why MasonXPay Uses Postgres Read Models for Dashboard Search
MasonXPay keeps payment state authoritative in Postgres shards while using payment_read_models for fast merchant dashboard search and filters.
Own the payment path.
Self-host for free or let us run MasonXPay for you.