Can session credits expire?

If you sold them outside store billing, the expiry rule is yours to write, subject to whatever your own consumer law says about prepayments, which varies by country and is worth an hour with an accountant or a lawyer. If you ever sell credits through in-app purchase, Apple closes the door: guideline 3.1.1 says any credits or in-game currencies purchased via in-app purchase may not expire. Guideline 3.2.1(iii) carries the same idea in its list of acceptable business models, allowing rental content to stop working at the end of the rental period and adding that all other items and services may not expire.

Should one credit equal one class?

Start there, because it is the version a customer can check in their head. One credit, one booking, a balance of six means six more classes. You only need weighted credits when your sessions genuinely differ in cost, for example a 30 minute slot against a 90 minute one, or a group class against a private. The moment you weight them, a credit becomes a currency and you inherit currency problems: people spend them on the cheapest slot, and a price rise makes last year's credits worth more than you sold them for. Decide out loud whether a credit is denominated in sessions or in money, and write the answer on the balance screen.

What happens to a credit when someone cancels late or does not turn up?

That is your cancellation policy, and the credit is how you enforce it. The usual shape is a window, say 12 or 24 hours, inside which the credit comes back and outside which it is spent. Pick the number, show the deadline on the booking itself rather than only in the terms, and send one reminder before it passes. A no show is the outside case, so the credit is gone. Deduct on booking, not on attendance, or two people on two phones will take the same last credit at the same time.

Can a customer share a package with a partner or a child?

Only if you decide a balance belongs to a household rather than a person, and it is easier to decide that at the start than to retrofit it. A shared balance needs an owner who can see the whole ledger, a way to add and remove the people who may spend from it, and a line on every entry saying who spent it. If you keep balances personal, offer gifting instead: one person buys, the other redeems. On Google Play there is one more line to note if any part of your credits is ever sold through Play billing, because its Payments policy says in-app virtual currencies must only be used within the app or game title for which they were purchased.

How do I refund a package someone has already half used?

Write the rule before you sell the first one, because the fair answer is not obvious. The common version: charge the sessions already taken at your normal single session price, refund what is left of the money, and say so in the terms the customer agrees to at checkout. That protects the discount, which is the whole point of a package, and it is easy to explain. The version that causes arguments is refunding a flat share of the package price, because someone who took eight of ten classes at a discount then gets money back as well.

Does it change anything if the classes are online?

Yes, and this is the trap. Apple guideline 3.1.3(d), Person-to-Person Services, says that if your app enables the purchase of real-time person-to-person services between two individuals, for example tutoring students, medical consultations, real estate tours, or fitness training, you may use purchase methods other than in-app purchase to collect those payments, and that one-to-few and one-to-many real-time services must use in-app purchase. So a block of private online sessions can stay on your card checkout, while the same block sold for live group classes on a screen has to go through in-app purchase, with Apple's commission and Apple's rule that those credits may not expire. Checked 14 October 2026.

Do I have to show the expiry date in the app?

Show it whether or not anyone makes you. Google's Payments policy requires that developers clearly and accurately inform users about the terms and pricing of their app or any in-app features or subscriptions offered for purchase, and the practical version is simpler than the policy: the balance screen says how many sessions are left and the date they stop working, and the receipt says it too. Expiry dates that only exist in a terms page are the single most reliable source of refund requests and one star reviews in this category.

Articles · GuidesUpdated October 2026

A block of ten classes is not an in-app purchase, because the class happens in the room.

A package is a block of sessions somebody buys up front and spends later, one booking at a time. You sell it with Apple Pay or a card, not with in-app purchase, because App Store Review Guideline 3.1.3(e) says services consumed outside the app must use a payment method other than in-app purchase. Google Play lands in the same place with different words: its billing system must not be used where payment is primarily for physical services, and gym memberships are one of its own examples. Both read on 14 October 2026. That single decision sets your checkout, your refund rule and whether you are even allowed to let the credits run out, which is why it belongs at the front of any thinking about app monetisation.

What follows is where each store draws the line, what a credit should be worth, how to handle expiry and leftovers without losing customers, and the four things that break the first week real people start booking against a balance. The hardest of them is not payments. It is two phones spending the same last credit.

Start here

The short version

Money in today is a promise, not revenue.

Selling a package moves cash forward and leaves you owing sessions. Every design decision that follows comes out of that one fact. The balance has to be a ledger rather than a number, so that each grant and each spend is a row with a date, a reason and the booking it belongs to. A counter you add to and subtract from cannot answer the only question that ever gets asked in anger, which is where the tenth class went.

Four rules carry most of it. One credit means one booking until you have a real reason otherwise. Deduct the credit when the booking is made, not when the person turns up. Put the expiry date and the cancellation deadline on the screen people actually look at. And keep the sale off store billing while the service is delivered in person, because both stores require that and both stores take a cut of the sales they do handle.

