Checked against Google Play Help Center and Android Developers documentation. Google changes verification requirements and document lists by region, so confirm the current wording in your own Play Console before you resubmit anything.
Identity verification failures on Google Play rarely arrive with a useful explanation. The task stays open or comes back rejected, and the message is generic. In practice, most failures come down to a disagreement between three records Google compares automatically: the document you uploaded, the Google Payments profile linked to your developer account, and your Play Console profile.
This guide covers the Play Console account verification task — the one that checks who the developer is. It is not Android developer verification and app registration, which is a separate system with its own scope; the comparison of those two systems explains the difference.
Quick answer: fix the data, then resubmit
The short version
- Check which task is actually open. Identity, website, device, and phone verification are separate tasks, and phone verification is blocked until the others are done.
- Compare every field in your document, your payments profile, and your Play Console profile: legal name, address, organization name, D-U-N-S.
- Match the document type to your region. Google publishes an accepted-documents list per country and account type.
- Fix quality problems: expired ID, photocopy, black-and-white scan of a colour document, glare, cropped edges.
- Correct the profile first, resubmit second. Uploading the same document again rarely changes the outcome.
- No document, D-U-N-S number, or support request guarantees approval. Google does not publish review timelines.
Which verification is failing?
Two similarly named systems cause a lot of confusion, and the first troubleshooting step is deciding which one you are in. A Play Console identity task and an Android developer verification notice look alike in a support forum and are handled in different places.
| Play Console account identity verification | Android developer verification | |
|---|---|---|
| What it checks | That the person or organization behind the account is real, using identity documents and a linked payments profile. | That a developer entity is registered so its apps can be installed on certified Android devices beyond Google Play. |
| Where you complete it | In Play Console, on the verification tasks on your home page and developer account settings. | Through Play Console for Play apps, or the Android Developer Console for apps distributed elsewhere. |
| Who needs it | All Play Console developer accounts; organization accounts add document and D-U-N-S requirements. | Developers distributing through participating stores in the countries Google has listed, with wider expansion planned. |
| What failure looks like | A rejected document, an unresolved mismatch, a blocked publishing flow, or a task that stays pending. | An app that cannot be installed where registration is required, or an unregistered package warning. |
Scope matters here: Google has described Android developer verification as starting with specific countries — Brazil, Indonesia, Singapore, and Thailand — across a named group of stores, with wider rollout planned. It is not a worldwide switch, and it does not replace the Play Console identity task.
Where Play Console shows what is actually pending
Google's guidance is to check your Play Console home page for pending verifications. That page matters because the tasks are ordered: phone number verification cannot proceed until identity verification, website verification (organization accounts), and device verification (individual accounts) are complete.
Work down that list rather than around it. Developers who resubmit an identity document five times while the real blocker is an unverified organization website are solving the wrong problem. If a task shows as pending rather than rejected, there may be nothing to fix yet.
The five mismatch patterns behind most failures
Google's document guidance states that submitted documents must match the information in your payments profile exactly, and that submitting unsupported documents is the primary reason developer verification fails. That single sentence explains most of what follows.
Name and address drift
For personal accounts, your legal name and address come from the Google Payments profile linked to the developer account. If you moved, changed your surname, or the profile was set up with an abbreviated address years ago, the document and the profile will disagree. Fix the profile during the verification task rather than uploading a document that contradicts it.
D-U-N-S disagreements
Organization accounts take the organization name and address from the payments profile, and the D-U-N-S number must match the record at Dun & Bradstreet. Enter the number exactly as shown there. A common trap is a large group holding several D-U-N-S numbers for different legal entities: the one you choose must describe the entity you are verifying.
The wrong document for your region
Accepted documents depend on the country in your payments profile and on account type. An organization must supply two document types — an organization registration document and a government-issued photo ID for an authorized representative — and that representative need not be the public account owner. Some countries require additional or notarized paperwork. Start from Google's accepted-documents list for your location, not from what you happen to have scanned.
Quality problems that read as rejections
An ID must be valid, not expired, captured in colour, clear and well lit, and not a photocopy. Black-and-white documents are accepted only where the issuer originally issued them that way. Watermarks, glare, cropped corners, and screenshots of a PDF all give the check a reason to refuse. European and UK requirements add a constraint: ID data cannot be blocked or redacted, because of anti-money-laundering rules that apply to the payments provider.
The wrong account type, or the wrong owner
If the account was created as an organization but the business does not exist as a legal entity, no organization document will ever satisfy the check — and the reverse is also true. Google also states that account ownership cannot be transferred and that a new account must be created if the wrong owner was verified. That is a structural problem, not a document problem, and it is worth diagnosing before another week of scanning paperwork.
Troubleshooting table
“Likely cause” is a hypothesis to verify against your own account, not a diagnosis. Confirm the values in your payments profile before you change anything.
| Symptom | Likely cause | Safe next step |
|---|---|---|
| Identity document rejected with no reason | Document type not accepted for your region, or a quality problem. | Re-check the accepted-documents list for your country and account type, then re-capture rather than re-upload the same file. |
| Name on the document does not match | Payments profile holds an older or abbreviated legal name. | Update the payments profile fields during the verification task, then resubmit. |
| D-U-N-S number “not found” | Typo, wrong entity, or a recent D&B change not yet propagated. | Copy the number exactly from the D&B record; allow for propagation if you just corrected it. |
| Organization address mismatch | D&B record, payments profile, and document show different addresses. | Correct the address at the source, request the D&B update, and retry once it propagates. |
| Phone verification unavailable | Identity, website, or device verification is still open. | Finish the earlier tasks; the phone step unlocks after them. |
| No verification code by SMS | Carrier delivery issues or a landline number. | Switch to the voice-call option, check the number is in international format, or try another supported number. |
| Task stuck pending for a long time | Review in progress, or an unresolved prerequisite. | Check the home page for other open tasks before resubmitting anything. |
| Apps or developer profile at risk of removal | Google says it cannot verify developer or contact information. | Complete verification, and use the official verification issues form if you are blocked. |
D-U-N-S problems: what actually goes wrong
A D-U-N-S number is a nine-digit identifier issued by Dun & Bradstreet. Applying is free, and Google explicitly warns about third-party services that charge administrative fees for the same registration. If your organization does not have one, Google notes the process can take up to 30 days — long enough to delay a launch — so check whether your organization already has one before applying.
Three failure modes dominate. First, a correct number paired with an outdated address: if you changed the address in Play Console just before seeing the error, the change must reach Dun & Bradstreet, and Google says the update can take up to five business days from the end of D&B's processing before you retry. Second, the wrong entity: a group with several legal entities may hold several numbers. Third, a genuine absence: Google supports alternative verification for regions Dun & Bradstreet does not cover, and known government organizations can verify without a number — but only through the official support route.
Two smaller points save time. Multiple developer accounts can use the same D-U-N-S number, and your public developer name does not have to match the organization's legal name.
Document preparation checklist
- ☐ Confirm your account type: personal or organization. The document list depends on it.
- ☐ Note the country in your payments profile; that is the region your documents are judged against.
- ☐ Copy the legal name and address exactly as stored in the payments profile.
- ☐ Check the D-U-N-S record matches the organization name, address, and entity you intend to verify.
- ☐ Verify each document is unexpired, in colour, fully in frame, and legible.
- ☐ Confirm the address document shows the same name and address as the profile.
- ☐ For organizations, prepare a registration document plus the representative's photo ID.
- ☐ Record what you submitted and when, so a retry is not a guess.
What not to do
Google states that modified or fake documents can lead to immediate removal of the account and apps. Avoid edited scans, documents belonging to someone else, or a second account created to route around a rejected verification — ownership cannot simply be reassigned later.
Avoid the quieter mistakes too: reusing an unrelated payments profile when Play Console prompts you to create one, buying a “verification service” that promises approval, and resubmitting the identical file unchanged.
Correct, retry, or contact support
Use the following order, because each step depends on the one before it:
- Correct the data. Update payments profile fields during the verification task, and fix the source record at Dun & Bradstreet if the address or entity is wrong.
- Retry only after the change has landed. A resubmission during propagation produces the same error and wastes a review cycle.
- Use the official verification issues form when a mismatch cannot be resolved in Play Console. Include the account, the task, the exact error, and what you already changed.
- Ask for an exception only where Google documents one — unsupported D&B regions, or government organizations prompted for a number they do not have.
Be realistic about outcomes. Google does not publish verification review times, does not guarantee that a given document will be accepted, and does not treat a support ticket as an approval. A well-prepared submission shortens the loop; it does not remove the decision from Google.
Frequently asked questions
Why was my identity document rejected without an explanation?
Play Console often gives a generic message. The documented causes are an unsupported document type for your region or account type, and a quality problem such as expiry, a photocopy, or colour artwork supplied in black and white.
Do I need to update my payments profile or my Play Console profile?
For personal accounts, legal name and address come from the linked Google Payments profile, so that is the record to correct. Organization name, address, and D-U-N-S also come from it. Play Console holds your public developer name and contact details separately.
Can I use the same D-U-N-S number for two developer accounts?
Google's FAQ says yes. The number identifies the organization, not the individual account.
Is a D-U-N-S number required for every organization?
For standard organization accounts, yes — Google says you cannot create one without a number. Known government organizations can verify without it, and Google offers an alternative path only for regions Dun & Bradstreet does not cover.
My phone number verification is greyed out. Why?
Phone verification cannot proceed until identity verification, website verification (organizations), and device verification (individual accounts) are complete. Check the Play Console home page for the open task.
Can I transfer a verified account to someone else?
Google states that account ownership cannot be transferred. If the wrong person was verified, a new account must be created with the correct information. Moving apps is different, as the app transfer guide explains.
Does this affect closed testing and production access?
They are separate requirements. Google requires a verified account before you can submit apps, and verification does not satisfy the closed-testing rule or guarantee production access. The closed-testing checklist covers the testing side.
Official sources
- Google Play Help — Verify your developer identity — verification steps, payments profile linkage, task order, and contact verification.
- Google Play Help — Developer account information — personal versus organization fields, D-U-N-S, and linked payments profile.
- Google Play Help — Keep your developer account information up to date — FAQ on proof of address, D&B propagation, ownership, and exceptions.
- Google Play Help — Accepted identity documents — document types by region and account type, plus image requirements.
- Android Developers — Android developer verification — the separate registration system and distribution paths.
Treat verification as a data-matching problem
Most Play Console identity verification failures are not judgement calls about who you are. They are a document, a payments profile, and an account record that disagree on a name, an address, or a legal entity — or a document that is the wrong type or quality for the region. Fix the record that is out of date, resubmit once, and use the official form if the mismatch cannot be resolved from your side.
Once verification is behind you, the next gate is testing and access. If you need real testers for a closed test, 12 Testers Community provides that service. It does not replace account verification, and no testing service can guarantee production access.
