Google Play Console identity verification failed: 7 checks

If your Google Play Console identity verification failed, the cause is almost always one of a short list that Google publishes: a document type it does not accept for your country, a name or address that does not match your payments profile exactly, an image it cannot read, or a mismatch between the account type you registered and the payment profile behind it. You get a limited number of attempts, so the useful move is to diagnose the exact reason from the rejection notice before you resubmit anything.

This is the account level check, not the device check and not package name registration. It gates publishing, which means it also gates the 12-tester, 14-day closed test that has to finish before you can apply for production access.

What follows is the order we would work through it in, then what a pending or failed verification does to a test that is already running.

What Google counts as identity verification

Google requires verification when you set up a Play Console developer account. A personal account needs an official government identity document. An organization account needs a D-U-N-S number, an official organization document, and a government ID belonging to the authorized representative. The check is run against the Google Payments profile linked to your developer account, which is why so many failures are data mismatches rather than bad documents.

For personal accounts, the legal name and address are taken from that payments profile. For organizations, they must agree with both the payments profile and the Dun and Bradstreet record behind your D-U-N-S number. Google describes the purpose as confirming who the developer is, not reviewing the app.

Three unrelated gates get mixed into the same conversation, and conflating them wastes attempts. Device verification and closed testing are separate requirements, and the device check is the one you complete in the Play Console mobile app. Package name registration is the other half of Android developer verification and is a per-package task. Phone and website verification sit downstream of identity verification: Google states that phone number verification cannot proceed until identity verification, website verification (for organizations) and device verification (for individuals) are done.

What a failed verification blocks

Google is specific about the scope of the block. Its help page says: "During the identity verification process, you can still access many features on the Play Console that will help you get your app ready to publish. However, you will not be able to publish an app until your identity is verified."

That sentence sets the timing for everything downstream. A closed test needs a released build on the closed testing track. The 14 days are counted from the point testers are opted in to that release. No publish, no release, no opt-ins, no clock. Google's own wording for the testing requirement is that at least 12 testers must be opted in to your closed test when you apply for production access, and must have been opted in continuously for the preceding 14 days.

The gate reaches your team as well. Google's FAQ says a user with permission to manage production releases "will be unable to publish a release until the account owner's identity has been verified". Only the account owner can clear it, so a contractor or co-founder cannot fix this on your behalf.

There is a quieter consequence too. Since 30 September 2026 every Play package must be registered for Android developer verification, and Google's registration guide warns: "You will only receive notifications about the registration status of your apps if you have completed identity verification in Play Console." An unverified account can miss the warnings that come before an app is removed.

Identity verification failures, in the order to check them

Start with the notice itself, not with another upload. Google lists the failure categories on its help page, and each one points at a different fix. The rejection email goes to the account owner, and the app list page carries a banner with a Verify ID action you can resubmit from.

1. Match the notice to one of Google's listed categories

Google's failure list covers unsupported document type, name mismatch on an ID, organization name mismatch, one side of a two sided document, account type mismatch, black and white images, and images that are blurry, cropped or unreadable. A second list covers individual IDs: a document issued in a different country from the payments profile, an expired document, photocopies or screenshots, and glare or a finger covering the data.

If the email names one of those, you already know which of the following checks applies. If it only says Google could not verify your identity, work down the list in order, because the data mismatch cases are the ones people miss.

2. Confirm the document is one Google accepts for your country

Accepted documents differ by country and by account type, and Google names the dominant cause of failure directly: "Submitting unsupported documents is the primary reason for developer verification failures, and providing modified or fake documents can lead to the immediate removal of your account and apps."

Open the accepted documents list for the country in your payments profile, which is not always the country you live in, and check the exact document names. A national ID card that is accepted for your neighbor may not be on the list for your profile country.

3. Check the name against the payments profile, character by character

Google fails the check when the name entered in the form does not match the name on the government ID exactly. The practical suspects are middle names present on one document and absent from the other, initials instead of full names, transliteration between scripts, and a name that changed after marriage while the payments profile kept the old one.

Fix the mismatch at the source rather than at the upload screen. Google says that where documents and payments profile disagree, you can update the payments profile information during the verification task. Uploading a different ID against a profile that holds the wrong name just burns attempts.

4. Judge the image the way a reviewer would

Google's photo guidance: the document must be valid, in colour, clear, well lit, not a photocopy, not a screenshot, and captured in full so that all four corners are inside the frame. Its failure list adds glare, flash reflection, a thumb over a field, and a document photographed on only one side when both sides carry data.

In practice that means a flat surface, daylight or diffuse light, no flash, the whole document in frame, and both sides photographed if the reverse carries information. Cropping to make the text larger is a common self-inflicted rejection.

5. Check the issuing country and the expiry date

Two entries on Google's individual ID list catch people who assume the upload quality is the problem: a document issued by a country different from the payments profile country, and an expired document. Neither is fixable by retaking the photo.

If the payments profile country is wrong, correcting it is not an edit inside Play Console. Google documents a change of country as a new developer account with an app transfer, so it is worth confirming the profile country before you choose which document to submit.

6. Confirm you registered the account type you actually have

Google's list includes the case where the payments profile is set to Organization but the developer account looks like an individual, or the reverse. This surfaces most often with sole traders who selected organization and then could not produce organization documents, or with a personal payments profile attached to an organization account.

If the organization route is not viable, Google's guidance for sole proprietors is to register as an individual rather than force documents that will not pass. The difference between personal and organization accounts matters here beyond the verification step, because it also changes what Google displays publicly.

7. For organizations, treat the D-U-N-S record as the identity

Four values have to agree: the D-U-N-S number, the legal name, the address, and the payments profile. Google publishes the exact error developers hit when they do not: "We couldn't match the D-U-N-S number and the address that you provided. Double-check your D-U-N-S number and the address that you registered with Dun & Bradstreet, then try again."

