# Custom domain A custom domain aligns hosted The Wallet Crew pages with the Brand identity. It also reduces phishing risk and improves trust when customers open enrolment or pass download journeys. By default, The Wallet Crew serves hosted pages on a The Wallet Crew domain such as `https://app.neostore.cloud//`. A custom domain replaces that public entry point with a Brand-owned domain such as `https://wallet.example.com`.
Real-world examples * A retailer uses `wallet.brand.com` for loyalty enrolment and card retrieval. * An event organizer uses `tickets.brand.com` for post-purchase wallet ticket download. * A Brand uses `registration.brand.com` to keep the web journey aligned with its email sender identity.
## Why use a custom domain The main goal is trust. A branded URL is easier to recognize than a shared platform domain. This usually improves conversion on sensitive flows such as enrolment, sign-in, and pass download. It also improves security posture. A dedicated subdomain makes spoofing easier to detect and keeps wallet-related traffic isolated from the main website. ### Before starting Choose the public domain that will host the journey. A dedicated subdomain is recommended, for example `wallet.example.com` or `registration.example.com`. The Brand also needs access to its DNS zone. All DNS changes are made there. {% hint style="info" %} This page covers the hosted web domain only. Email sender domains are configured separately. For email delivery, see [Email provider](https://docs.thewalletcrew.io/connect/email-provider) and [SendGrid](https://docs.thewalletcrew.io/connect/email-provider/sendgrid). {% endhint %} ### How the setup works Custom domains for hosted The Wallet Crew pages are handled through Cloudflare. The Wallet Crew prepares the Cloudflare-side configuration and provides the exact DNS records to publish. The Brand adds those records in its DNS provider. After the first validation succeeds, extra records can be required for domain ownership checks and certificate issuance. The Wallet Crew manages the hosted certificate lifecycle through Cloudflare once the DNS validation is complete. ### Configure the custom domain {% stepper %} {% step %} #### Select the public domain Pick the domain or subdomain that will be exposed to customers. Examples: * `wallet.example.com` * `registration.example.com` * `tickets.example.com` In most cases, a dedicated subdomain is the safest option. It avoids conflicts with an existing website and keeps wallet traffic isolated. {% endstep %} {% step %} #### Request activation from The Wallet Crew Share the chosen domain with The Wallet Crew. At this stage, The Wallet Crew prepares the hosted configuration and returns the DNS records required for validation and routing. {% endstep %} {% step %} #### Publish the DNS records Add the records exactly as provided by The Wallet Crew in the Brand DNS zone. The first set usually includes: * one routing record so the domain points to The Wallet Crew hosted pages * one or more TXT records for domain ownership or certificate validation The exact names and values are tenant-specific. They should not be guessed or reused from another environment. {% endstep %} {% step %} #### Complete the validation round Once the first records are visible in DNS, The Wallet Crew validates the domain. If additional records are required, The Wallet Crew shares them. Add those records, then wait for the final validation to complete. {% endstep %} {% step %} #### Test the journey end to end Before go-live, open the final URL and validate the full journey: * the page resolves on the custom domain * HTTPS is valid * the intended layout loads correctly * enrolment, sign-in, or pass download flows still work as expected If the custom domain is used with social sign-in, also update the allowed origins or callback configuration in the identity provider. {% endstep %} {% endstepper %} ### Example DNS records The exact records vary by tenant and by infrastructure state. The example below is anonymized and shows the typical pattern only. | Type | Hostname | Value | Purpose | | ----- | --------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------- | | CNAME | registration.example.com | app.neostore.cloud | Routes customer traffic to the hosted pages | | TXT | asuid.registration.example.com | 621ECF9549EAE65BA089A426C8142E089EF4C6916FB9AB9F21C111F30D85E816 | Domain ownership validation | | TXT | \_acme-challenge.registration.example.com | 7xLnjbponxeyiXkNsdIdrheyHHGouoFmfOXVvO9OAf8 | Certificate validation | | TXT | \_cf-custom-hostname.registration.example.com | cdea2f9a-2a68-48ed-a83d-88403213a690 | Additional custom hostname validation | ### Validate before go-live Use this checklist before exposing the domain publicly: * DNS resolves to the expected target. * HTTPS is active on the final URL. * The hosted page loads with the expected branding and language. * Any linked identity provider has been updated with the new domain. * Internal teams use the custom domain in campaigns, QR codes, and support scripts. ### Common pitfalls Most issues come from DNS or from other systems still pointing to the old domain. * **Using the root domain instead of a dedicated subdomain** can create conflicts with the main website. * **Publishing only the CNAME** is usually not enough. Validation TXT records are often required too. * **Testing too early** can produce false negatives while DNS is still propagating. * **Forgetting OAuth allowlists** can break Google, Apple, or Facebook sign-in on the new domain. * **Mixing web domain and email sender domain setup** causes confusion. These are related branding choices, but separate technical configurations. ## FAQ
Does a custom domain need to be a subdomain? No. A subdomain is strongly recommended to enfore brand authority. It is easier to isolate, safer to operate, and less likely to conflict with an existing website or mail setup.
Does the Brand need to provide its own SSL certificate? No. The Brand manages the DNS records. The Wallet Crew manages the hosted certificate lifecycle after domain validation succeeds.
Why can several TXT records be required? Different platform components can require different validation steps. One record can prove domain ownership. Another can validate certificate issuance. A third can validate the custom hostname configuration.
Can the Brand use Cloudflare Proxied DNS records? Yes. The Wallet Crew supports Cloudflare **Proxied** mode, often called the orange-cloud proxy or orange-to-orange proxy. This allows the Brand to keep its own Cloudflare security, routing, and traffic rules in front of the hosted The Wallet Crew pages, on top of the security controls already managed by The Wallet Crew.
Can the same domain also be used for email sending? The same brand namespace can be reused, but web hosting and email sending are separate setups. For example, a Brand can use `registration.example.com` for hosted pages and `no-reply@registration.example.com` for transactional emails. The DNS records and validation process remain different.
How long does the setup take? The timing mostly depends on DNS propagation and how quickly the required records are added. The practical sequence is simple: receive the records, publish them, wait for validation, then run an end-to-end test.
What else must be updated after switching to a custom domain? Any system that validates the public origin should be reviewed. Common examples include social sign-in providers, redirect allowlists, QR code campaigns, email templates, and support documentation that still references the default The Wallet Crew domain.
What happens if the selected subdomain already points somewhere else? That subdomain cannot point to two different targets at the same time. If it is already used by another service, either move that service first or choose another dedicated subdomain for The Wallet Crew.