iOS subscription billing retry: how Apple handles failed payments and what you can do about it

When a subscriber's payment method fails, Apple doesn't cancel the subscription immediately—it retries. Here's exactly how Apple's billing retry logic works, what the grace period means for access, and how to reduce the involuntary churn this creates.

A subscriber clicks "cancel" and you lose a customer intentionally. That's voluntary churn—the kind you can model and address with retention flows, winback offers, and pricing adjustments. But a significant share of iOS subscription cancellations happen for a completely different reason: the subscriber's payment card is expired, over its credit limit, or declined by their bank. They didn't choose to leave. Apple tried to renew the subscription, couldn't, and eventually suspended access.

This is involuntary churn, and most developers underestimate how much of it is recoverable. Understanding exactly how Apple's billing retry logic works—and how to layer your own recovery flows on top of it—is one of the clearest paths to improving subscription retention without spending anything on new acquisition.

How Apple's billing retry schedule works

When a renewal attempt fails due to a billing issue, Apple does not cancel the subscription immediately. It enters a retry phase: a series of automatic re-attempts spaced over multiple days. Apple has not published the precise retry schedule in public documentation, but patterns observed across large developer cohorts and corroborated by RevenueCat's reporting on billing recovery suggest a sequence that runs approximately as follows:

• Day 0: The billing date arrives. The renewal attempt fails.
• Day 1: First retry attempt.
• Day 3: Second retry attempt.
• Day 6: Third retry attempt.
• Day 16: Fourth and typically final retry attempt before the subscription lapses.

If none of the retry attempts succeed, Apple marks the subscription as expired due to a billing issue—not as cancelled. The distinction matters operationally: a billing-lapsed subscription can be reactivated simply by the user updating their payment method. They don't need to re-subscribe from scratch, find the app again, or re-enter through a paywall. Apple may prompt them to update their payment details in the App Store, in the Wallet app, or via a direct in-app prompt from your application.

During the retry window, Apple's treatment of the subscriber's continued access depends on whether you have the billing grace period enabled for the relevant subscription group.

The billing grace period: what it is and why it changes recovery rates

The billing grace period is an optional feature you enable per subscription group in App Store Connect. When enabled, subscribers whose renewal fails continue to have full access to your app while Apple's retry attempts are in progress. When disabled, access is suspended the moment the first renewal fails—even before Apple has completed its retry sequence.

Grace period lengths available to you depend on the subscription duration:

For monthly subscriptions, the 6-day grace period aligns well with the typical retry window—giving Apple time to attempt multiple retries while the subscriber retains access. For annual subscriptions, the 16-day window is more generous, but it also means you are providing paid-tier access for a longer stretch without confirmed revenue.

The prevailing view among iOS subscription practitioners, consistent with RevenueCat's reporting on billing recovery cohorts, is that enabling the grace period meaningfully reduces involuntary churn. When subscribers retain access during the retry window, they have a direct incentive to resolve the payment issue. When access is cut immediately, a user who might have updated their card and forgotten about the failure instead notices the app stopped working—and at that point many simply do not bother returning. The pain of updating a card is low, but so is the urgency once the app is already gone.

Enabling the grace period requires one entitlement-check change in your app: you need to handle the grace period state from the subscription status. During an active grace period, the isInBillingRetryPeriod field in the subscription receipt (or the equivalent status: 4 from the App Store Server API) signals that the subscriber has a pending billing issue but should still receive access. If your app uses RevenueCat, Adapty, or a similar entitlement SDK, the SDK surfaces this state so you can continue granting access without significant additional code beyond checking the entitlement.

Reading subscription status during billing issues

Whether you handle subscriptions server-side or entirely client-side, you need to correctly interpret subscription status during the billing retry window. Apple's App Store Server API returns a status field per subscription record that maps directly to billing states you need to act on:

Status 3 (billing retry, no grace period) and status 4 (billing retry, grace period active) are the two states that distinguish apps with the grace period enabled from those without. Without the grace period, you jump directly from status 1 to status 3 on a billing failure, and you should gate access. With the grace period, you'll see status 4 for the grace period duration before moving to status 3 or back to status 1 if the retry succeeds.

If you use the App Store Connect API with JWT authentication to query subscription status server-side, you can poll for status changes and trigger your own in-app messaging accordingly. The preferred approach for real-time handling, however, is to configure server-to-server notifications, which eliminate the latency and cost of polling entirely.

Server-to-server notifications for billing events