Organization details are not edited in Play Console. They are updated at Dun and Bradstreet first, and Google notes that corrections can take up to five business days to propagate after Dun and Bradstreet finishes processing. Retrying the same number inside that window produces the same error.

When the attempts run out

Google states that you are allowed a limited number of verification attempts and does not publish the number. Once the resubmission banner stops offering another try, the remaining route is support: the help page links a contact form for identity verification, and the account information page links a verification issues form for organization and D-U-N-S problems.

Two things are worth knowing before you spend an attempt. Submitting altered documents is treated as fraud and can remove the account immediately, so never edit a scan to tidy it up. And if verification ultimately fails, the $25 registration fee is not automatically lost: Google's FAQ says you can request a full refund for the sign-up fee and that requests are reviewed before approval.

Google also gives a rough turnaround, which most guides skip: "Identity verification may take approximately 3 business days." Do not judge a submission at the 12 hour mark and resubmit into a queue that is already processing.

If you do have to escalate, a specific request moves faster than a general appeal: the developer account email, the exact wording of the rejection, the date of your last submission, the document type and issuing country you sent, and one line on what has changed since. Reviewers are matching your file against a queue, and a request that names the failing category is easier to act on. That is our recommendation from the cases we see, not a documented Google requirement.

What a pending verification does to a running 14-day test

There are two situations here, and only one of them is documented.

If verification is failing before you publish, the clock has not started and no days are lost. You can keep building, finishing the store listing and lining up testers, but nobody can install from a track that has no live release. Testers seeing the app as unavailable is the symptom you will hear about, and the cause is upstream of the test.

If the account falls back into verification while an app is already live, the exposure is larger. Google states that where it cannot verify identity details or contact information, "your developer presence and apps may be removed from Google Play", and that you cannot republish until you have re-verified. Re-verification is triggered by legal name or address changes, and for organizations by an updated Dun and Bradstreet profile. Google does not publish whether the 14 days keep accruing while the app is unavailable, so treat a live test as at risk and do not change legal account details mid-window unless you have to.

From our own campaign records across 1,500+ closed-testing campaigns, the account level task that most often costs a day is not the test itself but an open verification or contact detail task found at hand-off, which is why we check it before a start date is agreed. That is a pattern from our onboarding work, not a measured rate, and it does not identify identity verification specifically.

The order that keeps the clock clean

None of this is complicated once it is sequenced, and the sequence is the part that gets skipped:

1. Complete identity verification at account setup, before you need it. It takes minutes to submit and around 3 business days to review.
2. Clear the contact verifications that depend on it, since phone verification cannot start until identity, website and device verification are done.
3. Complete device verification in the Play Console mobile app if you have a new personal account.
4. Confirm your package names are registered for Android developer verification.
5. Publish the closed testing release, then recruit testers. Opt-ins before a live release do not count for anything.
6. Hold 12 opted-in testers for 14 continuous days, then apply for production access.

If you are still choosing how to fill the tester slot, the current 12-tester requirement is the reference to work from rather than older guides that still say 20.

The arithmetic is the argument for doing all of this early. Three business days of review, then 14 continuous days of opted-in testers, then the production access review: even a clean run is about three weeks from first submission to a decision. A verification rejection discovered in launch week moves that date by days, not hours, and it moves it in the direction nobody plans for.

Frequently asked questions

Can I start my closed test while identity verification is pending?

No. Google states you cannot publish an app until your identity is verified, and a closed test needs a published release on the closed testing track. You can prepare the app, the listing and your tester list, but the 14 days only begin when testers can actually opt in.

Does a failed identity verification reset my 14 days?

If the failure happens before publishing, there is nothing to reset because the clock never started. If it happens while a test is running and the app is removed, Google does not publish whether those days still count, so plan on the basis that the window is compromised rather than assuming it survives.

Can someone else on my team complete the verification?

No. Google's FAQ says team members with production release permissions still cannot publish until the account owner's identity is verified. The account owner has to submit the documents.

How long does identity verification take?

Google says approximately 3 business days. Resubmitting during that window does not speed it up, and each submission consumes one of a limited number of attempts.

Why was my passport rejected when it is clearly valid?

The most common reasons are not about validity: the name on it does not exactly match the payments profile, the document was issued in a country different from the profile country, or the image was a photocopy, a screenshot, cropped or lit by flash. Check those before assuming the document type is the problem.

Do I need a D-U-N-S number for a personal account?

No. A D-U-N-S number is required for organization accounts, unless the account belongs to a known government organization or agency. Obtaining one through Dun and Bradstreet is free, and Google warns about third parties charging for it.

Can I get the $25 fee back if verification fails?

Google's FAQ says you can request a full refund of the registration fee from support, and that requests are reviewed before approval. It is not automatic.

Sources

Every Google statement quoted above was read from the page listed below on 1 November 2026, and quoted as published. Where a claim is our reading of a policy rather than the policy text, the article says so at that point.

• Play Console Help: Verify your identity (failure reasons, attempt limits, publishing block, team permission limit, 3 business day estimate, refund FAQ).
• Play Console Help: Verify your developer identity information (required documents by account type, payments profile dependency, phone verification prerequisites).
• Play Console Help: Required documents by country and region (accepted document lists, name and address matching, image rules).
• Play Console Help: Keeping your developer account information up to date (D-U-N-S mismatch error, re-verification triggers, removal consequence).
• Play Console Help: Registering Play package names (30 September 2026 registration deadline, notification dependency on identity verification).
• Play Console Help: App testing requirements for new personal developer accounts (12 testers, 14 continuous days, production access application).
• Android Developers: Register on Google Play Console (identity verification and package name registration for Android developer verification).