Resources

In-App Subscriptions: When Apple & Google Bill You

If your subscription is sold through a mobile app, there is a reasonable chance you do not bill your customers at all. Apple or Google does. The store owns the payment method, runs the charge, handles the retry logic, controls the customer communication, and decides when a subscription is finally cancelled for non-payment — while you receive status events and revenue reports after the fact. This is not a worse system, but it is a fundamentally different one, and operators who move between web billing and store billing often misjudge how little of the recovery playbook they still control. This article maps store billing at capability level: what the stores handle, the few levers developers actually have, and the contrast with web billing where recovery is yours to run.

Who does what in store billing

In an in-app subscription, the commercial relationship splits in two. The customer is your user, but the store's payer. Their card sits in their Apple or Google account, not in your processor. When renewal time comes, the store attempts the charge against its own stored payment method, on its own schedule, using its own retry and grace logic, and communicates with the customer through its own channels — store emails, account pages, and payment prompts inside the store environment.

Your systems learn the outcome through server notifications and entitlement checks: a renewal succeeded, a subscription entered a billing retry state, a grace period began, a subscription expired. Your job is to honor those states correctly — keep access alive while the store says the subscription is in a recoverable state, and close it cleanly when the store says it is over. Attempting to run your own parallel dunning on top of store billing is mostly impossible and partly counterproductive: you cannot retry a card you do not hold, and emailing a customer to "update their card" sends them to a store account page you do not control, through a flow you cannot see.

What the stores handle for you

It is worth stating the upside plainly, because web-billing operators tend to see only the lost control:

• Payment method custody and updates. When a store customer replaces a card, every subscription billed through that store account benefits at once. The expired-card problem that dominates web dunning is largely absorbed by the store relationship.
• Retry handling. The store retries failed charges according to its own policies during a billing retry period, without any build on your side.
• Grace handling. Where store grace periods apply, customers keep access while payment problems are resolved, which softens the cliff edge of a failed renewal.
• Localized payment infrastructure. The store handles regional payment methods, taxes in many configurations, currency conversion, and the regulatory surface of consumer billing in its markets.
• Customer billing support. Refunds and payment disputes route through the store's support machinery, for better and worse.

For a small team, that is a genuine operational gift. The price is visibility and leverage: you see outcomes, not decline codes; you get the store's schedule, not yours; and the customer communication that decides whether a billing problem becomes a cancellation is written by a platform with no knowledge of your product's value.

The levers developers actually have

Grace period configuration, where offered

Where the store offers a grace period setting for subscriptions, enabling and correctly honoring it is the single most valuable lever you hold. It keeps entitled access running while the store works the billing problem, and it depends on your app respecting store-reported states rather than cutting access the moment a renewal does not post. Most grace period losses are self-inflicted: the store granted time the app never honored because entitlement logic treated a retry state as an expired one.

Promotional and winback offers inside the store system

Both store ecosystems provide offer mechanics — introductory pricing, promotional offers for existing or lapsed subscribers, and winback-style offers surfaced through store channels. These are your retention instruments inside the store world. Used well, they target the lapsed-for-billing subscriber with a reason to re-enter and fix payment details as part of resubscribing. Used carelessly, they train customers to lapse on purpose. Target them at billing-driven lapses specifically, where the customer never chose to leave.

Your own communication, outside the payment flow

You cannot send the store's billing emails, but you can communicate in the channels you do own: in-app messaging, push notifications, and email to your registered users, subject to each platform's rules. A customer in a billing retry state can be shown a calm in-app notice explaining that their store payment needs attention and where in their store account to fix it. That message must be honest about the path — you are guiding them into the store's flow, not your own checkout — and measured against store policy, which restricts steering users around store billing. Within those bounds, clear guidance beats silence: most store subscribers who lapse on billing do so without ever understanding what happened.

Winback outside the store, within the rules

For subscribers already lapsed, your own channels can carry a winback campaign inviting them back — again, within platform policy on how and where resubscription can be offered. The practical point for this article is narrower: the billing-lapsed store subscriber is the highest-intent winback audience you have, because they never expressed any desire to leave. According to Recurly research, 20–40% of subscriber churn is involuntary; in store billing, where a card problem in a store account can end a subscription without the customer ever hearing from you, assuming every lapse was a decision is an expensive mistake.

