Shopify Multipass Replacement Solution

Authentication & Access
1

I have no idea what actual topic and tags should be applied here because nothing fit. So, here we are.

A little background. We made the switch to Shopify’s new account type three weeks ago. It was a chore – multiple pricing categories meant multiple price lists and catalogs, plus a bulk update for all the company and user data, plus all the other fun stuff that goes with that kind of migration.

We have our own ERP for managing customers, orders, shipping, discounts – everything needed to run a Shopify store, including a “Login As” built on Multipass. Well, you see the issue. Multipass doesn’t work with the new account types, at least not for pricing. We could still Multipass in, but if the customer had special pricing, we weren’t seeing it. That was on the list of things to fix before we cut over.

Along the way, I completely forgot about it. And then my boss texts me and says he’s not getting correct pricing when he logs in as a customer. Eesh.

A quick conversation with Claude and I had some work to do. The suggested route was OpenID Connect (OIDC). I found a provider offering 25,000 MAUs/month. Awesome. Except implementing it was a pain, and customers would have to change their password on first login.

Then I looked at rolling my own OIDC. That worked! Except customers often changed their Shopify password, which then didn’t match what we had in our ERP. Or they’d placed their first order on Shopify, which automatically created an account on our side when imported – but we had no idea what password to use, so the import just generated a random one.

So, since Shopify uses an emailed code to the address on file, I decided to give a different route a whirl. I took one of my accounts on Shopify, changed the email to another address I control, logged in, and got the code. It worked. I could place an order belonging to the actual customer account and then change the email back to the original and voila! Poor-man’s “login as”.

Then it was just a matter of integrating that into our ERP – a pretty easy flow:

  1. Click the “Place Order” button. Rather than multipass, this triggers a series of events:
    a. Opens a popup pointing to https://<mydomain>/account/logout and closes it.
    This ensures that any current shopify storefront in my session is logged out.
    b. Gets the current ERP admin user’s email.
    c. Changes the customer’s email via GraphQL to the admin user’s email.
    d. Displays a very prominent banner: “You are impersonating a customer. You have one hour. To switch back, click this button.” (An admin can only have one open swap at a time – trying to start another just generates a custom error.)
    e. Opens Shopify’s login page via a custom URL: https://account.<mydomain>/login?login_hint=<admin email>+<some random string>, which prefills the email field on the login form.
  2. Click Continue. This emails the code to the temporary email address.
  3. Grab the code and log in.
  4. Do what you need to do – usually place an order, diagnose a discount issue, diagnose pricing issues, etc.
  5. Click “Swap Out” in the ERP. This resets the customer’s email to the original and emails them the invoice, all via GraphQL.

As a backup, we have a cron job that runs every 5 minutes looking for swaps older than an hour and auto-reverts them, so no customer gets stuck with an email they can’t access.

It’s working incredibly well. The only issues: 1) the customer can’t log in with their own email until we swap back, 2) any existing Shopify session they have gets logged out, and 3) if they somehow place an order at the same time using their original email, a new account with that email gets created. That last one would be bad. So far, though, no issues.

I hope this can help anyone who is facing a similar issue and if you have feedback or improvement, post away! I’m no expert in this and I probably have some process bias that’s hiding some issues.

2

Hey @Chris_Schmidt1 - thanks for sharing the full write-up here.

I definitely get the use case, especially for staff-assisted ordering and B2B/customer-specific pricing flows. That said, I do want to be careful here: temporarily changing a customer’s email address so a staff member can receive the customer account login code isn’t something I’d recommend as a supported replacement for Multipass.

There are a few risks with that pattern, some of which you already called out: the customer can be locked out during the swap, existing sessions can be affected, duplicate accounts can be created if the customer acts at the same time, and there are broader privacy/audit concerns when a staff user is effectively authenticating as the customer.

For stores using customer accounts, Multipass isn’t supported. The supported path for bringing your own identity provider is an OIDC-compliant provider connected to customer accounts. I know that doesn’t solve every “login as customer” workflow that merchants built around Multipass, but I’d be hesitant to treat email-swapping as a safe long-term pattern.

If the core need here is staff-assisted order placement with customer-specific pricing, it would be helpful to know whether the blocker is mainly B2B pricing, needing to use the customer-facing checkout, or something else in the ERP/order flow.

Hope to hear from you soon. Happy to pass on a feature request at the very least, since I do get where you’re coming from in terms of this being a potential gap for sure.