Skip to main content
Question

Intermittent UNEXPECTED_ENVIRONMENT and low scores on React Native app (iOS & Android) despite matching identifiers

  • April 19, 2026
  • 0 replies
  • 11 views

Newroz Holdings

 

Overview:
We are experiencing a high volume of UNEXPECTED_ENVIRONMENT reason codes in our reCAPTCHA Enterprise assessment logs. We are looking for assistance in diagnosing the root cause of this issue, as it is happening intermittently on the same exact app builds across both iOS and Android platforms.

Environment Context:

  • Framework: React Native

  • reCAPTCHA Integration: Using the native Google reCAPTCHA Enterprise SDKs for both iOS and Android.

The Issue:
For example, this week we processed roughly 10,000 reCAPTCHA requests. About 7,000 of them were successful with high scores, but approximately 3,000 of them returned a low score (below 0.5) with the UNEXPECTED_ENVIRONMENT reason code. This ratio is happening across both our iOS and Android traffic.

Our Troubleshooting & Observations:
What makes this confusing is that our console configuration, Site Keys, and app builds are identical for both the successful and failing requests.

  1. Identifiers match perfectly: We have verified that the iosBundleId (for iOS requests) and androidPackageName (for Android requests) in the failed logs exactly match the restricted package names we registered in the Google Cloud reCAPTCHA console.

  2. Tokens are valid: Across all our logs (both high and low scores), the tokens are marked as valid: true.

Here is an example snippet of the tokenProperties from a failing iOS assessment response (our Android failing logs look identical, but with the androidPackageName field):

code JSON

"tokenProperties": {
"action": "registration",
"createTime": "2026-04-19T07:32:50.083Z",
"iosBundleId": "******",
"valid": true
}

Questions for the Support/Community Team:

  1. Since the configuration is correct, the native SDKs are being used, and it works for 70% of our traffic, why would the exact same application builds trigger UNEXPECTED_ENVIRONMENT for the other 30%?

  2. Does this specific reason code trigger if a user is on a jailbroken/rooted device, using a mobile emulator, or running the app on a desktop (like an M1/M2 Mac or Windows Subsystem for Android)?

  3. Are there specific device attestation failures (e.g., Apple DeviceCheck/App Attest on iOS, or Play Integrity API on Android) or network conditions that cause a natively generated token to fall back to being flagged as an "unexpected environment"?