Key facts at a glance
Shopify customer login after the 2026 migration
Last updated
- Trigger
- Shopify deprecated legacy customer accounts on February 1, 2026 and began automatic upgrades for low-customization stores in April 2026. Merchants get a notification on the day of the upgrade and a 30-day window to revert.
- Most common cause
- A third-party storefront app, typically a translation app like Weglot or an A/B testing app, is rewriting the OAuth callback URL and stripping the code and state query parameters during the handshake.
- Hallmark symptom
- The Liquid
{% if customer %}conditional returns false on your storefront even after the customer logs in successfully on the hosted account portal. Analytics globals like__st.cidstay empty. - Why it happens
- New Customer Accounts authenticate on a Shopify-hosted domain that is structurally separate from your storefront. The OAuth session does not sync to the storefront Liquid cookie automatically. By design under the new system, not a bug.
- Primary fix
- Add
/customer_authentication/*,/account/*, and/services/auth/*to the URL rewriter's exclusion list. If still within 30 days of auto-upgrade, reverting is a one-click alternative. - Distinctive failure mode
- Login looks successful from the customer's side. They see their order history and saved addresses on the account portal. When they navigate back to your storefront the navigation still shows Log in, the Liquid customer object is empty, and analytics globals never populate. Two parallel authentication universes, one healthy, one starved of session, on the same store.
Source: Shopify Help Center, Shopify Developer Forum threads on the new customer-account flow, and our hands-on repairs across stores auto-upgraded during the April 2026 wave. Get a quote in 60 seconds →
What changed in February 2026
On February 1, 2026 Shopify deprecated legacy customer accounts across all plans. The replacement is a Shopify-hosted account portal that uses OAuth 2.0 with PKCE for authentication and supports email one-time codes plus social login. The change shipped quietly for most merchants because nothing visibly broke on day one. The real impact landed in April, when Shopify began automatically upgrading stores that had no or minimal use of legacy accounts and no significant account customizations. Merchants receive a notification on the day of the upgrade and have 30 days to revert.
The new system is a real improvement on the security front. OAuth with PKCE is the same authentication pattern Google, Apple, and most major SaaS platforms use, and the hosted account portal closes off a class of customer-account vulnerabilities that legacy Liquid-based accounts left open. The cost of that security is that authentication now happens on a domain Shopify controls, not on your storefront. Your storefront Liquid still has a customer object, but it is populated from a separate cookie that does not sync automatically with the OAuth session on the account portal. For most merchants that is invisible. For stores with custom Liquid auth checks, B2B approval forms, headless setups using Multipass, or storefront URL rewriters, it broke a lot of things at once.
- February 1, 2026: Legacy customer accounts officially deprecated. New stores cannot opt in.
- April 2026: Automatic upgrades began for low-customization stores. Notifications sent on the day.
- 30 days after your upgrade: The revert window closes. After that, going back to classic accounts is no longer possible.
- Later in 2026: Final sunset date for legacy accounts. Shopify has not announced the exact day.
Which symptom matches yours
Several distinct symptoms all trace back to a small number of root causes. Find the row that matches what you are seeing and you will know which fix path to use.
| Symptom | Most likely root cause |
|---|---|
| Customer logs in successfully but the storefront navigation still shows Log in | Storefront Liquid is not syncing with the OAuth session on the account portal. This is the most common signature. |
| {% if customer %} or {{ customer.id }} is empty in Liquid templates after login | Same root cause. The hosted account portal authenticated the customer but the Liquid context on your storefront has not picked up the session. |
| __st.cid is undefined in analytics so customer email and name no longer flow into Meta or GA | Same root cause again. The analytics globals are populated from Liquid customer context, which is empty. |
| Customer reaches the OAuth callback URL but the session does not stick on your storefront | A storefront URL rewriter, typically Weglot or another translation or A/B testing app, is stripping or modifying the code and state query parameters during the callback. |
| Customer cannot log in at all. Login form returns No account found with that email | Customer record is in Invited or Disabled state from the migration, or an app removed the record. Login only accepts Enabled. |
| Login flow stalls after reCAPTCHA or just spins indefinitely | Third-party app interference, almost always one of the analytics, popup, or A/B testing apps loaded on storefront pages. |
| Custom B2B registration form is gone and account approval workflow is dead | New Customer Accounts removed the ability to fully replace the registration form. The replacement is Customer Account UI Extensions, which cannot replicate every classic-form pattern yet. |
Why login breaks on the new system
There are three root causes behind almost every broken-login report. Knowing which applies determines whether the fix is a settings tweak or a structural rebuild.
1. The storefront Liquid context does not sync with the OAuth session
Under legacy accounts, the customer logged in on your storefront domain and the same cookie that carried the session populated Liquid's customer object on every page render. Under New Customer Accounts the customer authenticates on a Shopify-hosted domain that is structurally separate from your storefront. The OAuth flow returns the customer to your store with a session token, but your storefront Liquid still reads the older storefront-cookie customer context, which can lag or stay empty even after a successful OAuth handshake. The visible signature is that {% if customer %} evaluates false, {{ customer.id }} is empty, and the navigation menu still shows the Log in link. Shopify staff confirmed in the developer forum that the new customer-account experience does not currently support Liquid customizations in the way the classic system did, and login happens on another domain, which is why customer state is not being recognized on the storefront. This is by design under the new system, not a bug.
2. A third-party app is rewriting the OAuth callback URL
Translation apps such as Weglot and Langify, A/B testing apps such as Intelligems, currency switchers such as Aelia, and any other tool that intercepts or rewrites storefront URLs can break the OAuth handshake. The new login flow returns the customer to your storefront with code and state query parameters that Shopify uses to verify the session. If a translation app rewrites the return URL to add a language prefix, the parameters drop or the destination path no longer matches the registered redirect URI, and the session fails to attach silently. The customer sees a successful login on the account portal but appears logged out everywhere on your storefront. Shopify staff have specifically called out Weglot for this and suggested adding /customer_authentication/* to the excluded URL list in Weglot settings. The same pattern applies to any storefront URL rewriter.
3. Customer records were left in a non-enabled state during the migration
Shopify customers carry one of four states: Enabled, Invited, Disabled, Declined. Only Enabled customers can log in directly. Under legacy accounts, many stores accumulated customers in the Invited state, meaning Shopify had emailed them an activation link they never clicked. After the migration, those records still exist but the New Customer Accounts login flow does not surface a useful path back to activation, so the customer sees a generic No account found with that email error. If the merchant tries to add the customer manually, the admin returns Email already taken because the existing record blocks it. The reconciliation is not automatic. Each affected customer needs to be opened in the admin and either re-invited from the new flow or transitioned to Enabled directly. Stores with thousands of legacy Invited customers need a bulk operation through the Admin API rather than a one-by-one fix.
DIY vs hand it off
If most of the left column matches your situation, you can probably fix this yourself in an hour. If the right column matches, hand it off and save the time.
Realistic on your own
- ✓You are still within your 30-day revert window and reverting is acceptable for your store
- ✓The breakage is limited to a translation or A/B testing app, and you have access to that app’s settings
- ✓Customer login works in a fresh incognito window with no extensions enabled
- ✓You can find the affected customer record in the admin and the state shows Invited or Disabled
- ✓You do not have a headless or Multipass-based setup
- ✓You can read browser DevTools Network tab confidently
Hand it off, save the time
- ✗You are past the 30-day revert window and the Liquid customer object is still null
- ✗Your storefront is headless or uses Multipass to bridge a custom frontend to checkout
- ✗You had a custom B2B registration form for account approvals and it is gone
- ✗Hundreds or thousands of customer records are stuck in Invited state
- ✗Customer-Account UI Extensions feel like a language you do not speak
- ✗The store is losing logged-in revenue every day and you cannot debug for an afternoon
How to diagnose the root cause
Run through these in order. Each step rules out a class of causes and points you to the right fix path.
In the admin, go to Settings then Customer accounts. Look for the upgrade banner. If it shows a Revert option, you are within the 30-day window. Note the date you were upgraded so you know how long you have. If the toggle still says Classic, your symptoms are not about the migration and the rest of this page does not apply.
Open an incognito or private window with no browser extensions enabled. Visit your storefront, log out, and log in again. If login works cleanly here, your day-to-day issue is browser state, an extension, or a logged-in storefront app. If login still fails in incognito, the issue is in your store configuration.
Open DevTools, Network tab, Preserve Log enabled. Click Log in on your storefront. Watch the redirect chain. It should hit shopify.com/authentication then return to your storefront with code and state query parameters intact. If those parameters are missing on return, or if the return URL was rewritten with a language prefix or a tracking suffix, a storefront URL rewriter stripped them. Note which app is responsible by checking which storefront extensions were loaded on the page.
Temporarily edit your theme to render the customer state. Add the line customer.id: {{ customer.id }} | __st.cid: {{ __st.cid }} to the bottom of your theme.liquid layout, save, and reload after login. If both values are empty even though the customer can see their orders page, the Liquid context is desynced from the OAuth session. If one or both populate, the desync is not your issue and the symptom you are chasing has a different cause.
In Apps, look for Weglot, Langify, Aelia Currency Switcher, Intelligems, Convert, anything labeled translation, A/B test, currency, popup, or storefront proxy. Pause them one at a time, retest login, and watch for the symptom to clear. The app that breaks login is almost always one that rewrites or intercepts storefront URLs.
If a specific customer cannot log in, find their record in the admin at Customers. Open the record. The state field shows Enabled, Invited, Disabled, or Declined. Only Enabled can log in via the storefront flow. Invited customers need to be re-invited or transitioned to Enabled. Disabled customers were turned off by an app or admin action and need to be re-enabled.
How to fix it
The fix depends on which root cause your diagnosis surfaced. Each branch below stands alone.
If a translation or A/B testing app is rewriting OAuth callbacks
Open the app's settings and add the auth-related paths to its excluded URL list. The exact menu name varies by app. In Weglot it is Settings then Language switch button then Excluded URLs. In Langify it is Settings then Translation rules. In Intelligems and similar testing apps it is the page-targeting or excluded-pages section.
Add at minimum these path patterns to the exclusions:
/customer_authentication/*
/account/*
/services/auth/*
/customer/auth/*Save, then test login in an incognito window. If login now works, the rewriter was the cause. If you have multiple URL-rewriting apps installed, exclude these paths in every one of them, not just the most obvious.
If the Liquid customer object stays null after login
This is the harder case because there is no Liquid one-liner that fixes the desync. The options are:
Revert within the 30-day window. Settings then Customer accounts then Revert in the upgrade banner. This is the right answer for the majority of mid-size stores that do not actually need the new accounts feature set yet. Caveat: any new app or extension installed in the meantime that depends on the new accounts may stop working on revert.
Rebuild the auth state read on top of the Customer Account API. Use the JS SDK in your theme to call the Customer Account API on page load and write the result into a window-level variable that the rest of your theme reads instead of {{ customer }}. This works but adds a client-side fetch on every page and shifts auth checks out of SSR, which has SEO and Core Web Vitals consequences for logged-in flows.
Wait for Shopify to mature the Liquid bridge. Shopify has acknowledged the gap and indicated improvements are coming. If your business can live with the current degraded state, the path of least effort is to do nothing structural and revisit in a quarter.
If specific customers cannot log in due to account state
In the admin go to Customers. Search the affected email. Open the record. Look at the state. If the state is Invited, click the option to resend the account-invitation email or transition the customer directly to Enabled. If Disabled, click to re-enable. The customer can then log in immediately.
For stores with hundreds or thousands of stuck Invited records from the migration, the manual path is not realistic. Use the Admin API customerUpdate mutation to flip state in bulk, or have a developer run a one-off script against the Admin GraphQL endpoint. We can do this as a flat-rate fix.
If you are headless or relying on Multipass
Multipass is being phased out alongside legacy accounts. Migrate to the Customer Account API authorization-code flow with PKCE. The new architecture requires:
- Registering a Customer Account API app in Shopify Partners with explicit redirect URIs
- Implementing the PKCE code-challenge handshake on your custom frontend
- Persisting the access token and refresh token across page navigations and tabs
- Refreshing the token before checkout to avoid mid-checkout session loss
This is not a swap-Multipass-for-OAuth quick edit. Plan it as a project. We do these migrations at a flat rate when scope fits.
Not sure which branch above applies, or do not want to read DevTools and theme code yourself?
Let us fix it in 2 hours →The 30-day revert window most merchants do not know about
When Shopify auto-upgraded your store, you received a notification email on the day of the upgrade. The email mentioned a 30-day revert window. Most merchants either missed the email or did not read past the first paragraph. The window is real, the revert button exists, and for many stores reverting is the right call.
Two warnings before you click Revert:
- 1.If you installed apps since the upgrade that depend on Customer Account UI Extensions or the new Customer Account API, those apps will lose functionality on revert.
- 2.The legacy system itself is on a countdown to a final sunset date Shopify will announce later in 2026. Reverting buys you time, not a permanent escape. Plan the eventual migration deliberately rather than letting Shopify auto-upgrade you again.
A real recent example
Anonymized from a recent repair so you can see how the diagnosis maps to the fix above.
A subscription box store on Shopify Advanced was auto-upgraded to New Customer Accounts on April 12, 2026. Two weeks later, customer support tickets started rolling in. Customers said login looked successful and they could see their orders, but when they returned to the storefront the navigation still said Log in. Subscription management links in the account portal worked, but the upsell logic on the storefront that used {% if customer.tags contains "vip" %} never fired for any customer, breaking the VIP pricing display. Revenue from the upsell module had dropped 18% week over week.
Incognito reproduced the issue. The store ran Weglot for French and Spanish translations. DevTools showed the OAuth callback returning to /fr/customer_authentication/oauth/callback instead of the registered /customer_authentication/oauth/callback, with the state parameter intact but the redirect URI no longer matching what Shopify had registered. The session attached on the account portal, where Liquid is not involved, which is why the orders page worked. The storefront, which renders through Liquid and reads the storefront cookie, never picked up the session because the OAuth bridge had failed silently.
Added /customer_authentication/*, /account/*, and /services/auth/* to Weglot's excluded URL list. Cleared the Weglot cache. Verified the OAuth callback now returned to the un-prefixed path with all parameters intact and the customer session attached on the storefront. Verified {% if customer %} was now truthy after login. The VIP upsell pricing display started firing again on the next customer login. Total time including support handoff and verification was 73 minutes.
When to stop and let us take over
Three scenarios where DIY is not the right call. First, if you are past the 30-day revert window and the storefront Liquid customer object stays null after login. The fix here is a structural rework of how your theme reads auth state, not a settings tweak, and it has SEO consequences if done badly. Second, if your store is headless or relies on Multipass and customers were authenticating through a custom frontend. The replacement Customer Account API flow is a real project, not a swap. Third, if hundreds of customer records are stuck in Invited state from the migration. Fixing those one by one is impossible and the Admin API bulk path needs care to avoid sending unwanted invitation emails. Our flat rate is $49 to $149, we finish in two hours, and we refund in full if we cannot.
Get a quote in 60 secondsShopify customer login FAQ
Why does {% if customer %} return false on my Shopify storefront even after a customer logs in?
Because New Customer Accounts authenticate the customer on a Shopify-hosted domain that is separate from your storefront. The OAuth session lives on the account portal. Your storefront Liquid only sees the storefront cookie, which does not pick up the OAuth session automatically. The Liquid customer object stays null until Shopify reconciles the session back to your storefront, which can fail if a third-party app rewrites or proxies the callback URL. This is by Shopify design under the new system, not a bug, and it is the single most common surprise after the migration.
I never enabled New Customer Accounts manually. Why is my store on it now?
Shopify began automatic upgrades in April 2026 for stores with no or minimal use of legacy accounts and no significant account customizations. You receive a notification on the day of the upgrade and have 30 days to revert. If your customer login broke recently and you did not knowingly change anything, check Settings then Customer accounts for the upgrade banner. If you are within the 30-day window, reverting is one click. Many merchants miss the notification email and only notice the change when login traffic starts dropping or support tickets come in.
How do I tell whether a translation or A/B testing app is breaking my OAuth login?
Open browser DevTools, switch to the Network tab, attempt a customer login from your storefront, and watch the redirect chain. The flow should bounce to shopify.com/authentication, then return to your storefront URL with code and state query parameters intact. If those parameters are missing on return, or if the return URL was rewritten with a language prefix like /fr/ or /es/, the rewriter stripped them. Weglot, Langify, and several others all do this on storefront paths by default. Add /customer_authentication/, /account/, and /services/auth/ to the excluded URL list in the app settings and retest.
My customer can see the order history page after login but the navigation still shows Log in. Is this the same problem?
Yes, this is the storefront Liquid desync signature. The OAuth session is valid, which is why the hosted account pages render correctly. Your theme navigation runs through Liquid, and Liquid does not see the OAuth state on the first redirect back. Many merchants discover that clicking the storefront logo a second time fixes the display temporarily because Shopify re-syncs on the second request, but the cookie still drops on browser navigations between subdomains. The proper fix is either to revert within the 30-day window, to rebuild navigation auth state on top of the Customer Account API, or to live with the redirect-twice pattern. There is no Liquid one-liner that solves it.
Multipass stopped working after the migration. What replaces it for headless or custom-frontend stores?
Multipass is being phased out alongside legacy customer accounts. Shopify points headless merchants to the Customer Account API with the OAuth 2.0 authorization-code flow plus PKCE. The migration is materially more complex than swapping a Multipass token. You need to register an app in Partners, configure the redirect URIs, implement the PKCE handshake on your custom frontend, and persist the session token across page navigations. If your headless build relies on Multipass today, expect the rebuild to be a project, not a quick edit. We do these migrations as a flat-rate fix when scope fits.
A customer says the login form gives them No account found, but adding them manually says Email already taken. What is happening?
The customer record exists but is in a non-enabled state, typically Invited or Disabled. Shopify tracks four customer states: Enabled, Invited, Disabled, Declined. The login form only accepts Enabled. The admin add-customer form sees the existing record and refuses the duplicate. The fix is to find the customer at Customers in the admin, open the record, and either resend the activation invitation if the state is Invited, or change the state to Enabled. After the legacy-to-new migration, some customers slipped between states during the conversion and need this manual step. Bulk operations are possible through the Admin API for stores affected at scale.
Our B2B store had a custom registration form for account approvals. The migration killed it. Can we get it back without reverting?
Not in the same form. The new customer-accounts system removed the ability to fully replace the registration form with custom Liquid markup. The replacement path is Customer Account UI Extensions, which give you React-based blocks rendered inside the hosted account portal, plus the Customer Account API for backend approval workflows. UI Extensions are improving but still cannot replicate every classic-form pattern. For mid-tier B2B stores the realistic options are reverting within the 30-day window and waiting, moving the approval flow to a pre-checkout form on the storefront, or building UI Extensions plus an external approval service. We help merchants choose between these depending on stack and timeline.
Sources and further reading
Every Shopify-specific claim on this page is grounded in Shopify's own documentation, the developer forum, or our hands-on experience fixing post-migration login on Shopify stores.
- Shopify Help Center: Customer accounts overview
- Shopify Help Center: Upgrading to customer accounts from legacy customer accounts
- Shopify Help Center: Setting up and managing customer accounts
- Shopify Developer Forum: New customer account login issue on return to storefront
- Shopify Community: Issue with new customer accounts login (Customer liquid object null)
- Shopify Community: Are you all migrating to the new customer accounts?
- Shopify Dev Docs: Customer Account API authorization-code grant