Does a prepaid class package have to be an in-app purchase?

No. For a service delivered in person it has to be the opposite. Apple sorts payments by what the money buys, not by how the screen looks. Guideline 3.1.1 is the first test: if you want to unlock features or functionality within your app, by way of example subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version, you must use in-app purchase. A package of studio classes unlocks nothing in the app. It buys an hour of somebody's time in a building.

Guideline 3.1.3(e), headed Goods and Services Outside of the App, is the one that decides it: if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. Note the verb. Not may, must. People read this as a loophole and it is really an instruction. Sell a block of in-person sessions through in-app purchase and you have the wrong payment method, not a clever one.

Two details in the same section are worth knowing before you draw the screen. The preamble to 3.1.3 says apps in that section cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except for apps on the United States storefront and as set out in 3.1.1(a) and 3.1.3(a). In practice that means you take the card in your own checkout, which 3.1.3(e) names, rather than pushing people out to a web page. And 3.1.1 says digital gift cards, certificates, vouchers and coupons which can be redeemed for digital goods or services can only be sold in your app using in-app purchase, while physical gift cards that are sold within an app and then mailed to customers may use other methods. A gift card that buys studio classes is redeemed for neither of those things, so the sale follows the sessions it pays for.

The exception is online delivery, and it is sharper than most people expect. Guideline 3.1.3(d), Person-to-Person Services, says that if your app enables the purchase of real-time person-to-person services between two individuals, for example tutoring students, medical consultations, real estate tours, or fitness training, you may use purchase methods other than in-app purchase, and that one-to-few and one-to-many real-time services must use in-app purchase. One trainer, one client, on a video call: your checkout. One trainer, nine clients, on the same video call: in-app purchase. Same product page, same price, different rule.

Apple, App Store Review Guidelines, sections 3.1.1 and 3.1.3, read 14 October 2026

Check yours

Which checkout does your package need?

Tick everything your package can be spent on. Where the session happens is what decides the answer, not what you call the product.

Nothing ticked. A package that can only be spent on something you deliver in person never touches store billing on either platform.

What does Google Play allow when you sell a block of real classes?

The same answer, reached from the other end. Google's Payments policy starts from the obligation: apps requiring or accepting payment for access to in-app features or services, including any app functionality, digital content or goods, must use Google Play's billing system. Then it lists the cases where its billing system must not be used, and the second one is payment primarily for the purchase of physical services. The examples it gives are transportation services, cleaning services, airfare, gym memberships, food delivery, and tickets for live events. A studio sells the same sort of thing as the gym in that list.

Two lines from the same policy change how you name things. The in-app purchase examples include subscription services, and Google's own illustration of those begins with fitness. So a package that unlocks recorded workouts is Play billing, while a package of classes you teach in person is not, and an app that sells both is selling two products through two checkouts. The other line is narrower and catches people who reach for the word credits: in-app virtual currencies must only be used within the app or game title for which they were purchased. If what you are selling is really a prepaid balance for a service in the world, call it sessions or visits rather than coins, and keep it away from anything that looks like an in-app currency.

The policy also bars apps from leading users to a payment method other than Play's billing system, other than in the conditions its own numbered sections describe, and it points to a programme for alternative billing and for steering in eligible countries and regions. The page does not print those section numbers in its body text, so do not guess which one covers you: read it in full, and note that Google says it offers Google Pay in some markets for apps selling physical goods or services. The honest summary for a studio app is that your in-house card checkout is the expected route and your advertising for it stays out of anything Google would class as an in-app purchase.

Google Play Console Help, Payments policy, read 14 October 2026

What is one credit worth, and should the package expire?

One credit, one booking. Start there and stay there for as long as you can, because it is the only version a customer can verify without doing arithmetic. Weighted credits earn their place when the sessions genuinely differ, a 30 minute slot against a 90, a group class against a private hour. The cost of weighting them is that a credit becomes a currency. People spend currency on the cheapest thing it buys, so your quiet weekday slots fill and your peak class stays half empty. And when you put prices up, last year's credits buy this year's class. Decide whether a credit is denominated in sessions, where the price risk is yours, or in money, where it is theirs, and print the answer next to the balance.

Expiry is the question people avoid until it bites. The business case for it is real: an open-ended balance is a liability that never ages off your books, and a customer who bought ten classes two years ago is not coming back, but their credits still might. The humane version of expiry is a long window, a freeze you can apply for illness, injury or a holiday, a reminder a fortnight out, and the date visible on the balance from the day of purchase. The version that generates refund requests is a short window buried in a terms page. Your own consumer law may also have something to say about prepayments, and it differs by country, so get that checked rather than copying a competitor.

