Non-renewing subscriptions hand you the expiry, the renewal, and every refund, here's what that really costs

Most of the subscription advice you read assumes the store does the renewing. Non-renewing subscriptions break that assumption on purpose. A non-renewing subscription charges the customer once, grants access for a set stretch of time, and then simply ends. Apple does not bill again, does not send a renewal, and does not even keep track of when the access runs out. That last part is the catch. The moment you choose this model, the expiry clock, the renewal nudge, and the cleanup after a refund all move from Apple's servers to yours.

Google Play has the same shape under a different name, the prepaid plan, and it comes with a refund quirk that can hand money back to a customer who never used what they bought. Here is how a non-renewing subscription and a prepaid plan actually work on each store, what a refund does to one, and what the fixed-term model costs you once you count the value you ship on day one.

Why a non-renewing subscription is a one-time charge that behaves like a subscription

A non-renewing subscription sits in an odd spot among the in-app purchase types. It is not a consumable, because it grants time rather than a quantity of something. It is not an auto-renewable subscription, because nothing renews. Apple's own description is plain: a non-renewing subscription gives a customer access to content or a service for a limited period, and it does not renew automatically. A season pass, a month of an archive, a course that unlocks for ninety days, these are the natural fits.

What makes it a subscription in name only is who keeps time. With an auto-renewable subscription, Apple tracks the expiry, charges the card, and tells you through App Store Server Notifications when a renewal succeeds or fails. With a non-renewing subscription, none of that happens. Apple hands you the sale and steps back. Your server has to record when the access period ends, cut off access at that point, and decide whether and how to invite the customer to buy again. Because Apple is not watching the clock, nothing on Apple's side stops a customer from buying the same non-renewing subscription twice, so preventing overlap is your job too.

How each store runs a fixed-term subscription

Apple calls it a non-renewing subscription

On the App Store, you set up a non-renewing subscription in App Store Connect like any other in-app purchase, give it a duration, and sell it. The charge is a single payment. When the period is up, the customer keeps nothing unless they buy again, and buying again is a brand new purchase, not a renewal Apple schedules for you. There is no billing retry, no grace period, and no account hold, because there is no recurring charge to retry. Those safety nets exist only for auto-renewable subscriptions.

Google Play calls it a prepaid plan

Google Play's prepaid plan is the same fixed-term idea built into Play Billing. A prepaid plan does not renew on its own. To keep access going, the customer buys a top-up, and Google is specific about how that works. The top-up charges the full price immediately and extends the entitlement by the top-up's duration. A top-up gets a new purchase token, with the old one carried in the linkedPurchaseToken field so you can stitch the history together. Users cannot cancel a prepaid plan the way they cancel an auto-renewing one. It simply expires when its paid time runs out.

Google also puts a hard deadline on acknowledging a prepaid purchase, and the penalty for missing it is a refund. A prepaid plan of one week or longer has to be acknowledged within three days. A prepaid plan shorter than a week has to be acknowledged within half its length, so a three-day plan gives you a day and a half. Miss the window and Google revokes the top-up, revokes and cancels the remaining subscription, and refunds the customer. That is not a customer changing their mind. It is an integration slip that unwinds the whole sale.

What a refund does to a fixed-term subscription

On the App Store, a refund goes through Apple

A customer who wants their money back on a non-renewing subscription does not come to you first. They file at reportaproblem.apple.com, pick a reason, and Apple reviews the request and decides. You do not approve it, and for a non-renewing subscription there is no store notification that asks you for usage evidence before the decision, the way a consumable refund can. If Apple grants it, you learn about it as a refund on your side and in your reports. Because your own server is the only place the access period is recorded, you also have to decide what a refunded non-renewing subscription means for access, and enforce that yourself.

On Google Play, a refund and a revoke are different actions

Google Play splits what most people call a refund into two different outcomes, and the difference decides whether the customer keeps using your app. A straight refund can leave the customer's access in place until the paid period expires. A revoke, which you can trigger through the API and which is also what a chargeback does, ends access immediately, and Google tells you to cut the entitlement the moment it lands. So a refunded prepaid customer might still be using the content you gave them, or might be locked out on the spot, depending on which path was taken.

The unused prepaid refund you cannot see coming

Google adds one exception that is easy to miss. A customer can request a refund on a prepaid plan they have not used, even though a used prepaid plan generally cannot be refunded and past subscription charges usually stand. The self-service refund path is short and narrow on Google Play otherwise: a customer can return a purchase within 48 hours, and only once per app. Past that, the request routes to you. But the unused-prepaid rule sits outside that window, so a buyer who tops up and never opens the app has a clean way to take the whole payment back.

What the fixed-term model actually costs you

The money math on a fixed-term subscription is different from an auto-renewing one, and it is different in a way that is easy to underprice.

You ship the whole term on day one

When someone buys a month of access, a season pass, or a ninety-day unlock, you owe them the entire period from the first tap. The compute, the API calls, the storage, and any per-user cost your app carries are spent across a window you were paid for once, at the start. A refund on that purchase does not give you back the days you already served. If a customer used two days of a thirty-day pass and Apple refunds it, or Google revokes it, you are out the price and out the cost of those two days, and there is no proration that hands you a slice back. Fixed-term revenue stays fully reversible for the length of the term, and the value behind it is already leaving your budget.

The refund you cause yourself

The prepaid acknowledgment rule turns a code path into a refund. If your server does not acknowledge a prepaid purchase or top-up in time, Google does not just warn you. It revokes the top-up, cancels the rest of the subscription, and refunds the customer, all at once. That is a sale you closed and then lost to a missed callback, and the fix is entirely on your side. Acknowledge server-side, fast, and never lean on the user reopening the app to trigger it. On a short prepaid plan, where the window can be a day and a half, a slow acknowledgment pipeline is a standing refund risk.

No involuntary churn, but retention is now manual

There is a real upside to hold onto. A fixed-term subscription cannot churn involuntarily, because there is no renewal charge to fail. The declined cards, the billing retries, and the account holds that quietly end a share of auto-renewing subscriptions simply do not apply. Nobody gets locked out because a card expired. The trade is that retention stops being automatic. Every continuation is a fresh decision to pay, so a customer who lapses does not show up as a failed charge you can recover. They show up as nothing at all, a silent gap where a renewal would have been. Winning them back is a prompt you have to build and time yourself, and the revenue you do not chase is revenue that just does not arrive.

Every one of these events, the refund, the revoke, the chargeback, the expiry, arrives on the same App Store Server Notifications and Real-time Developer Notifications that RefundHalt already watches. A non-renewing subscription and a prepaid plan do not hide their refunds, they report them like any other purchase. Reading those feeds is how you turn a model where the store stops tracking the clock into one where you always know which fixed-term sales became revenue and which ones came back.

The short version

A non-renewing subscription on the App Store, and a prepaid plan on Google Play, is a single charge for a fixed stretch of access that never renews. Apple does not track the expiry, so your server does. Google lets a customer refund an unused prepaid plan, and it refunds the whole thing if you miss the acknowledgment deadline. A Google refund can leave access running or, as a revoke or a chargeback, cut it immediately. There is no involuntary churn to fight, but there is no automatic renewal either, so retention is a prompt you own. You deliver the full term up front, and a refund claws back money you have already started spending, so price the model for the day-one cost, not the headline sale.