Put a self-hosted checkout on your own domain

A branded checkout is more than a logo on a payment page. The checkout needs to load on a domain customers recognize, use a valid encrypted connection, and match the storefront that sent the customer there. With a self-hosted payment gateway, the merchant also owns the work of connecting those pieces.

OwnPay is open-source payment gateway software that runs on PHP servers. It supports white-label checkout with merchant branding and custom domains, and its multi-brand architecture can manage multiple storefronts. The exact configuration steps depend on your deployment, so use the documentation for the OwnPay version you run rather than assuming a particular dashboard or settings screen.

1. Choose the checkout address

Pick a hostname that belongs to your business and is easy to recognize, such as a dedicated payments subdomain. Decide which storefront it represents before changing DNS. If you operate several brands, keep a simple record of each brand’s intended domain, logo, and visual identity. OwnPay supports multiple storefronts, but the hostname still needs to lead customers to the right one.

Also decide whether the checkout should be hosted on its own hostname or reached as part of a broader site. That choice affects DNS and server setup. The trade-offs between a hosted page and a more API-driven flow are covered in how hosted checkout changes the scope of integration work.

2. Point the hostname at your server

At your DNS provider, create or update the record that directs the chosen hostname to the server running OwnPay. The right record and destination depend on your hosting setup. Check the result from outside your network before moving on; a stale or incorrect DNS answer can send customers to the wrong server or leave the hostname unreachable.

Make sure the web server serving OwnPay is configured to accept requests for that hostname. DNS alone does not make the application respond on a new domain. Keep the change narrow: do not redirect a live storefront’s main domain until you have confirmed the checkout hostname works as intended.

3. Set up TLS before sending customers

Configure a valid TLS certificate for the checkout hostname at the server or hosting layer. The certificate must cover the exact name customers will visit, and the server must present it when a browser connects. Renewals and certificate monitoring belong in the deployment runbook, not in a one-time launch checklist.

Test the address in a browser and confirm that it loads without a certificate warning. Check both the bare hostname and any alternate hostname you intend to support. If you are not sure where TLS terminates in your deployment, resolve that with your hosting or server operator before binding the domain to checkout.

4. Assign the domain and brand in OwnPay

Use the configuration documented for your OwnPay installation to associate the custom domain with the intended storefront or brand. Do not guess at a setting name, edit application files, or assume that a DNS change automatically selects the correct brand. If the installation has more than one storefront, verify the domain-to-brand relationship deliberately.

Then apply the merchant identity using the branding options available in your deployed version. Start with the business name and logo, and check that the logo remains clear at the size shown on checkout. Match the page’s colors to the storefront so customers can recognize the transition. OwnPay supports customizable white-label checkout; the available controls and their location should be confirmed in the documentation for your installation.

5. Match the page without patching core

Use the supported checkout theme or branding controls first. If your installation documents custom CSS, make small, scoped changes and review them at common screen sizes. If it does not expose custom CSS, do not assume that editing core templates is a safe substitute. Core edits can make future updates harder and may be overwritten.

Keep the payment form readable and the primary action easy to find. Branding should help a customer recognize the merchant, not compete with the details needed to complete a payment. Check the page on a phone as well as a desktop browser.

6. Test the complete customer path

Open the custom domain directly, then reach checkout through the route your storefront will use. Confirm that the address stays on your domain, the expected brand appears, the TLS connection is valid, and the page works at the screen sizes your customers use. If you manage multiple storefronts, repeat the check for every domain and brand pairing.

Finally, run a payment test using the procedures available for your configured gateway and verify that the result is handled correctly. A polished page is not proof that DNS, brand routing, and payment processing are all connected. Keep a record of the domain, certificate renewal process, brand assignment, and any theme changes. That gives the next operator a clear path to maintain the unbranded checkout experience without relying on memory.