If you run multiple businesses — or a platform serving multiple merchants — you've probably hit the same wall: each Stripe account is a separate island. Separate dashboards, separate API keys, separate reporting. Switching between them during an outage is manual, slow, and error-prone.
MasonXPay solves this with connector management: a unified layer that sits in front of multiple Stripe accounts (and other providers) and routes payments intelligently.
The Problem with Managing Stripe Accounts Directly
When you connect a single Stripe account to your application, the integration is straightforward. But as soon as you need multiple accounts, the complexity multiplies:
- Separate API keys per environment: each business entity has its own
sk_live_xxxandsk_test_xxx - No cross-account routing: if one account gets rate-limited or flagged, your only option is a code-level switch
- No unified reporting: comparing volume across accounts requires exporting CSVs from multiple dashboards
- No failover: if Stripe degrades in one region, you have no automatic fallback
How MasonXPay Handles Multiple Connectors
In MasonXPay, a connector is a configured connection to a payment provider account. You can add as many connectors as you need — even multiple Stripe accounts — and control routing through rules.
Step 1: Add Your First Connector
From the MasonXPay dashboard, navigate to Connectors and click Add Connector:
Provider: Stripe
Name: Stripe US Primary
API Key: sk_live_xxx
Weight: 70
Your Stripe API key is encrypted with AES-256 before storage. It never appears in logs or API responses.
Step 2: Add a Second Stripe Account
Add a second connector with a different Stripe account key:
Provider: Stripe
Name: Stripe EU Backup
API Key: sk_live_yyy
Weight: 30
With Weight: 70 / 30, MasonXPay routes approximately 70% of transactions to your primary account and 30% to the backup — using weighted random selection.
Step 3: Define Routing Rules
Weights give you probabilistic routing. For deterministic control, use routing rules. Rules are evaluated in priority order and support filtering by:
- Currency — route EUR transactions to your EU Stripe account
- Amount — route high-value transactions to a specific connector
- Country — route by the customer's billing country
- Provider — force a specific provider for certain transaction types
Example rule: always route EUR payments to the EU connector regardless of weight:
Priority: 1
Condition: currency = EUR
Action: route to "Stripe EU Backup"
Rules above weights — if a rule matches, weights are ignored for that transaction.
Step 4: Set a Primary Connector
The primary connector is the fallback used when no rule matches and weighted routing has no eligible connector available. You can designate any active connector as primary from the connector detail page.
Handling a Stripe Outage
If Stripe degrades or your account gets temporarily flagged, you have two options:
Instant manual switch: Go to Connectors, set the affected connector's weight to 0. All traffic immediately shifts to your remaining connectors. No code change, no deployment.
Automatic failover: MasonXPay retries failed provider calls and can be configured to mark a connector as degraded after a configurable failure threshold, automatically excluding it from routing until it recovers.
Viewing Connector Performance
The Connectors dashboard shows per-connector metrics: transaction count, success rate, and volume. You can see at a glance which account is handling which share of traffic, and whether any account has an elevated failure rate.
This is something you simply cannot do when each Stripe account is a separate integration in your codebase.
Beyond Stripe: Adding Square
The same pattern works for other providers. To add Square as a failover:
Provider: Square
Name: Square Fallback
Access Token: EAAAxxxxxxxxx
Weight: 0 ← set to 0 initially, increase when needed
Start with Weight: 0 so Square receives no traffic by default. When you need it — during a Stripe incident, for a specific market, or for testing — increase the weight without touching your application code.
Why This Matters for Platform Businesses
If you're building a marketplace or platform where each merchant needs their own Stripe account, MasonXPay's RBAC and multi-merchant architecture means:
- Each merchant connects their own Stripe credentials — they're stored isolated per merchant
- Your platform never sees their raw funds or statements
- Routing rules are configurable per merchant, not global
This is the model used by most payment-as-a-service platforms — and with MasonXPay you can self-host it entirely, with no per-transaction fees going to a middleware vendor.
Getting Started
Self-hosting MasonXPay takes about 5 minutes with Docker:
git clone https://github.com/majianbing/masonxPay
cp .env.docker.example .env
# add your JWT_SECRET
docker compose up --build
Open http://localhost:3000, register your account, and add your first connector from the dashboard. If you'd rather skip the ops, the Pro plan is $99/month fully managed.