The Opening Comes With a Perimeter

The Epic remedy becomes a real operating choice only after a developer passes through several states: eligibility, enrollment, integration, user-facing operation, and accountability. This chapter traces that lifecycle for Google’s current US programs and then places it on the 2025–2026 legal and policy timeline. The result is a practical boundary: a route may be legally permitted and still require program approval, user protection, reporting, fees, and a fresh check when the underlying injunction changes.

Eligibility is the first boundary

Google’s alternative-billing and external-content-links pages describe programs for eligible apps or games serving users in the United States. The alternative-billing page specifies mobile and tablet form factors and digital content or services. The external-links page likewise describes mobile or tablet apps and games serving users in the United States and its territories. These limits are not decorative. They define the population for which the current program descriptions answer the question “what may a developer do?”

A developer outside that scope cannot safely infer that the same route is available simply because the injunction was nationwide as described by the Ninth Circuit. The court’s order and Google’s implementation pages operate at different levels. The opinion describes the legal remedy; the help pages describe the routes Google currently offers under that remedy. A page that explains US users on mobile or tablet form factors does not establish a worldwide entitlement or a rule for every Android device.

The programs are also optional. A developer that does not want to offer an alternative to Play Billing or link users to external content can take no action. That choice preserves the existing Play-only path, but it does not provide the additional payment or destination choice that the injunction is meant to protect. Eligibility is therefore not a command to change. It is the first gate for deciding whether a change can be attempted under the described programs.

Enrollment turns permission into operation

The next state is enrollment. For alternative billing, Google directs a developer to complete the required onboarding in Play Console, integrate the alternative-billing APIs, and manage settings for the participating apps. For external content links, Google requires enrollment and approval, API integration, and—when a link leads to an external app—registration and declaration of the linked apps and the landing and download URLs.

This difference reflects the different risks of the routes. Alternative billing introduces another payment system inside an app. External links can take a user to a website, webview, another app, or another store, and can lead to an app whose installation and updates are not managed by Google Play. The latter route therefore requires Google to know more about the destination and, for downloads, the external app being offered.

Enrollment is not merely paperwork. It assigns responsibility before a user relies on the new route. An alternative-billing participant must comply with applicable payment and child-protection laws. If they handle credit or debit card information, they must meet the Payment Card Industry Data Security Standard.