Built for multi-tenant commerce from the foundation up
Real tenant isolation, custom domains, scoped team roles, and transparent metered billing. Run one store, run twenty.
Multi-tenant is a feature most platforms claim but few actually deliver. They call it multi-tenant, but every store shares the same database tables and the application code decides whether to filter by tenant. One bug in a filter and your data is everyone's data. One slow query on one merchant's catalog and every merchant's storefront slows down.
Mercemur is multi-tenant from the database row up. Tenant isolation is enforced at the storage layer, not just in application code that could be bypassed. Every store has its own data scope, its own custom domain, its own team configuration, and its own billing relationship with the platform. You run one store, you run twenty, the platform treats each as a real tenant with real boundaries.
The platform behaves the same way whether you have one tenant or a thousand. The boundaries do not bend for convenience.
The commerce core
One model underneath everything else. Every surface reads and writes the same records, under the same permission system, so a change made in the admin, through the API, by an agent or from the CLI produces the same state.
Catalog
Pricing
Customers
Orders
Inventory
Promotions
Checkout
Content
Identity
Workflow
Tenant isolation
Stores cannot see each other's data. Tenant boundaries are enforced at the storage layer with multiple layers of defense:
Storage layer scoping
Every record carries the tenant identifier
Query filtering
Every database query is scoped to the active tenant
Storage policies
Row-level security policies on every multi-tenant table
Application-layer checks
The application enforces tenant scope on every request
Per-tenant encryption keys
Sensitive data uses tenant-scoped encryption where applicable
Tenant isolation is enforced at the database layer through row-level security and application controls. Privileged cross-tenant operations are narrowly scoped, explicitly implemented and audited. Auditors get clear documentation. Compliance teams get clear evidence.
Extensibility
Extensions exist, and Mercemur connects to plenty of them. The difference is that Mercemur does not require an extension marketplace to make the core platform useful. Four routes out, all against the same commerce core:
Native integrations
Payments, shipping, email and analytics providers, maintained as part of the platform.
REST and webhooks
A versioned API over the same commerce core, with signed events for everything that happens.
MCP
Agent-driven workflows against the same model and the same permission scopes.
Enterprise integration
Scoped work for the requirements that do not fit any of the above.
Custom domains
Every store can map a custom domain.
What you get:
How it works:
Add the domain in the admin
Mercemur provides DNS configuration
You add the DNS records at your registrar
SSL provisions automatically once DNS resolves
The storefront is live on the custom domain
Platform reliability
Security as a feature
Security is not an Enterprise upcharge. The baseline includes:
Enterprise plans add:
Team roles and permissions
Invite teammates with scoped roles and permissions. Roles available out of the box:
Owner
Full access, including billing and team management
Admin
Full operational access, no billing or team management
Staff
Day-to-day store operations (orders, products, customers)
Fulfillment
Warehouse and shipping operations only
Customer support
Customer accounts, orders, and returns
Marketing
Campaigns, content, blog, analytics
Custom roles
On Enterprise, define your own permission scopes
Each role has its own scoped permissions. A Staff member cannot delete the store. A Fulfillment member cannot edit product prices. A Customer Support member cannot run a campaign. The boundaries are real.
Audit logs
The admin logs who did what:
Audit logs are available on all plans, scoped to admin actions. Enterprise plans add extended retention and exportability.
Mercemur consumption billing
Three tiers (Free, Growth, Enterprise), metered on storage, email, and API usage rather than on orders.
Metered event types:
Nothing taken at payment time
Mercemur takes no transaction fee. Stripe, Razorpay, and Adyen settle through your own provider accounts; Dodo acts as merchant of record and remits according to its own terms. Mercemur never holds the funds, and your subscription is billed separately, monthly, so nothing is skimmed per order.
Real-time usage tracking
Usage events are recorded as they happen. The admin dashboard shows current period spend with a forecast of where you will land.
Overage invoices generate automatically when usage exceeds plan inclusions.
Multi-store under one billing relationship
Multi-store operations get a unified billing relationship:
Useful for:
How it works
Sign up. Free to start, multi-store unlocks on Enterprise.
Create your first store. Pick a name, a default region, a default currency.
Map a custom domain. SSL provisions automatically.
Invite teammates. Assign roles (Owner, Admin, Staff, Fulfillment, Customer Support, Marketing).
Configure billing. Real-time usage tracking is on by default.
Scale. Add more stores under the same billing relationship as needed.
Audit. Audit logs are on by default, viewable from the admin.
Built for agencies
Agencies running ecommerce for clients get:
Built for multi-brand operators
If you run several brands under one parent company:
Common structures:
Use cases
Multi-brand operator
Three brands, three storefronts, three custom domains, one billing relationship. Each brand has its own team. Reports roll up at the operation level.
Agency
One agency account, ten client storefronts. Each client gets their own admin scope. The agency operator has access to all clients, the client gets scoped access to their own store.
International expansion
A single brand running three regional storefronts (US, EU, India). Each region has its own catalog, its own currency, its own tax rules, its own customer accounts. Customers in each region see only their local storefront.
Holding company
Multiple ecommerce subsidiaries under one billing umbrella. Each subsidiary is operated independently. Centralized usage reporting at the holding company level.
B2B operator
A wholesale storefront for trade partners (authenticated, customer-group-gated) and a public DTC storefront for retail. Two stores, one operation.
Frequently asked questions
Best practices for multi-store operations
Plan tenant structure before launch
A "tenant" is a real boundary. Customers, orders, products, and data are all tenant-scoped. Decide at the start: one tenant per brand, one tenant per region, one tenant per client. Migration between tenants is supported but harder than getting it right at the start.
Use the same admin operators across tenants when possible
Multi-store operators can grant the same operator access to multiple stores. The operator switches between stores in the admin without separate logins.
Configure per-tenant branding consistently
Each tenant has its own colors, logo, sender domain, payment provider connections. Document the per-tenant configuration so onboarding new operators is fast.
Set up audit logs and review them
Audit logs exist on every plan. Reviewing them periodically catches issues before they become incidents.
Plan for the second tenant before you need it
Even if you launch with one store, design your workflows so adding a second store is easy. Reuse-friendly content templates, shared catalog templates, consistent role definitions.
Multi-store scenarios
Two brands, two stores
A premium brand and a value brand under one parent. Each has its own storefront, its own customer base, its own marketing voice. Customers in each brand do not see the other.
Three regional stores
A US storefront, an EU storefront, an India storefront. Each in the right currency, with the right payment methods, with the right tax handling. Customers shop their local store.
Agency with ten clients
The agency runs ten client storefronts. Each client has isolated data. Agency operators access all ten through the admin. Each client has staff-level access to their own store only.
B2B operator with two storefronts
A public DTC store and an authenticated wholesale store. Different storefronts, different price lists, different shipping options. Customers in each segment see their own catalog.
Quick reference
Multi-tenant isolation at the storage layer. Custom domain with automatic SSL on every store. Team roles: Owner, Admin, Staff, Fulfillment, Customer Support, Marketing, custom roles on Enterprise. Three billing tiers: Free, Growth, Enterprise. Three metered dimensions: storage, email sends, API requests. Orders are never metered. Real-time usage tracking with bill forecast. Overage invoices generated automatically. Audit logs on every plan.
Get started
Start with one store, scale to twenty.
Start fast, compare plans, or talk through the details with us.