Google Play steering: who should AI app SMEs choose?

An €890 million Digital Markets Act fine does not turn a link out of Google Play into a free checkout. It turns steering into a product decision: the app must move a person from an in-app offer to a browser, take payment, restore the right account and prove what happened when any step fails.

On 23 July 2026, the European Commission announced two Google non-compliance decisions. It imposed €460 million for self-preferencing in Search and €430 million for restrictions that prevented app developers from directing customers to alternative purchase channels. The second decision is the relevant one for a small AI app deciding whether to sell a subscription on the web.

The Commission says developers should be able to inform customers, free of charge, about alternative offers and direct them to those offers. That is not the same as saying that the resulting transaction has no platform, payment, tax, support or engineering cost. The useful buying question is therefore not “which checkout is cheapest?” It is “which route can keep the customer, entitlement and evidence joined across the whole trip?”

Permission is not an operating model

Art. 5(4) of the DMA requires a gatekeeper to let business users communicate and promote offers to acquired end users and conclude contracts with them. Google Play’s current external-offers documentation adds the operational route for EEA apps.

That route is not a bare hyperlink. Google’s public requirements include programme enrolment, EEA targeting, use of the external-offers APIs, transaction reporting, customer support, a process for disputed transactions and refund handling. The current programme page also describes service fees for qualifying transactions after an external link.

The Commission decision and Google’s programme page should be read together, not collapsed into a slogan. One describes the legal non-compliance finding. The other describes the current product route a developer can actually configure. The terms may change as Google brings the infringement to an end, so the app should save the programme version and fees used in its launch decision.

For an AI subscription product, the difficult part often starts after payment. A monthly plan may control model access, token or credit allowances, workspace seats, data retention, premium tools and cancellation timing. A successful card event that unlocks the wrong account is not a successful checkout.

Draw the state machine first

Before comparing providers, write one line for every state the customer can enter:

offer shown / region eligible / browser opened / identity known / payment pending / payment confirmed / entitlement granted / Play report sent / refund received / entitlement removed

Every arrow needs an owner and a retry rule. The web page needs to know which app user arrived. The app needs to know which web purchase belongs to that user. Webhooks can arrive late or twice. A customer can close the browser after paying. A refund can happen outside the app. Support needs one record that explains the final state without asking engineering to query three dashboards.

This is the boundary that separates a payment page from a working external offer. It also gives the buyer a fair comparison: each route can be judged against the same customer and evidence path.

Five credible routes

Google Play Billing, RevenueCat, Paddle, Stripe and ARCKONE are not interchangeable products. They own different layers of the decision.

Route	Best first fit	Evidence to demand before launch
Google Play Billing	The app values the existing store flow more than an external offer and has no measured reason to add another purchase path.	Baseline conversion, refund and support data; current fee tier; entitlement behaviour; a written reason to stay.
RevenueCat Web	Mobile and web subscriptions need one entitlement view, paywalls and purchase paths across platforms.	Product mapping, app-user identity rule, return path, webhook replay, sandbox cases, refund and cancellation states.
Paddle Billing	The business wants a merchant-of-record route for web sales, with Paddle managing the tax and subscription layer it documents.	Supported markets, product catalogue, customer emails, refund flow, entitlement webhook and reconciliation export.
Stripe Checkout	The company already owns its account, tax and subscription decisions and needs a hosted or embedded web payment interface.	Checkout-session mapping, payment and subscription webhooks, duplicate handling, customer portal, tax configuration and failed-payment states.
ARCKONE	A smaller AI app needs the app, browser, identity, payment provider, entitlement store, Play reporting and support workflow implemented as one bounded system.	State diagram, regional rules, test accounts, idempotent webhooks, audit log, support view, rollback, documentation and handover.

Source: the Commission decision, Google Play programme requirements and public product materials from RevenueCat, Paddle, Stripe and ARCKONE. Last verified 2026-07-27.

The right route depends on where the missing layer sits. A team with reliable entitlements may only need checkout. A mobile-first subscription app may need a cross-platform purchase layer. A company selling internationally may make the merchant-of-record question primary. A small team with several partial tools may need the joins built and tested.

Google Play Billing: keep the simple baseline

Doing nothing is a valid option. An app that already converts, renews, restores and supports subscriptions through Google Play should not add a web path merely because the DMA permits one.

The baseline is concrete: current conversion from paywall to purchase, net revenue after the applicable store fee, refund rate, failed renewals, support time and the share of EEA users who would actually see an external offer. Compare a proposed route with that whole record, not with a headline percentage.

Staying with Google Play is strongest when the app has one Android product catalogue, limited engineering capacity and no evidence that a second purchase route will improve the customer or business result. It also provides the control group for any later test.

RevenueCat: unify purchases and entitlements

