White Label Domain

Overview

A White Label Domain gives the payment experience a merchant-owned web identity, such as a checkout subdomain. The application can call the provider’s API behind the scenes while keeping the payer on the merchant’s interface.

Domain configuration should use valid TLS certificates, restricted DNS access, secure deployment, and monitoring for certificate or record changes. A compromised checkout domain can replace addresses or payment amounts even when the provider API is secure.

The domain must interact safely with callbacks, return URLs, and APIs. Cross-origin policies, session handling, webhook authentication, and redirect allowlists should be designed explicitly.

A custom domain is one component of White Label Branding, not the entire white-label architecture. The payment data, status logic, infrastructure, and provider relationship remain separate concerns.

Users should be able to verify that the domain belongs to the merchant and see consistent support information. Anti-phishing guidance should warn that a familiar domain does not remove the need to verify network, address, and Expected Amount before sending.

Domain monitoring should include certificate transparency, DNS change alerts, content-integrity checks, and automated comparison of displayed addresses with API responses. A valid certificate only proves control of the domain, not that the page content is trustworthy. Incident plans should support rapidly disabling checkout while preserving order and payment evidence.

Payment-domain ownership should be separated from general marketing-domain administration where possible. Restricting DNS and deployment permissions lowers the chance that a routine website change compromises the checkout destination or callback flow.

Domain changes should use staged deployment and rollback because a broken redirect, cookie, or content policy can interrupt payment recovery and callbacks.