Apple's App Store Server Notifications (version 2) deliver real-time webhook payloads to a URL you configure in App Store Connect under "App Information > App Store Server Notifications." Several notification types are directly relevant to billing failures, and building your involuntary churn recovery flow around them is significantly more reliable than receipt polling:

• DID_FAIL_TO_RENEW: Delivered immediately when a renewal attempt fails. The payload indicates whether the subscription is now in a billing grace period (isInBillingRetryPeriod: true) or whether access should be gated immediately. This is your first signal that a billing issue has occurred and the moment to begin in-app prompting.
• GRACE_PERIOD_EXPIRED: Delivered when the grace period ends without a successful payment. At this point access should be revoked if your app hasn't already acted on the status.
• DID_RENEW: Delivered when a retry attempt succeeds and the subscription renews. You should restore full access immediately upon receiving this, and ideally suppress any billing-issue prompts in the app without requiring the user to restart.
• EXPIRED: Delivered when the subscription ultimately expires without renewal—after the retry window ends or following a user-initiated cancellation.

If you haven't configured a server notification URL, you're effectively flying blind during billing issues. You learn about the subscription state only when a user opens your app and you fetch their receipt on-demand—which may be days into the retry window, or not at all if the affected user hasn't opened the app since their card expired. For apps with meaningful active subscription bases, the absence of server notifications is one of the most common and most correctable operational gaps. The setup is a single URL configuration in App Store Connect and a webhook handler on your backend.

Practical strategies to reduce involuntary churn from billing failures

Apple's retry system handles the mechanical recovery attempts. Your job is to increase the probability that the subscriber resolves the underlying payment issue before the retry window closes.

Enable the billing grace period for every subscription group. This is the single highest-leverage setting. Enable it in App Store Connect under the subscription group settings. It takes effect for all renewals going forward and requires no App Store review. The only meaningful cost is a short period of access without confirmed revenue—a cost that is almost universally outweighed by the recovery uplift for monthly and annual subscribers.

Display an in-app payment prompt immediately on DID_FAIL_TO_RENEW. When you receive the billing failure notification and the subscriber next opens the app, show a visible but non-disruptive banner or in-session modal explaining that there's a payment issue and providing a direct deep-link to the iOS subscription management UI. Many subscribers don't check email promptly; an in-app prompt catches them at a moment of active engagement. You can deep-link directly into the subscription management panel using itms-apps://apps.apple.com/account/subscriptions, which drops the user directly to the relevant screen without requiring navigation.

Segment your win-back flow by churn type. A subscriber who lapsed due to a billing failure is behaviorally different from one who cancelled intentionally. The billing-lapsed subscriber primarily needs a low-friction path back; they did not express intent to leave. Over-incentivizing billing lapses with discount offers—treating them the same as intentional cancellations—trains users to let payments fail. Keep the billing-lapse recovery flow focused on reducing friction and clearly communicating the next steps. Reserve discount offers for intentional churners. The AppsOps pricing dashboard can help you model revenue impact by cohort type so you can size how much each recovery segment is worth.

Time your in-app prompts strategically. Showing a payment error banner on every screen creates friction and may push a user toward an explicit cancellation rather than payment resolution. Show the prompt once per session, at app open, during the grace period. Once the grace period expires, a harder gate is appropriate—but even then, a one-step path to payment update beats a full re-subscription flow for users who want to return.

Monitor recovery rates by subscription duration and market. Annual subscribers have a 16-day retry window; weekly subscribers have 3 days. Recovery rates naturally differ across durations, and the operational effort to recover an annual subscriber is more justifiable than for a weekly subscriber at the same absolute dollar value. Markets with higher rates of prepaid payment methods—notably parts of Southeast Asia, Eastern Europe, and Latin America—tend to show elevated billing failure rates. For context on why subscriber payment behavior differs by market, the dynamics covered in iOS subscription churn in low-PPP markets apply to billing failure rates as well: markets where prepaid debit is the norm have structurally higher involuntary churn independent of user intent.

Tracking these dimensions separately, rather than reporting a single blended involuntary churn rate, is what allows you to intervene at the right level of the funnel with the right message.

Sources and further reading

• Apple Developer Documentation: App Store Server Notifications
• Apple Developer Documentation: Get All Subscription Statuses (App Store Server API)
• Apple Developer Documentation: Handling Subscriptions Billing (StoreKit)
• RevenueCat Engineering Blog: iOS Subscription Lifecycle
• Phiture Mobile Growth Stack: Reducing Involuntary Churn
• AppFollow Blog: Subscription Analytics and Operations