Validated live domains, store-specific links and a safe plan for replacing old hostnames.
1. Plan the addresses
Each base domain has three roles: Console for your team, Checkout for customers and Public API for integrations. Default names are merchant, pay and api; you can choose others and add aliases.
| Role | First domain | Second domain |
|---|---|---|
| Console | merchant.example.com | panel.example.org |
| Checkout | pay.example.com | payment.example.org |
| Public API | api.example.com | api.example.org |
Both domains reach the same installation. They do not create separate wallets, data or access permissions. A store’s preferred domain controls generated links; it is not tenant isolation.
2. Add a domain or manage aliases
Open Settings → System → Domains. Use Add domain above Live domains for a new base such as example.org. Use Manage on an existing entry to add aliases or change primary addresses.
For example, keep both merchant and panel as console names. The first name, marked with a star, is primary for that role. Choose the primary base domain for system-wide default links.
A live base name is not renamed in place; add a replacement domain instead. Drafts show Pending activation and are not live yet. Choose Continue to DNS to save and review.
3. Point DNS to your VPS
Add an A record for every new hostname, pointing to the VPS IPv4 shown by the panel. Add AAAA only when that IPv6 address really reaches the server. Remove stale records; Wholly Crypto does not edit DNS for you.
Keep inbound TCP 80 and 443 open in server and provider firewalls. Leave your SSH access intact. Click Check DNS. It checks new or changed host/role pairs against authoritative DNS; unchanged live addresses are reused.
Using Cloudflare?
For the first installation, keep the proxy off until setup completes. Afterward you can use direct or proxied DNS without switching a mode in Wholly Crypto. Let’s Encrypt stays on the VPS.
Use Full (strict) ↗. Keep the HTTP certificate challenge reachable and bypass caching and browser/bot challenges for console, checkout and API requests. Wholly Crypto must be able to verify the origin too.
Authoritative checks bypass ordinary VPS/ISP address caches. Visitors can still have older cached DNS, and changes to nameservers can take longer.
4. Review, then publish
Saving a draft or passing DNS checks does not change live routes.
Review additions, removals and primary-address changes, then choose Continue to activation → Validate SSL & publish. Edits or a DNS check older than ten minutes require another check.
New addresses are checked for certificate challenges, HTTPS and the correct service. Unchanged live host/role pairs do not repeat those network checks, but the complete Nginx configuration is still validated.
Wait for success and the return to Live domains. Open each new hostname and check its role. On failure, read the deployment report and rollback status before retrying; do not delete the working domain to force activation.
5. Choose domains for each store
Go to Project → Stores → select store → Basic → Store domains. Choose the active merchant, checkout and API hosts for that store. Pending addresses cannot be selected.
Generated links use store choice → project’s default store → system default. For example, the invoice API’s links.checkout can use payment.example.org for one store while another keeps pay.example.com.
Configure SDK and shop-plugin API origins separately; changing a store preference does not rewrite your integration settings. Retained signed IPN/webhook retries keep their original links. Existing bookmarks and customer links are not rewritten.
Console aliases still require Basic Auth and an application login. Under Settings → System → Source IP restrictions, rules apply to each hostname separately. Keep customer checkout open unless you deliberately run a private checkout.
6. Replace old addresses in two stages
- Add and publish the replacement while the old hostname still works.
- Open the new console address and sign in. Test checkout and API access through their replacements.
- Update store preferences, integrations, bookmarks and published links. Keep old pay/API aliases while customers or clients still use them.
- From the new console address, manage the old domain or alias and stage its removal. Review and publish the change before removing its DNS record.
The panel prevents removing the console hostname you are currently using. Retired hosts are rejected, not automatically redirected. A primary-only change or removal still needs review and publication, even when no new DNS lookup is needed.