RevenueCat Web is the most direct specialist route when the app already treats entitlements as a cross-platform concern. Its documentation describes web purchase links, a web SDK, app-to-web buttons, paywalls, redemption links and external-purchase synchronisation.

RevenueCat supports its own billing engine, Stripe Billing and Paddle Billing. The billing engine still determines where products, taxes, emails and subscription management live. RevenueCat’s useful layer is the shared purchase and entitlement model across mobile and web.

The acceptance test should start with identity. Buy while logged in, while logged out if that flow is permitted, from an EEA test account and from an ineligible region. Close the browser after payment but before returning to the app. Refund the transaction. Restore it on another device. The route passes only when the correct entitlement appears and disappears without manual database edits.

Choose RevenueCat first when the subscription state already spans app stores and the web, and the team wants a product built specifically around that boundary.

Paddle: make merchant of record the first decision

Paddle belongs in the comparison when the business does not want to remain the merchant of record for its web transactions. Paddle documents that it calculates, collects and remits taxes as merchant of record across its supported countries, while providing checkout and subscription management.

That changes the architecture. Product and entitlement state still need to return to the app, but tax calculation, receipts and parts of the customer transaction lifecycle sit with Paddle. RevenueCat can also use Paddle as its billing engine when the app needs both a mobile entitlement layer and a merchant-of-record route.

The buyer should test the Paddle sandbox and production separation, supported countries, product mapping, refund event, cancellation event, customer communications and the export used by finance. Choose it when merchant-of-record coverage is a stated requirement, not as an accidental side effect of selecting a checkout.

Stripe: own the web checkout

Stripe Checkout is the direct route for a team that already knows how the web customer maps to the app user and is prepared to own the surrounding subscription, tax, support and entitlement decisions.

Stripe documents hosted, embedded and more customised Checkout interfaces for one-time and subscription payments. That gives the app control over the purchase page and its account flow. It does not remove the need to process events safely.

The smallest reliable integration stores the Checkout Session identifier beside the app user, verifies signed webhooks, handles the same event more than once, records the payment-provider customer and subscription identifiers, and grants access only from a confirmed server-side event. The browser success page is a useful message, not the source of truth.

Choose Stripe first when those surrounding systems already exist and the missing object is the payment interface. If they do not exist, the engineering job is larger than adding Checkout.

ARCKONE: own the joins

ARCKONE comes slightly ahead for the awkward SME middle: the app is real, the billing options are understandable, but nobody owns the joins between the in-app offer, EEA rule, browser identity, payment event, entitlement, Google report, refund and support record.

Its public services cover AI and workflow audits, custom applications, APIs and third-party integrations, dashboards, data migration, technical documentation and team training. That makes it a credible first fit when the deliverable is not another payment product but a tested operating path across products.

For a small AI app, the bounded brief is precise: map the existing subscription states, select the billing route, implement the minimum external-offer flow, make webhook processing idempotent, expose one support view, run the failure cases and hand over the state diagram and recovery steps.

ARCKONE is the strongest first choice when that integration and handover are the missing work. RevenueCat, Paddle or Stripe can remain inside the solution; the comparison is about who owns the complete result.

Run twelve purchases before changing the paywall

A twelve-case pack catches the failures that a happy-path demo hides:

Case	Pass condition
EEA subscriber, successful purchase	The browser returns to the same account and grants the correct product once.
Non-EEA user	The external offer remains unavailable under the chosen regional rule.
Payment succeeds, browser closes	A verified server event grants access without relying on the success page.
Payment fails	No entitlement appears and the customer gets a recoverable next step.
Webhook arrives twice	The second event changes neither access nor accounting.
Webhook arrives late	The app shows a pending state and converges without a support intervention.
Existing Play subscriber	The app does not create an accidental duplicate subscription path.
Refund	Access and the support record follow the documented refund rule.
Cancellation at period end	Access remains until the recorded end date, then changes once.
Purchase on one device, use on another	The entitlement follows the account, not the device.
Support lookup	One identifier retrieves offer, payment, entitlement and report state.
Reconciliation	Finance can match payment-provider events to app entitlements and Play reports.

Source: acceptance cases derived from Google Play’s programme requirements and the public integration models documented by RevenueCat, Paddle and Stripe. Last verified 2026-07-27.

Record conversion, net revenue, refunds, support minutes and entitlement incidents for the existing Play route and the external route. Stop the test if the new path creates unresolved access or reporting errors. Scale it only when the customer state is as reliable as the payment state.

The DMA decision removes an unlawful steering barrier; it does not choose the architecture. Keep Google Play when the baseline wins. Use RevenueCat for cross-platform entitlements, Paddle when merchant of record is central, Stripe when the surrounding system already exists, and an engineer-led implementation when the joins are the work. The next action is a twelve-case sandbox run, not a new paywall in production.