Google Play Billing Library v9: the small API changes, and the bigger Play discovery shift

Original article (source): RevenueCat - “Google I/O 2026: What’s New in Google Play and Play Billing Library 9.0” (May 19, 2026)

• https://www.revenuecat.com/blog/engineering/play-billing-v9/

The headline

Billing v9 is a lighter lift than v8, but it lands inside a Play ecosystem that is getting more AI-shaped, more conversational, and more churn-aware.

RevenueCat’s post is useful because it separates:

1. the code-level Billing Library v9 changes, and
2. the product-side Play changes (discovery surfaces, Play Console automation, and churn-reduction mechanics).

What changed in Play Billing Library 9.0 (code surface)

RevenueCat calls out a handful of practical updates (not a full rewrite like v8):

• In-app messaging for opt-in price increases (new user communication surface).
• Blocked Play Store now returns BILLING_UNAVAILABLE (less ambiguous failure handling).
• getLinkUri becomes @Nullable (edge case handling that will crash you if you assume it always exists).
• Target SDK 35 expectations are part of the same window, so this is not just “billing work”.

The bigger story: discovery and store UX are moving into Gemini

The post highlights several Play shifts that have App Store Marketing implications even if you never touch billing code:

• Ask Play (Gemini-backed conversational overlay) means listing copy, screenshots, and reviews are increasingly “inputs” to an answer, not just keywords for search.
• Play Shorts introduces short-form video into the store browsing experience.
• Engage SDK surfaces are expanding, which pushes discovery toward deep links and content-level entry points (not just installs landing on your home tab).

Why this matters

Two practical implications for teams:

• Churn work is getting platform help, but only if your product and instrumentation can tell “involuntary churn” from “user chose to cancel”.
• Your store listing is becoming a model-readable artifact. If your screenshot #1 and opening lines of description do not clearly state the use case, you risk being mis-categorised by conversational discovery.

Tiny win

Do one quick “billing + discovery readiness” check this week:

1. Add a guardrail to log when billing returns BILLING_UNAVAILABLE (so support can diagnose blocked-store scenarios fast).
2. Review screenshot #1 and the first 2 lines of your Play description: do they answer “who is this for, and what problem does it solve” in plain language?

Read the original: https://www.revenuecat.com/blog/engineering/play-billing-v9/