Goal

Fix the account-code mismatch blocking your Publish Your App page, so you can submit your iOS or Android build again — safely, without any risk of the publish routing to the wrong customer’s App Store or Play Console account.

This covers the most common cause: your site’s account code no longer matches what the MAM Suite server (WPMAM) has on file for it. That usually happens after a site gets moved, cloned, or restored.

Important: the safe fix here is to let verification realign the code on its own, or to contact MAM Suite support. Don’t hand-edit the account code, and don’t borrow a value from another site — even one you’re sure is right. The account code is what ties your WordPress site to your customer record, your subscription, and every app build you publish. Get it wrong, and a publish can end up in the wrong hands.

What the message means

Every MAM Suite site carries an account code — the enrollment ID your site was issued when it was first set up. It’s what ties this particular WordPress install to your customer record on the MAM Suite server.

Open Mobile App Manager → Publish Your App and the page runs a quick verification step before it lets you submit a build. It asks the MAM Suite server a simple question — “For this site’s URL, what account code do you have on file?” — then compares the answer to the code stored locally on your site.

• Match, and the page moves on without a hitch.
• Different, but the server recognizes your URL — verification quietly realigns your local code to match the server’s record and carries on. You don’t have to lift a finger.
• Different, and the server doesn’t have a code for the URL it’s seeing — because the site moved, was cloned, or is sitting on a staging address the server doesn’t know — the realignment can’t complete, and your local code stays out of sync. That’s the situation this article walks you through.

Verification is a guard — it’s there so a publish can never go out under the wrong customer’s account.

What causes the drift

Verification keys off your site URL, so drift almost always traces back to the site’s address — or its database — changing relative to what the server expects:

• The site moved — you switched domains, moved from a staging URL to the live one, or changed from http to https (or added/dropped www) — and the server’s record is still pointing at the old address.
• The site was cloned — a staging or development copy got spun up from a production database. The clone inherits production’s account code, but the server doesn’t recognize the staging URL as belonging to that account.
• The site was restored — a backup or migration brought back an older account code, one that no longer matches what the server has on record now.
• Two sites share a code — a copied database left the same account code sitting on more than one URL.

Nothing is actually “broken” in any of these cases. The local code and the server’s record have simply drifted apart, and until the server can confirm a code for the URL it’s now seeing, verification has nothing to quietly realign it against.

Prerequisites

• You are an admin on the WordPress site (you can reach Mobile App Manager in wp-admin).
• You know the site’s current, intended live URL — the address customers actually use.
• You know whether this site is your production site or a staging/clone. This matters: only the production site should publish.
• Your site can reach the internet (verification calls out to the MAM Suite server).

Steps

1. Confirm which site you’re on

Before you touch anything, work out whether this is even the site that should be publishing.

• On a staging or cloned copy? Stop here — staging sites aren’t meant to submit builds. Publish from production instead, and treat this mismatch on staging as expected, not a problem to fix.
• On production with the correct URL? Move on to the next step.

2. Confirm the site URL is the one you expect

Head to Settings → General and check WordPress Address and Site Address. If either one still shows an old domain, a staging URL, or the wrong http/https/www form, verification is comparing against the wrong address — no wonder it doesn’t match. Fix the URL to your live address first, then come back to the publish page. Many mismatches clear up right here, because once the URL is right, the server can finally match this site to its account.

3. Reopen the Publish Your App page

Head back to Mobile App Manager → Publish Your App. Just opening the page re-runs verification against the server.

Verification only runs once a day per code at most, though — so if you just fixed the URL and want an immediate re-check, the next step is how you force a fresh look.

4. Force a fresh verification (if it still shows the mismatch)

The result of that daily check is cached for up to 24 hours. There’s no button on the publish page to force a re-check — it runs on its own each time the page loads, but it skips itself if it already ran for the current code that day. So if you’ve fixed the URL and the page still shows the old state, don’t worry: the cache is probably just stale, not wrong. Reload the publish page once the cache window has passed, or ask support to trigger a fresh verification so you don’t have to sit and wait.

5. If it still won’t match, contact support

If the URL is correct, this is production, and the mismatch just won’t budge, this is support’s territory now. Reach out to MAM Suite support and include:

• Your site’s current live URL.
• The account code the page shows (if it’s displayed), plus whatever code you believe is the right one.
• A short note on what changed recently — moved domains, restored a backup, cloned from staging, and so on. This one detail does more than anything else to help support figure out which record is the authoritative one.

From there, support can confirm which account code the server holds for your site and realign the records on their end — so the next verification just passes.

What not to do

• Don’t hand-edit the account code just to make the warning disappear. If you set a value the server doesn’t agree with, the next verification will either overwrite it or block you again — and a wrong value risks publishing under another customer’s app account.
• Don’t copy an account code from another site. Each site and URL has its own enrollment record; there’s no shortcut here.
• Don’t publish from a staging or cloned site to “test” past the warning. Staging was never meant to be a publishing surface.

Why the safe path is realign-or-support

The account code is a frozen, load-bearing identifier. It ties your site to your subscription, your plugin entitlements, and — critically — the App Store / Play Console accounts your builds actually go to. A publish puts a real build under a real developer account, so verification deliberately refuses to guess. It will realign your local code to match the server’s record for your URL, but the server is always the authoritative source. For a stubborn mismatch, the safe move is to fix the URL or let support confirm the record.

Related

• Recipe: Customer enrollment and account code — how a site first gets its account code, and how enrollment ties the site to your customer record.
• Recipe: Publish your app to iOS and Android — the full publish workflow, including bundle IDs, version numbers, and submitting the build.
• Troubleshooting: staging vs. production sites — why cloned sites carry production’s settings and how to keep them from interfering with publishing.