How to run multiple store checkouts from one self-hosted OwnPay instance

The challenge of multi-store payment routing

Managing multiple storefronts often means dealing with fragmented payment software. Proprietary SaaS gateways force you into per-transaction cuts, rigid APIs, and vendor lock-in. If you operate three distinct brands, setting up separate processing workflows usually requires maintaining three application servers or paying heavy enterprise middleman fees. That approach drains engineering time and increases monthly overhead.

Self-hosted payment infrastructure solves this problem directly. Fattain Naime created OwnPay under the AGPL license to give merchants complete control over their revenue stack. OwnPay is an open-source, PHP-based payment gateway designed to run on your own server. It charges zero percentage platform fees. You connect your payment gateway credentials, retain your customer data, and keep all of your revenue.

One of its strongest features is its multi-brand architecture. From a single PHP installation, you can manage independent storefronts, attach distinct custom domains, assign isolated gateway plugins, and maintain unified accounting. Here is how to configure a multi-brand payment deployment on your server.

Step 1: PHP server deployment and domain mapping

Start by installing OwnPay on your PHP web server. The software drops onto standard PHP hosting setups and installs in under five minutes. Because you host the application on your server infrastructure, customer transaction data remains entirely under your control. It never flows through third-party telemetry systems.

Once the core application is installed, configure your web server to direct traffic from all your storefront domains to that single installation. Point your primary brand domains and custom checkout domains to the same server root directory. OwnPay inspects incoming HTTP host headers and resolves the brand context dynamically for every request.

Step 2: Configuring white-label brand contexts

With domain routing established, configure individual brand profiles inside OwnPay. Each brand gets its own isolated operational boundary within the installation. You can assign custom domains, merchant branding, custom color palettes, and specific team access roles to every profile.

White-labeling is absolute. Buyers experience your domain, your logo, and your SSL certificate during checkout. The word OwnPay does not appear anywhere in the customer journey. Customers buying from your primary brand see only primary brand assets, while buyers on a secondary store interact exclusively with that store's design, despite both running on the exact same server instance.

Step 3: Gateway configuration per brand

Different brands usually require different payment processors based on target markets and regional preferences. OwnPay features a modular plugin architecture supporting over 120 payment gateway plugins. Options range from global gateways like Stripe, PayPal, Adyen, and Authorize.Net, to regional processors such as bKash, Nagad, and SSLCommerz.

Each brand context manages its own gateway connections. If Brand A serves international buyers, you can attach Stripe and PayPal Checkout to that profile. If Brand B targets regional buyers, you can enable Nagad, bKash, or SSLCommerz without surfacing those payment methods to Brand A. Because you input your direct processor credentials, transaction funds land directly in your merchant account without intermediary delays.

Step 4: Automated accounting with double-entry ledgers

Processing payments across multiple storefronts often complicates accounting. OwnPay handles this at the core level by running a double-entry bookkeeping ledger system for all financial movements.

Every time a transaction completes, OwnPay creates balanced ledger entries. A credit to merchant revenue is automatically paired with an equal debit to customer receivables. Debits always match credits. This structure ensures your financial records are permanently audit-ready. Instead of spending hours matching multi-store payouts across spreadsheets at month-end, reconciliation takes seconds.

Step 5: Extending execution with plugin hooks and webhooks

To trigger fulfillment, sync customer records, or issue receipts, you do not need to modify core application code. OwnPay uses a WordPress-style plugin hook system built on familiar action and filter patterns.

If you have written code for WordPress, the syntax feels natural. Developers can register custom logic to execution points like the payment.completed hook. You can run custom PHP functions immediately after a transaction succeeds.

For external service integrations, OwnPay provides full REST API endpoints and HMAC-signed webhooks. When a checkout finishes, the server emits a cryptographically signed payload containing the payment event, currency, and amount. Your external services verify the signature and process backend orders safely.

Take control of your payment stack

Running your own payment gateway eliminates unnecessary transaction cut fees and removes vendor platform risk. With one PHP server running OwnPay, you gain multi-brand isolation, complete white-label checkouts, double-entry financial precision, and an extensible WordPress-style hook framework. You own your code, you own your transaction data, and you keep every dollar you process.