RevenueCat Said My Play Store Credentials Were Invalid. They Weren't.

I created a Google service account, uploaded the JSON key to RevenueCat, and watched my Android app reject every purchase. The dashboard said the credentials needed attention. On device, the logs showed a RevenueCat error: 7107 / Invalid Play Store credentials.

The credentials weren't invalid. I'd just made the mistake that costs a lot of mobile developers a full day: I expected Google to be fast.

Here are three Google Play Billing traps from one app launch. Two of them are Google being slow. The third costs money instead of time. All three look exactly like bugs in your code, and none of them are.

The setup

I'm building Origo, a subscription app on Expo and React Native. Payments run through RevenueCat, which validates every Google Play purchase server-side before it grants entitlements. That server-side check is the whole point. The client can't be trusted to claim "this user paid," so RevenueCat asks Google directly.

To ask Google, RevenueCat needs a service account with access to your Play Console. You create the service account in Google Cloud, generate a JSON key, grant it permissions in Play Console, and paste the key into RevenueCat. The official docs walk through it cleanly.

Then nothing works, and the docs don't warn you loudly enough about why.

Trap 1: "Invalid Play Store credentials" usually means "wait"

The first purchase test failed instantly. RevenueCat's dashboard showed a banner: Credentials need attention. On device, the SDK threw Invalid Play Store credentials. My first instinct was that I'd pasted the wrong key or missed a permission.

I hadn't. The key was correct and the permissions were correct. The problem was time.

When you create a fresh service account, Google has to propagate its access to the Play Developer API. RevenueCat's support docs put this at 24 to 48 hours. Until it finishes, every server-side validation returns an error that reads like a configuration mistake. So you "fix" a config that was never broken, re-upload the same key, and wait again.

The faster fix: you can force Google to re-evaluate the credentials instead of waiting on the background job.

1. Open Play Console and go to your app.
2. Go to Monetize → Products → Subscriptions (or In-app products).
3. Edit any product. Change the description. Save.

Saving a product change pokes the billing config and can validate the new credentials right away, per RevenueCat's own guidance. If you remember one thing from this post, remember that the credential error is a clock, not a bug. Editing a product can reset the clock.

Trap 2: new products return ITEM_UNAVAILABLE for hours

The second trap looks even more like a real defect. You create a subscription or a one-time product in Play Console, wire it into RevenueCat, run a purchase, and the SDK returns ITEM_UNAVAILABLE.

The product exists. You're staring at it in the console. It still says unavailable.

Same root cause: propagation. A product you created minutes ago hasn't reached the billing backend yet. One-time products in particular can take hours. I hit this with a lifetime product I'd created minutes before the test, started reading my purchase flow line by line, then realized the product was simply too new to buy.

The rule I follow now: if a product is less than a few hours old, ITEM_UNAVAILABLE isn't evidence of anything. Retest later before you touch your code. The most expensive debugging is debugging a system that simply isn't ready yet.

Trap 3: test with license testers, or you'll charge yourself

The first two were Google being slow. This one's different. It's the mistake that turns a test into a real transaction.

Google Play has no separate sandbox the way Apple does. A purchase on a live product charges a real card unless the buying account is registered as a license tester. So before any purchase test, I add our test Google account under Play Console → Settings → License testing. License testers get the full purchase flow, real dialogs, real RevenueCat validation, but no charge and no refund paperwork.

Skip this step and your "test" buys your own subscription with real money. Then you're filing a refund instead of reading logs.

The pattern underneath

The two delays share one shape. The symptom shows up at the boundary between your app and a platform you don't control, and that platform is eventually consistent. It says no now and yes in a few hours, with nothing in between that admits it's still thinking.

Your debugging instinct is to assume the last thing you changed is broken. With Google Play Billing, the last thing you changed is often correct and just not live yet. So I changed my checklist. Before I debug a billing error, I ask one question first: how old is the thing that's failing? If the answer is minutes or hours, I wait and retest before I read a single line of my own code.

That one question has saved me more time than any fix.

I'm writing up the real launch problems behind Origo as I hit them. If you're shipping subscriptions on React Native, these propagation traps are the ones I wish someone had warned me about on day one.