The contrast with web billing

Dimension	Store billing (Apple / Google)	Web billing (your processor)
Who holds the payment method	The store	Your payment stack, via your processor
Who retries failed charges	The store, on its own schedule	You, or your recovery tools, on yours
Decline code visibility	Outcomes and states, not raw decline detail	Full decline codes, routable in real time
Customer billing communication	Store emails and prompts	Your branded dunning emails, SMS, and update pages
Card update path	Store account settings	Your secure card-update page
Save offers at cancellation	Store offer mechanics	Your cancel flow with matched offers
Backlog recovery	Lapsed winback through store and your channels	Backfill sequences run on your failed payment history

On the web side, that control is where tools like Swipe Again operate: decline-code-aware smart retries up to 6 attempts over about 16 days, hard declines never retried, branded dunning emails and card-update pages, SMS in the sequence, cancel deflection with Discount, Pause, and Service offers, and a 90-day backfill on connect — across Stripe, Recharge, Seal Subscriptions, Skio, Loop Subscriptions, Chargebee, Recurly, Braintree, and Paddle, at $179/mo flat ($1,799/yr) with no percentage of recovered revenue. None of that machinery ports into the store, because the store does not expose the surfaces it runs on. Our guide to subscription dunning software maps which recovery capabilities exist in which billing environment if you are evaluating a mixed setup.

Running a hybrid business without fooling yourself

Many subscription businesses end up hybrid: store billing on mobile, web billing everywhere else. The management discipline that matters is accounting honestly for the split. Measure failure and recovery rates separately by billing owner, because a single blended churn number hides which system is underperforming and — worse — invites you to apply web fixes to store problems. A spike in store-side billing lapses calls for grace period verification, entitlement-logic checks, and store winback offers. A spike on the web side calls for decline routing and dunning work from the involuntary churn guide. Teams that confuse the two spend quarters optimizing levers that were never connected to the problem.

Reporting needs the same honesty. Benchmark your web recovery against references like the failed payment recovery benchmarks, and judge store performance on the metrics the store actually gives you: renewal rates, billing retry entry and exit, and grace period outcomes. Expecting store billing to produce web-style decline analytics leads to dashboards full of proxies and a team arguing about numbers nobody can act on.

The bottom line

Store billing trades control for convenience. Apple and Google hold the card, run the retries, and own the billing conversation; you keep grace period configuration, store offer mechanics, honest in-app guidance, and winback to the billing-lapsed. Run those levers well, keep store and web metrics separate, and reserve your full recovery machinery for the web billing you actually own. The operators who lose money here are not the ones who chose the store — they are the ones who never noticed the choice had been made for them.

Frequently asked questions

Can I run my own dunning on Apple or Google subscriptions?

Not in the web billing sense. The store holds the payment method and runs retries, so you cannot retry charges or collect updated cards yourself. What you can do is honor grace and retry states correctly in your entitlement logic, guide customers in-app to fix payment details in their store account, and use store offer mechanics and your own channels for winback.

What is a billing grace period in store subscriptions?

It is a store-provided window during which a subscriber keeps access while a payment problem is being resolved, so a failed renewal does not end the subscription immediately. Where the store offers it as a setting, enabling it and making sure your app honors the associated subscription states is the highest-value step most developers can take.

Why do store subscriptions lapse without the customer knowing?

Because billing communication comes from the store, not from you, and store payment prompts are easy to miss among account notifications. A card expires or is replaced in a way the store account does not absorb, retries run their course quietly, and the first thing the customer notices is lost access in your app.

Do failed payment recovery tools work with in-app subscriptions?

Recovery tools operate on billing systems where the merchant controls retries and card updates, such as Stripe, Recharge, Chargebee, and the other web billing platforms. Store billing does not expose those controls, so recovery software cannot run sequences on Apple or Google subscriptions — its role is on the web side of a hybrid business.

How should a hybrid business report churn from the two billing systems?

Separately. Track store billing performance using the states and renewal data the store provides, and web billing performance using decline and recovery metrics. A blended number hides which system is failing and leads teams to apply web dunning fixes to store problems that need grace period, entitlement, or winback work instead.