One store rule removes the choice entirely, and it is the strongest practical reason to keep these sales outside in-app purchase. Guideline 3.1.1 says any credits or in-game currencies purchased via in-app purchase may not expire, and that you should make sure you have a restore mechanism for any restorable in-app purchases. The acceptable business models list says it again from the other side, at 3.2.1(iii): disabling access to rental content after the rental period has expired is fine, and all other items and services may not expire. Sell credits through in-app purchase and you have sold them forever. Read 14 October 2026.

Both decisions are easier to make once you can see the balance on a real screen next to a real diary, which is the argument for prototyping the booking side first. A package is only interesting when there is something to spend it on, so an appointment calendar app is the sensible first build, and calendar sync is what stops a credit being spent on a slot you have already given to someone else by phone.

Apple, App Store Review Guidelines, sections 3.1.1 and 3.2.1, read 14 October 2026

What breaks first once people book against a balance?

The last credit, spent twice. A phone and a laptop both show a balance of one, both tap book, and both get a place. Deduct at the moment the booking is created, in the same write that creates it, and treat the balance as the thing that is allowed to say no. If you wait until attendance, you are running a diary with no brakes. Return the credit when a booking is cancelled inside your window, and write that return as its own row rather than editing the original spend, so the history still reads correctly a year later.

Then the front desk. Plenty of customers never open the app: they ring, or they walk in, and somebody on your side books them. If the only way to spend a credit is the customer's own phone, the balance drifts from reality within a week and your staff start keeping a paper list. A redeem screen for staff, with a search box and a one tap deduction, is not a nice to have. It is the difference between a ledger people trust and one they work around.

Third is the no show, which is the only reason many studios want packages at all. A credit is a cleaner enforcement tool than a fee, because it needs no new payment and no argument about a card. Set one window in hours, show the deadline on the booking card rather than in a terms page, send a single reminder before it passes, and let a missed class take the credit. Google's Payments policy puts the general obligation plainly: developers must clearly and accurately inform users about the terms and pricing of their app or any in-app features or subscriptions offered for purchase. The studio version of that sentence is that nobody should learn your cancellation rule by losing a class to it.

Last is the accounting, and it is the one that surprises founders. The money arrived in March and the classes happen in June, so March was not a good month, it was a loan. Keep a report that shows outstanding sessions and the cash sitting behind them, split by package, because that number is your real obligation and it is the one your accountant will ask for. It is also the number that tells you whether a discount is working: a package nobody finishes is not loyalty, it is breakage.

Google Play Console Help, Payments policy, read 14 October 2026

The same package, priced by where the session happens

What the credits buy	App Store	Google Play	Can the credits expire
A class in your room	Outside in-app purchase, guideline 3.1.3(e)	Outside Play billing, physical services	Yes
Live one-to-one online	May use another method, guideline 3.1.3(d)	Not in the physical services list	Yes
Live online group class	In-app purchase, guideline 3.1.3(d)	Play billing	No
A recorded library	In-app purchase, guideline 3.1.1	Play billing	No
Classes plus a recorded library	Two products, two checkouts	Two products, two checkouts	Only on the half you sell yourself

The last column is the store rule only. Where it says yes, Apple and Google leave expiry to you, and your own consumer law may still have something to say about how long you can hold somebody's prepayment. Where it says no, guideline 3.1.1 has already decided: credits bought through in-app purchase do not expire.

Where this lands if a builder generated your app

The rules do not soften because an AI wrote the code, and on iOS you are still the one who submits. Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. For a studio app you are that provider, so the payment decisions above are yours to defend in review.

Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync, so a credit ledger is ordinary code you can read and change rather than a setting in somebody's dashboard. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK, and it does not submit to the App Store for you, for the reason in 4.2.6. It costs $25 a month with no free tier, a smaller line in this project than the store fees you can read about in what it costs to publish an app.

Ask for the ledger in those words and you get something you can audit: a packages table, a grants and spends table with a reason on every row, and a balance that is a sum rather than a stored number. Ask for a card checkout and a staff redeem screen in the same sentence, because the second one is the half everybody forgets. The honest limit: no builder decides your expiry window, your cancellation hours or your refund rule. Those are the parts of this product that are actually your business, and they want an afternoon with a pen before anyone writes code.

Questions people ask about class packages and session credits

No, and more than that, it must not be, as long as the sessions happen outside the app. App Store Review Guideline 3.1.3(e), Goods and Services Outside of the App, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. A block of ten classes in your studio is that. Read on 14 October 2026. The premise people start from, that a bundle of sessions is a consumable in-app purchase, is the wrong one for a real world service.

Write the four rules down, then build the ledger

What a credit buys, when it expires, what a late cancellation does to it, and what a half used package refunds. Four sentences. They take an afternoon to settle and they decide every screen after that.

Start building