If your Android app takes payments, it needs to be on Google Play Billing Library 8.0.0 or later, and the deadline for that was 31 August 2026. The warning email Google sends about it quotes 1 November 2026. I've seen enough confusion about this in the last fortnight to think it's worth spelling out: both dates are real, and the difference between them is an extension you have to go into Play Console and request.
The published schedule is unambiguous. Version 7 stopped being accepted for new apps and updates on 31 August 2026. The 1 November date is a backstop, available through the Policy status page, and you get it by opening the warning and completing a form. Nobody grants it automatically. If you read the email, noted the November date and closed the tab, your deadline is not in eight weeks. It went on 31 August.
What you actually lose
Nothing visible, which is what makes this easy to defer.
Your app carries on working. Existing installs are untouched, purchases keep processing, and revenue keeps arriving. What you lose is the ability to publish. Google rejects releases from apps on a deprecated billing library, so no security patch, no crash fix, no price change, and no target API level bump goes out until it's resolved.
That's a bad thing to discover in the same quarter that Android's other deadlines land. Target API level enforcement and the new developer verification requirement both need you to be able to ship an update. A team that's locked out of publishing for two weeks in October has a scheduling problem. A team that's locked out in the week a security researcher emails them has an incident.
The change that compiles cleanly and still costs you money
Version 8, released on 30 June 2025, is where Google removed a set of long-deprecated APIs. Most of that list behaves the way you'd want: the compiler complains, someone fixes it, the build goes green.
One doesn't, and it's the one I'd check first.
enablePendingPurchases() used to take no arguments. In version 8 it takes a params object, and the fastest way to get a green build is to hand it an empty one. Do that and you've quietly switched off support for pending one-time purchases, because you have to enable them explicitly.
Pending purchases are how Google Play handles payment methods that don't settle immediately: convenience store cash in Japan, bank transfers in Germany, boleto in Brazil, OXXO in Mexico. In those markets a real slice of paying users never touch a card. Turn the support off and those transactions initiate and never complete. Unit tests pass. Your own device testing passes, unless you happen to be testing a delayed payment method. It surfaces weeks later as a regional revenue dip that nobody can attribute to a release.
The other significant removal is queryPurchaseHistoryAsync(), which is gone with no client-side replacement at all. Restoring purchases and checking free trial eligibility can no longer be answered on the device. Both move to your own entitlement records and the Play Developer API. If your app has no server-side record of what a user has bought, this is where a one-day version bump becomes a three-week piece of work, and it's the single most common reason I've seen this migration overrun.
What this means if you're not writing native Android
Most product teams in this region aren't calling BillingClient directly. You still ship it, and Play still reads the version out of your bundle, so the version you need is whatever your plugin bundles.
Flutter teams on the official in_app_purchase plugin want 3.3.0 or later, which pulls in Billing Library 8.0.0. Unity teams need Unity IAP 5.0.0, released in August 2025. On Capacitor or Cordova, cordova-plugin-purchase 13.13.1 or later, with 13.15 adding native Capacitor bridges. RevenueCat covers it from Android SDK 9.0.0, with matching 9.0.0 releases for Flutter and React Native. Qonversion shipped Billing Library 8 support on its native Android SDK first, so check your wrapper's version rather than assuming it's arrived.
React Native is the awkward one. react-native-iap was the default choice for years, and it was archived on 4 August 2026, three weeks before the deadline. If that's your billing layer, you're not bumping a version, you're replacing your in-app purchase implementation while the clock runs. expo-iap is where most teams are heading, and it works in bare React Native rather than only in Expo. Budget a fortnight, not an afternoon: it touches your purchase flow, your restore flow and your receipt validation, and none of it can be verified in an emulator.
Go to 9, not 8
Google's recommendation is version 9 and it's worth taking. All the breaking changes are in version 8. Version 9.0.0, released in May 2026, removed no APIs at all: a nullable return value, an error code reclassification, and some new in-app messaging.
Landing on 8 keeps you compliant until 31 August 2027. Landing on 9 keeps you compliant until 31 August 2028 and costs you an afternoon more. Google has run this two-year cycle since announcing it at I/O 2019 and has never let a date slip, so you're choosing between doing this again next summer or doing it in 2028.
What usually makes this expensive
On the migrations we've taken on, the code change has rarely been the costly part.
The fortnight goes on establishing who holds the Play Console account, whether the original upload key still exists, and whether anyone left in the building can sign a release. Every deadline Google sets tests that quietly, and this one arrives with a hard stop attached.
If you're not sure of the answer for one of your own apps, that's worth resolving in September rather than in the last week of October, alongside everyone else who left it.
If you'd rather hand the migration over, that's the kind of work our App Support and Maintenance service covers: store compliance deadlines are core scope, and it usually starts with a code review to size the job before anyone commits to a number.
We've written the full version, with the per-framework version list and what the two removed APIs mean for restores and trial eligibility: Google Play Billing Library 8: The Deadline Google Gave You Two Dates For.
Foresight Mobile is a Manchester-based mobile app development and maintenance company. We take on migrations like this one for teams who no longer have an Android developer to hand, usually starting with a code review to establish what's actually involved. If that's useful, get in touch.
