White-label is one of the most over-used words in SaaS marketing. In the subscription-app category specifically, it usually means the portal interface can be rebranded — your logo, your colors, your fonts, no visible 'Powered by [vendor]' label. That part is straightforward and most paid plans include it. The interesting question is what white-label doesn't cover: the URL the portal lives on, the from-address of the transactional emails, the iframe origin if the portal is embedded, and the hosted payment-method surface that opens when subscribers update a card. Each of those is a place where subscribers can still see who built the portal even when the portal UI itself is clean. This guide walks through brand removal at each layer and what to ask your app vendor about each one. The companion guides are portal customization (the broader setup workflow) and custom domain (the URL piece in detail).
What 'white-label' actually means in this category
In the subscription-app world, white-label is shorthand for 'the portal looks like part of your store, not part of the vendor's product'. The minimum bar is: no 'Powered by [vendor]' badge in the footer, your logo in the header, your brand colors on buttons and links, your typography. Most paid plans on the major apps clear this bar. Free plans and starter tiers often do not — there's usually a vendor attribution somewhere that you can only remove by upgrading.
Beyond the minimum, the term stretches. Some vendors mean white-label = brand removal at the portal UI level only. Others mean it includes the custom domain so the URL itself is yours. Others extend it to transactional emails sent from your domain. Read the marketing carefully; pricing pages frequently bundle 'white-label' into a higher tier without specifying which layers are covered.
When evaluating a subscription app, don't just check the marketing for 'white-label included'. Ask explicitly: is the portal URL yours, are the transactional emails from your domain, can you remove the vendor badge from the footer, does the magic-link email look branded? Each of those is a separate layer and the answer varies between apps even at the same price point.
Logo, colors, and fonts — the obvious layer
This is the part everyone gets right. Upload your logo (SVG preferred, transparent background, sized to a 200px container), set your primary brand color, set your accent color, pick the typography. The portal renders with your visual identity instead of the vendor's. Setup is usually a few minutes and the preview updates live.
- Logo: appears in the portal header. SVG ideal; PNG with transparent background acceptable. Match the size of your storefront header logo for consistency.
- Primary color: applied to buttons, action links, and highlights. Pick from your brand guidelines exactly — 'close enough' produces a subtly-off portal that subscribers notice without being able to articulate why.
- Accent color: applied to secondary buttons, badges, and hover states. Usually a tint or shade of the primary.
- Typography: the single highest-impact branding setting. Match your storefront typeface exactly. Google Fonts import via URL; custom-licensed fonts need @font-face declaration in custom CSS.
- Button shape: rounded, sharp, or pill. Match your storefront button radius.
- Background and surface colors: light/dark presets, override to match storefront neutrals if needed.
Typography is where most stores under-invest and the polish difference is largest. A portal in your storefront's actual typeface — even with no other change — feels like part of the store immediately. A portal on default sans-serif feels like a generic tool product even with perfect colors. If you make one branding change, make it the typography.
What white-label does NOT cover: the URL
Most subscription portals run by default at a vendor-owned URL: yourstore.subscriptionapp.com, account.recurring-vendor.com, app.subscription-vendor.com, etc. The portal interface itself can be fully white-labeled, but if the URL still has the vendor's domain, subscribers see who built the portal every time they bookmark it, share it, or read the URL bar.
Custom domain is a separate feature from white-label, and it's where vendor scopes diverge most. Some apps include it on every paid plan; some gate it behind a higher tier; a few don't support it at all. If a true white-label experience matters to you, the URL is the layer to validate. The dedicated custom domain guide walks through the DNS and SSL setup in detail.
Subscribers who land at portal.yourstore.com — even with a default-themed portal — feel like they're on your store. Subscribers who land at yourstore.recurring-vendor.com with a perfectly themed portal still feel like they're on a vendor product. The URL is the single most-visible non-visual brand element. Fix it before the deeper customization work.
If your subscription app doesn't support custom domains, that's a genuine white-label gap and worth weighing against the rest of the offering. No amount of color and typography work in the portal UI compensates for a URL bar that says 'recurring-vendor.com'.
What white-label does NOT cover: transactional emails
Subscribers receive multiple transactional emails from their subscription: the magic-link login email, renewal-reminder emails, dunning emails when a card fails, cancellation confirmations, skip confirmations. By default these are sent from a vendor-owned email address — usually [email protected] or similar — even when the portal UI is fully white-labeled.
Most paid plans support sending these from your own domain ([email protected], [email protected]) but the setup involves SPF, DKIM, and DMARC records in your DNS. Without those records correctly configured, your domain's email reputation can drop and the magic-link emails start landing in spam — which breaks the entire portal login flow. The technical setup is documented separately in the subscription email and SMS providers guide.
- Magic-link email — the login flow. If this lands in spam, subscribers can't access the portal at all.
- Renewal-reminder email — the pre-renewal heads-up. Stores using these see lower involuntary churn.
- Dunning email sequence — sent when a card fails. Critical for recovering the ~5–10% of renewals that fail every cycle.
- Cancellation/skip confirmations — sent after each subscriber action. Low-stakes individually but visible.
- Order-confirmation email — sent by Shopify, not the subscription app, so this is already from your domain by default.
Some apps send emails from your domain by setting the From header without you actually configuring SPF/DKIM. The emails leave the vendor's mail servers but claim to be from your domain — which fails strict SPF checks and lands in spam. Always verify SPF and DKIM records before declaring the email layer white-labeled. The vendor should give you the exact DNS records to add; if they don't, the white-label claim isn't real.
What white-label does NOT cover: the iframe origin
Some stores embed the subscription portal inside their main storefront via an iframe — usually on a /account or /subscription-portal page. The iframe loads the portal content from the vendor's servers and displays it inline within your storefront's layout.
The iframe approach has a hidden white-label gap: the iframe source URL still points to the vendor's domain, and developer-tools-savvy subscribers (and competitors and journalists) can see this with a right-click → View Source. For most consumer subscribers it's invisible. For B2B subscribers and enterprise customers — especially those doing security reviews — it's a finding.
- Embedded iframe: visible to anyone who inspects the page source. The iframe src attribute shows the vendor URL.
- Full-page portal on custom domain: no iframe; the portal runs as its own page at portal.yourstore.com. No source-code leak.
- Hybrid: portal at custom domain, optionally linked from /account on the main storefront. Recommended for most stores.
If iframe embedding is important to your UX, pick an app that supports a same-origin iframe (the portal served from your custom domain so the iframe src is portal.yourstore.com, not vendor.com). Most modern apps support this. If your vendor doesn't, the cleanest fix is a full-page portal at the custom domain with a clear 'Manage subscriptions' link from the storefront.
What white-label does NOT cover: the hosted payment surface
When a subscriber updates their payment method in the portal, the actual card-entry form is hosted by Shopify (or the payment processor — Stripe, Adyen). The portal can't display a card form directly because that would put your store in PCI-DSS scope. Instead, the portal pops open a Shopify-hosted page or modal where the subscriber enters the new card.
Shopify's hosted payment surface is Shopify-branded by default. There's a small Shopify logo, the URL is shopify.com or shop.app, and the trust signals are Shopify's, not yours. This is fine — subscribers trust Shopify — but it's a place where 'white-label' breaks. You can't theme the Shopify-hosted page beyond the limited options Shopify exposes.
Subscribers trust Shopify-branded payment forms more than store-branded ones (the inverse of what you'd expect from a brand-consistency lens). The Shopify logo on the card-entry page increases the percentage of subscribers who complete the card-update flow vs an unbranded form. Don't try to white-label the payment surface even if your app offers a way to — you'd be trading conversion for brand consistency, and the math favours conversion.
How to evaluate a vendor's white-label claim
When comparing subscription apps, the marketing-page claim of 'white-label included' should trigger a checklist of follow-up questions. Get answers in writing — sales-team verbal claims about which layers are covered are notoriously unreliable in this category.
- Can I remove the 'Powered by' badge on this plan tier? (Yes / No / Higher tier required)
- Does this plan include a custom domain (portal.mystore.com)? (Yes / No / Higher tier required)
- Are transactional emails sent from my domain by default? (Yes / No / Manual SPF setup required)
- Does the vendor provide exact DNS records for email auth? (Yes / No)
- Is the portal iframe served from my custom domain when embedded? (Yes / No)
- After a major portal update, do my customizations persist? (Yes / No / Sometimes)
- If a 'white-label' setting is included in my plan, is the badge actually gone right now? (Yes / No — verify in live portal, not admin)
- What happens to the white-label on the magic-link email subject line and footer specifically? (Vendor-branded / Editable / My domain only)
Run this checklist against your current vendor as well, not just prospects. Stores that have been on a subscription app for a year often have a white-label gap somewhere — a footer badge that came back after an update, a magic-link email still sent from the vendor's domain — that they stopped noticing. A 30-minute audit closes most of these gaps quickly.
DIY portal vs vendor white-label
Some stores at significant scale consider building their own portal from scratch instead of using the vendor's white-labeled one. The argument is total brand control: every pixel, every URL, every email is yours by construction.
The argument against is engineering cost. A subscription portal that handles the four primary actions (skip, swap, update card, cancel) plus magic-link login, plus dunning, plus localization, plus mobile — is maybe 4–6 months of full-time engineering work to build well. Vendors who specialize have built and refined this over years. Most stores save more revenue by spending those engineering months on growth than they save by owning the portal themselves.
- DIY makes sense if: you have unusual subscription mechanics, you're at $5M+ subscription ARR with budget for a dedicated team, or you have a brand-critical custom flow no vendor supports
- Vendor white-label makes sense if: you're under $5M ARR, your subscription mechanics are standard (frequency, swap, skip), and the engineering team has higher-leverage work to do
- Hybrid makes sense if: you want a custom 'cancel save flow' or 'box builder' on top of vendor portal — most apps expose APIs for this without forcing full DIY
White-label portal FAQ
What does 'white-label' include at minimum?
At minimum: your logo in the portal header, your brand colors on buttons and links, your typography, and no 'Powered by [vendor]' badge in the footer. Most paid plans on the major subscription apps include all of these. Free or starter tiers often still show vendor attribution.
Is the URL part of white-label?
Usually no — custom domain is sold as a separate feature. The portal UI can be fully white-labeled while the URL is still yourstore.subscriptionapp.com. If true white-label matters, validate the custom-domain feature separately. See the dedicated custom-domain guide for setup.
Can I remove the 'Powered by [vendor]' badge?
Usually yes on paid plans, sometimes no on free plans. Check your plan tier in admin settings. After enabling badge removal, view the live portal (not the admin preview) to confirm the badge is actually gone. After major portal updates, re-check — the setting can occasionally reset.
Are subscription emails sent from my domain?
Depends on the app and your DNS setup. Most paid plans support sending magic-link, renewal, dunning, and confirmation emails from your domain — but you must add SPF and DKIM records to your DNS or the emails fail authentication and land in spam. The vendor should give you the exact records to add; if they don't, the email white-label claim isn't real.
What about the iframe source URL when the portal is embedded?
If you embed the portal in your storefront via iframe, the iframe src attribute is visible in page source. For full white-label, use an iframe served from your own custom domain (same-origin) — most modern apps support this. If your vendor doesn't, use a full-page portal at custom domain with a 'Manage subscription' link from the storefront.
Can I white-label the card-update payment form?
No — the card-entry form is hosted by Shopify or your payment processor for PCI compliance reasons. You can't theme it beyond the limited options Shopify exposes. This is actually fine for conversion: subscribers trust Shopify-branded payment surfaces more than custom ones.
How is white-label different from custom domain?
White-label is about brand removal at the UI level (logo, colors, typography, no vendor badge). Custom domain is specifically about the URL (portal.yourstore.com instead of yourstore.subscriptionapp.com). They're complementary — you typically want both for a truly branded subscriber experience.
Does white-label include the email designs?
Usually you can edit the email templates (subject, body, branding) in addition to sending from your domain. Confirm with your vendor whether the magic-link email design is editable or fixed; some apps lock the magic-link email template more tightly than the other transactional emails.
What if my vendor's white-label isn't complete?
Audit each layer (badge, URL, emails, iframe, payment) and decide whether the gaps matter for your subscriber base. For most consumer-DTC stores, gaps at the iframe and payment layers are invisible to subscribers. For B2B and enterprise stores, the URL and email layers matter most.
Can I white-label only the portal but not the storefront widget?
Yes — these are separate features and customized separately. The product-page widget has its own theming (usually via the theme app extension), independent of the portal's branding. Set both up consistently for a coherent subscriber experience.
Is white-label worth paying for?
Yes for almost any store taking subscriptions seriously. Visible vendor branding in the subscriber experience suggests 'this is built on someone else's product' rather than 'this is part of the store'. The retention and trust uplift from genuine white-label is large enough that the price difference between tiers is usually trivial.
Do I lose white-label customizations when the vendor updates the portal?
Most settings persist, but after major updates re-verify: the badge, the custom domain SSL, the email send-from address, the language strings. Vendors sometimes reset specific settings during architecture changes. Add a post-update verification step to your operational checklist.