One OwnPay install, several checkout identities: route brands deliberately

For a merchant with several storefronts, a shared payment installation can reduce duplicated operations. It can also create a subtle failure: a customer lands on the right checkout domain but sees the wrong brand, or an unintended payment option. The configuration work is not just visual. It is the mapping between a storefront, its checkout hostname, its identity and the gateways it should offer.

OwnPay is open-source, AGPL-licensed payment gateway software that runs on PHP servers. Its multi-brand architecture manages multiple storefronts, and its white-label checkout supports merchant branding and custom domains. It also integrates with more than 120 gateway plugins. Those building blocks make a multi-brand setup possible, but they do not make every boundary automatic. Treat the desired separation as a configuration and testing requirement, not an assumption.

Start with a brand map

Before changing a live checkout, write down one row for each storefront. Include the brand name, its public checkout hostname, the visual identity customers should see and the payment methods that business intends to offer. Record who owns each domain and who approves changes to that brand’s gateway list.

Keep the list specific. “Cards and local methods” is not a useful test plan. Name the actual gateway options that should appear, and name the ones that should not. OwnPay supports a broad plugin ecosystem, but a merchant’s installed gateways and commercial arrangements determine what is available in its own environment.

This map is also where operators catch mismatches early. Two storefronts may share a legal entity or infrastructure while serving different markets, currencies or customer expectations. Do not assume they should expose identical payment choices merely because they run through one installation.

Assign one hostname to each checkout identity

Choose a distinct subdomain for every brand’s checkout, using names that customers can recognize and that operations staff can distinguish. Point each hostname through the merchant’s normal DNS and web-server process, and arrange its TLS certificate before sending customers there. Those steps belong to the surrounding hosting environment; do not assume a payment application substitutes for DNS or certificate management.

Then verify the association between each hostname and the intended brand in the deployed setup. The exact configuration mechanism depends on the installation, so use its documented process rather than copying assumed menu names or configuration keys. Test the hostname directly, not just through a link from the storefront. A default or fallback checkout can hide a bad mapping until a customer arrives from an unusual path.

For each domain, inspect the rendered checkout as a customer would. Confirm the brand name and merchant styling, and check that links and return paths stay consistent with the storefront. Custom domains are part of the customer’s trust boundary. A polished logo on a checkout that has drifted to another brand’s domain is still a broken experience.

Scope gateway choices deliberately

Define the expected gateway list for each brand before enabling traffic. Where the installation supports brand-specific gateway selection, configure that list per storefront and verify it independently. Do not infer that a multi-brand architecture automatically guarantees separate gateway lists. If the deployment cannot enforce the required separation, pause before launch and resolve the limitation rather than relying on staff to remember which options belong where.

Run a simple matrix test: open each checkout hostname, confirm the intended identity, and compare the displayed payment choices with that brand’s approved list. Repeat after changing a plugin or adding a gateway. A shared installation makes changes easier to centralize; it also means one change can have a wider blast radius. Keep a record of which brands a change should affect and test the others for unintended changes.

For teams deciding which methods belong on which storefront, gateway coverage across regions is useful background. The same principle applies across brands: availability should follow the merchant’s operating needs, not the convenience of showing every installed option everywhere.

Separate brand presentation from security claims

Different names, domains and gateway lists create useful operational boundaries. They do not, by themselves, prove tenant-level isolation or separate access controls. If agency payment infrastructure serves multiple clients, document what is shared and what is separated in the actual deployment. Review access to the host, application, credentials and operational records under the policies that apply to that environment.

OwnPay includes a double-entry bookkeeping ledger, REST API endpoints and cryptographically signed webhooks. Those capabilities can support operational review, but they do not replace a brand-by-brand reconciliation and incident process. Decide who investigates a failed payment, who can change a gateway list and how a brand-specific issue is escalated.

Make the monthly check repeatable

Keep the brand map with the deployment notes. Each month, compare live hostnames and checkout options against it, and rerun the matrix after relevant changes. Record the result, including any mismatch and its owner. That routine is less exciting than adding another plugin, but it catches the mistakes that make a white-label payment gateway feel unreliable: wrong identity, wrong domain or the wrong choice at the payment step.

For multi-store merchants, the practical value of one self-hosted installation is centralized operation without forcing every storefront to look or behave alike. The useful test is simple: each brand should reach the right checkout, show only its intended payment choices and remain recognizable through the payment journey.