Goal

Fix the account-code mismatch warning on 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 answer the address-changed notice, 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 asks the MAM Suite server: “For this site’s URL, what account code do you have on file?” It compares the answer with the code stored on your site.

• Match, or the server has no code for this URL: no warning.
• Different: the page shows a yellow Account check warning with both codes. It does not change your code. Publishing uses the code stored on this site, so check with support before you publish.

The page never switches your code to whatever the server finds for the URL. Doing that could move your site onto another account, and your purchases and publishing would no longer follow it.

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 for this URL have drifted apart, and the warning tells you so.

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. Answer the address-changed notice, if you see one

If the site moved or was cloned, an admin notice asks whether This site moved to a new address or This is a staging copy. Answer it first. A move updates the server’s record for your account, which usually clears the warning. See Update your app when your site URL changes.

4. Reopen the Publish Your App page

The comparison is cached for up to a day for each site URL. A new URL is checked right away. If you answered the notice and the warning is still there, it will refresh within a day, or support can confirm the record sooner.

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. A wrong value risks publishing under another customer’s app account, or losing your own purchases.
• 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 page only reports

The account code ties your site to your subscription, your plugin entitlements, and the App Store and Play Console accounts your builds go to. The server’s record for a URL can be wrong after a move, for example a stray account created for the new address. So the page shows the mismatch and leaves the fix to the address-changed notice or to support.

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.