当支付服务商不稳定时，MasonXPay 让支付继续前进。
一个可自托管的支付运营平台，面向需要多服务商选择、确定性路由、账单工作流和支付后运营可见性的团队，避免把一堆零散工具拼在一起。
当前授权
$142.00 USD
Checkout
$142.00
策略
美国 · 卡
Stripe US
超时
Square
通过
运营看板
下一步
在 Stripe 延迟恢复到阈值以下前，继续让 Square 处理美国卡交易。
服务商覆盖
少一点功能罗列，多一点支付控制室。
产品故事很直接：收款、确定性路由，并把服务商周边的运营问题处理清楚。
绕开服务商故障
通过明确的路由策略、能力检查和账号级回退分流，而不是把支付路径硬编码到单一 PSP。
让账单贴近支付
客户、订阅、发票、支付方式和离线扣款尝试都在同一个运营界面里处理。
知道发生了什么
签名 Webhook、投递重放、读模型、指标和看板，让结账后的支付运营可追溯。
Dashboard 面向结账之后的真实工作。
MasonXPay 不只是一个支付表单。它为商户提供客户、发票、订阅、Webhook、路由变更和恢复工作的运营界面。
支付
通过投影读模型按 ID、状态、服务商、日期和模式搜索。
客户
保存商户范围内的客户资料和安全的可复用支付方式引用。
发票
生成账期、执行离线扣款、核销、重试或手动收款。
Webhook
轮换密钥、检查投递、重放事件，并保持载荷签名。
一个可以检查源码的真实支付核心。
开源仓库包含 Spring Boot 后端、Next Dashboard、浏览器和服务端 SDK、模拟器、监控资产、基准测试和部署参考。
64
逻辑支付分片
5
已实现服务商适配器
S1-S5
账单阶段已交付
$99
托管固定价格
用一个刻意很高的压力门槛验证支付核心。
绝大多数商户不会持续达到每秒 100 笔支付 charge。MasonXPay 把这个负载作为证明门槛：如果核心路径能在受限本地资源上通过它，普通商户流量面对突发、重试、服务商延迟和运营工作流时就更有余量。
100/s
压力门槛，不是商户常态基线
185-190/s
本地饱和前的方向性拐点
0%
100/s 通过扫测中的系统错误
公开的本地测试资源
2 个 backend 节点，每个 2 CPU / 4 GB；nginx 为 1 CPU / 1 GB；隔离 Postgres 为 4 CPU / 8 GB；每个 backend 节点 40 个 Hikari 连接。
- 一笔实测 charge 同时包含 create 和 confirm，不是单个便宜接口。
- 模拟器注入 p50 120ms / p99 380ms 的服务商延迟，因此平台必须在接近真实 PSP 尾延迟下保留余量。
- 当前瓶颈是连接池在服务商延迟期间的持有时间，这给出了明确的下一步优化目标。
这不是说每个部署都应该跑到 100 TPS。它是一个高水位测试，让支付架构、瓶颈和扩展路径都可以被检查。
面向 1000+ 支付服务商生态构建。
MasonXPay 从当前已实现的服务商适配器开始，并用目录模型按市场梳理 PSP、网关、收单机构、钱包、BNPL、银行轨道、本地支付方式和付款服务商。
492
目录条目
5
当前支持
1000+
生态目标
Stripe
当前支持
Square
当前支持
Braintree
当前支持
Mollie
当前支持
Adyen
生态
Checkout.com
生态
PayPal
生态
Klarna
生态
Razorpay
生态
Mercado Pago
生态
Flutterwave
生态
Xendit
生态
本地运行，连接服务商，发布路由。
先用 Docker Compose 和 Mason Simulator 启动，再在需要测试真实服务商流程时添加 PSP 凭证。
# 本地快速开始
$ git clone https://github.com/majianbing/masonxPay
$ cp .env.docker.example .env
$ docker compose up --build
博客文章
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.
掌控支付路径。
可以免费自托管，也可以让我们为你运行 MasonXPay。