Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/own-pay/OwnPay-Documentation/llms.txt

Use this file to discover all available pages before exploring further.

A brand in OwnPay is the fundamental organizational unit — a fully isolated merchant entity that owns its own customers, transactions, payment gateways, staff members, and checkout experience. Understanding how brands work is essential before configuring anything else in OwnPay, because nearly every resource in the system belongs to a brand rather than to the global installation.

What Is a Brand?

Think of a brand as a complete, self-contained payment operation. When you create a brand, you are creating an isolated partition within your OwnPay installation. Data from one brand is completely invisible to another brand — there is no cross-brand customer leakage, no shared transaction history, and no staff member who accidentally sees another brand’s data unless they hold the master administrator role. Each brand has its own:
  • Customer database — Separate customer records with no cross-brand visibility
  • Payment gateways — Independent gateway credentials and configuration
  • Staff members — People scoped to this brand with their own role-based permissions
  • Checkout experience — Custom domain, logo, colors, and CSS
  • API credentials — Brand-scoped public/secret key pairs
  • Webhooks — Independent callback URL and event subscriptions
  • Ledger — A separate double-entry bookkeeping record for all transactions

Multi-Brand Architecture

A single OwnPay installation can host any number of brands simultaneously:
OwnPay Installation
├── Brand A (Acme Corp)
│   ├── Customers
│   ├── Transactions
│   ├── Staff Members
│   ├── Payment Gateways
│   └── Custom Domain → pay.acmecorp.com
├── Brand B (TechCorp)
│   ├── Customers
│   ├── Transactions
│   ├── Staff Members
│   ├── Payment Gateways
│   └── Custom Domain → checkout.techcorp.io
└── Brand C (StartupCo)
    ├── Customers
    ├── Transactions
    ├── Staff Members
    ├── Payment Gateways
    └── Custom Domain → pay.startupco.co
From an infrastructure perspective, all brands run on the same server, database, and OwnPay codebase. From an operational and security perspective, they behave as completely separate systems.

Brand Configuration Fields

When creating or editing a brand, the following fields are available:
FieldDescription
NamePublic-facing display name for the brand
SlugURL-safe identifier used in internal routing
CurrencyDefault currency for new transactions (USD, EUR, BDT, etc.)
TimezoneUsed for all timestamp display and report date ranges
Contact EmailReply-to address for customer-facing transaction emails

White-Labeling

White-labeling in OwnPay means that end customers interacting with the checkout page have no indication they are using OwnPay. The checkout is served under the brand’s own domain with the brand’s own visual identity. To fully white-label a brand:
1

Add a Custom Domain

Navigate to Settings → Domains within the brand context and add the brand’s checkout domain (e.g. pay.acmecorp.com). Then update your DNS provider to point that domain’s A record at your OwnPay server IP.
2

Upload a Brand Logo

Go to Settings → Branding and upload a logo. This image appears on the hosted checkout page, payment receipts, and email notifications.
3

Set the Primary Color

Set the primary brand color in Settings → Branding. OwnPay uses this color for checkout buttons, links, and accent elements.
4

Customize Email Templates

Edit the email templates in Settings → Email Templates to replace any generic language with the brand’s name, contact information, and support details.
5

Configure the Landing Page (Optional)

Go to Settings → Branding → Landing Page to add custom HTML or text for the brand’s public-facing landing page.

Domain Isolation

Each brand can be served on its own custom domain. When a customer visits pay.acmecorp.com, OwnPay identifies the corresponding brand from the incoming hostname, loads that brand’s configuration, and renders the checkout in that brand’s visual identity — without any OwnPay branding visible. The brand’s API also operates on its custom domain:
https://{brand_domain}/api/v1
For example:
https://pay.acmecorp.com/api/v1/payments
https://pay.acmecorp.com/api/v1/customers
This means that API calls from a brand’s application are scoped to that brand by virtue of the domain they target. You do not need to pass a brand identifier in the request body — the domain determines the brand context.
DNS propagation can take up to 48 hours after updating an A record. For SSL to work correctly on a custom domain, the DNS must be fully propagated before requesting a certificate. OwnPay will attempt to auto-provision an SSL certificate for the custom domain once DNS resolves correctly.

Brand Access Control

Access to brand data is governed by the role assigned to each user. There are three meaningful scopes:
RoleBrand Access
Master AdministratorAll brands — create, read, update, and delete any resource across the entire installation
Brand Manager / StaffOnly the brand(s) they have been explicitly assigned to
View-Only / AuditorRead-only access to the brand(s) they are assigned to
The master administrator is the only user who can create new brands and access data across all of them. Brand-level staff are fully confined to their assigned brand. See User Roles and Permissions for the complete RBAC model.

Use Cases

Platform Operators

Host payment processing for multiple businesses on one installation. Each business is a brand with complete data isolation.

Agency Owners

White-label checkout flows for clients. Each client gets a custom domain, logo, and checkout theme with no OwnPay branding.

Multi-Location Retailers

Use a single brand for the company and separate stores for each physical location or sales channel.

Enterprise Deployments

Isolate payment processing by division or subsidiary while maintaining a unified management console for the master admin.

Creating a Brand

1

Navigate to Brands

From the master admin sidebar, go to People → Brands.
2

Add Brand

Click Add Brand and fill in the brand name, default currency, timezone, and contact email.
3

Configure Payment Gateways

After the brand is created, switch to the brand context and go to Gateways → Add Gateway to connect at least one payment provider.
4

Invite Staff (Optional)

Go to People → Staff within the brand context to invite team members and assign roles.
5

Set a Custom Domain (Optional)

Go to Settings → Domains to add the brand’s checkout domain and begin the DNS configuration process.
You must create at least one brand before you can process any payment. The master admin dashboard manages brands but does not process payments itself — payments are always associated with a specific brand.

Build docs developers (and LLMs) love