It’s not just about reaching the $10 threshold. That’s outdated advice and oversimplified. Google may request identity verification under a few conditions:
You reach the payment threshold and haven’t verified previously
You change your payee name or address
You’re flagged by some back-end trust scoring trigger (I suspect IP geo drift or cookies mismatch across devices)
Programmatic behavior from mobile or multiple logins via VPNs
For example, I once got the ID verification prompt on a brand-new account before it earned a cent — just because I tried to verify a UBO (ultimate beneficial owner) using an email alias tied to a G Suite domain that had contradicting address info from a previous Google Ads entity. That mess took 11 support pings to straighten out.
It’s pretty clear that behind the pretty UX prompt sits a weighted queue of risk signals and account history pipelines. If anything seems off — old payment profiles, mismatched IPs, or re-used legal entity names — the docs prompt gets triggered to “establish country of residence.” Which sounds simple but can turn Kafkaesque real fast.
The Acceptable Document Types Nobody Tells You About
The public list says things like government-issued ID, passport, driver’s license. But they’re a little looser than they admit — if you hit the right document format.
You can actually get verification through some of the following:
Digitally issued EU national ID cards (PDF printout accepted)
Japanese residence cards if you include both the front and back — they won’t say this but will reject silently without the back
Swiss health insurance cards if they double as ID (but only in French or German)
Once I submitted a US green card scan — same file I’d used for opening a bank account — and got rejected for “document unreadable.” Resubmitted the same scan with a minor brightness increase and no filename spaces and it passed. I am not kidding.
So yes, filename parsing and basic image preprocessing seem to matter. No official word on this from Google, but after testing with intentionally malformed TIFFs and rotated JPEGs, they will reject anything below 300 DPI, with slight tolerance if EXIF metadata say it came from a mobile camera.
Where It Breaks: The Phone Capture Trap
If you’re taking a photo of your ID with your phone and uploading it from your phone browser (especially anything Chrome-based), weird compression kicks in. I’ve confirmed this tweaking the capture pipeline on Android — on some devices, Google Photos auto-compresses the upload if it thinks it’s duplicative.
You think you’re uploading a sharp photo, but the actual blob Google gets is an overcompressed artifacted mess. The kicker: their UI won’t warn you. It’ll just float in pending for a few hours then reject.
Better route: upload the document from a computer, preferably via Chrome desktop or Firefox. If you must use mobile, convert the image to PDF using an app like Adobe Scan or Dropbox Scan before uploading. Images wrapped in PDFs pass more consistently, presumably because the parsing system handles PDFs differently (guessing it’s passed to a separate OCR queue or a more lenient parser).
Browser Detection and Upload Failures with Script Blockers
Don’t assume “upload failed” means your image was wrong. I’ve had uploads silently fail because of uBlock Origin, Ghostery, and even DuckDuckGo’s privacy extension. They block something called gstatic.com/upload/identity — no clear error, just infinite spinner or “upload pending.”
The uploader needs third-party JS to validate the content before passing it to the next pipeline. If that fails client-side validation, you won’t even reach the server. Disable extensions temporarily or run the session from a clean Chrome profile.
Edge case: Firefox in strict privacy mode can sometimes throw Credential Management API warnings. Ignore these — but they do prevent autofill of address info, which indirectly breaks form submission on the next page.
Honestly, I now keep a clean profile just for this crap. No extensions, no saved logins, and session cookies cleared before and after anything AdSense-related. Saved me hours.
How Long It Actually Takes — And What That Means
Here’s the reality: you’ll hear “24-48 hours” everywhere. In practice, approval times are bimodal. Either:
You’re in the fast queue (under 6 hours)
Or you fall into a manual review bucket (anywhere from 3 to 20 business days)
There doesn’t appear to be a clear skip-the-line method, but certain factors seem to influence path:
Uploading a PDF instead of JPG seems to get routed faster
Submitting between 3–6am UTC hits less global load (completely anecdotal but it’s worked three times for me now)
One thing that tripped me up — if you reupload during pending, it resets the internal queue counter. It doesn’t add a second document; it just nukes your first submission and starts over. No warning or flag. I only learned this by digging into old HAR logs and seeing the payload pattern change completely with each reupload.
Account Lockout if You Miss the Window
You typically get 30 days to submit ID after the prompt. After that, your account doesn’t close — but ad serving is disabled. This creates a super awkward state:
What’s bananas is that once this happens, document upload sometimes becomes disabled. The upload form 404s or shows “unavailable.” If you see that, you must ask support for a manual recovery flow. Yes, even if you never got to submit ID at all.
Worst case I saw: ID request came during a late-December holiday week, and they froze out before the user even saw the email. By the time they logged back in mid-Jan, the link was dead and the dashboard was partially disabled. Took manual escalation via a YouTube Partner support route to reopen the upload window.
Tip: if you have users under a shared domain (edu or G Suite), warn them that identity requests can go to alternative inboxes. Google’s delivery logic occasionally sends ID request emails to secondary Google account addresses, not the primary login email — this behavior is not documented anywhere.
Verification After Changing Payment Country
This is where things get spicy. If you change your payment country — say, from Germany to Portugal — Google requires you to close the current profile and make a new one. Fine, until you realize ID can no longer be resubmitted the same way.
Your old ID, even if valid, is not transferrable. The new country profile requires documentation compliant with that jurisdiction. So no, your German eID won’t pass for Portugal, even if everything else matches.
Worse, the account often inherits ghosted metadata. There’s a race condition (someone at r/AdSense confirmed this too) where your closed Germany profile leaves a payment channel that’s still linked to your AdMob or YouTube property IDs. This leads to ID check requests before monetization eligibility, even when the UI shows no earnings yet.
“Aha” moment: tracking a payment profile ID leak in the JS payload from the Publisher Console. It showed the deactivated country code still associated silently in a hidden field. So submitting an ID from the new country would fail — because the backend was asking for the old jurisdiction logic. No way to edit this. Required a full profile purge via support.
How Support Treats Rejected Identity Docs
Pro tip: they won’t tell you what field failed. You’ll get a generic rejection message like “document unreadable” or “does not meet criteria.” No hint if it’s the name mismatch, translation, blur, or wrong document type.
However, through trial/error submissions and one gloriously honest support agent in the Dublin tier-2 queue (my respect to Imelda), I got something useful: Google system parses your “legal name” from the document using OCR + localized character sets. If your dash, accent mark, or special suffix (Jr., Sr., etc.) doesn’t align with the account name exactly, it’ll flag.
I’d included my middle name on the uploaded doc — but hadn’t registered with it in AdSense. Auto-reject. No UI prompt. No resolution from first-line support until I manually changed the account holder name.
Another sloppy bug: if the OCR fails to detect the document type (e.g. if the heading is obscured), the system defaults to “unsupported document.” Seen this happen with passports under plastic sleeves or with bank statement scans that are actually OK but got filed under the wrong type internally.
