Charge per visit when the visit is the decision. Sell a membership when the habit is already there.
A pay as you go app charges for one booking at a time. A membership charges on a cycle and gives the member something a walk-in does not get: included visits, a lower price per visit, first call on the diary. Which one works is not a matter of taste. It follows how often the same person comes back. Someone who books every six weeks will not keep a monthly charge alive. Someone who turns up twice a week is already paying you like a member, and the plan only puts a name on what was happening anyway. Both can live in one app, and for a service delivered in the real world neither of them goes through in-app purchase. Every store rule quoted below comes from Apple's and Google's own policy pages, read on 14 October 2026. Most people hit this decision while picking a booking app builder.
What follows is the arithmetic that predicts which model survives contact with your customers, what each store actually lets you charge for and how, and the four things that break in the first month you run both at once. The last one is the one nobody plans for.
Start hereThe short version
Repeat rate decides it, not the price you want to charge.
Take the plan price you have in mind and divide it by what you charge for one visit. The result is the number of visits a month at which a member stops paying you more than a walk-in. Now look at how often your customers really come back. Below that number, a membership is a discount you are handing to people who were already paying full price. Above it, a membership is a volume commitment, and the thing that limits you stops being the card and becomes the diary.
A membership buys you two things. Money arrives at the start of the month rather than the end, and the booking decision gets made once instead of every time. It costs you two things in return. You are holding money for work you have not done yet, which is a refund risk and in some places a liability you have to account for, and you have promised access to hours that are finite. Pay as you go has neither problem and neither benefit. You get paid for what you did, and every visit is a fresh decision the customer can answer with no.
Which model fits the business you actually run?
Start with the gap between visits. A barber sees the same head every three or four weeks. A hairdresser doing colour sees it every six to eight. A yoga studio sees the same person three times in a week or not for a month. A cleaner comes fortnightly, forever. Those are four different businesses and only two of them support a plan. The trade people usually get wrong is the six week one, because a monthly charge means the customer pays for roughly one and a half visits every time they take one. They do that twice and then they read their statement.
The second question is what your limit is. If you are the person doing the work, your capacity is your own week, and an unlimited plan sells hours you do not have. Sell a fixed number of included visits instead, or stay on per visit pricing and spend the effort on getting the next appointment booked before the customer leaves. If the limit is a room with twenty mats in it, unlimited is survivable, because the marginal cost of the twelfth visit is close to nothing. This is why gyms sell unlimited and a salon booking app almost never should.
The third question is seasonality. If half your year is quiet, a rolling monthly charge runs straight through the quiet half and the customer cancels in the middle of it. Cancelling is easy and resubscribing is a decision, so you lose the next busy season too. A pack of visits with a stated expiry fits that shape far better than a plan does, because the customer buys when they are in the mood to buy and the clock you set matches your season rather than the calendar month.
One more thing to settle before you build either: what a membership includes that is not a visit. Priority slots, a member price on products, a free reschedule inside the cancellation window. Those are usually the parts people actually value, they cost you less than included visits, and they are the reason a plan at a modest price can still be worth having for someone who only comes twice a month. Write the list before you price the plan, not after.
Check yours
How often does the same customer come back?
Pick the rhythm your diary already shows, not the one you want. The answer below is what that rhythm usually supports.
Either, and this is the real decision
The plan price lands close to what this person already spends, so the membership is mostly a commitment device. It will win you a few extra visits and lose you a little margin on the rest.
Watch for: Price the plan against the visits they book now, not the visits you hope they will book.
A rule of thumb, not your numbers. Divide your plan price by your single visit price and compare the result with your real repeat rate.
Does Apple make you use in-app purchase for either one?
For a service people turn up for, no, and it is stronger than no. App Store Review Guideline 3.1.3(e), headed 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 haircut, a treatment, a class in your room, a table, a cleaned kitchen. All of them are consumed outside the app. Both your single booking charge and your monthly membership charge are collected with your own card processing, outside Apple's billing entirely.
In-app purchase sits on the other side of that line. Guideline 3.1.1 says that if you want to unlock features or functionality within your app, and it names subscriptions among the examples, you must use in-app purchase. So the question is never whether the charge recurs. It is what the money buys. A plan that gets someone into your building is 3.1.3(e). A plan that unlocks a video library or a premium tier inside the app is 3.1.1, and that one does go through Apple's billing. Wiring the card up is the same piece of work either way, and adding payments walks through it.
If part of what you sell is digital and does use in-app purchase, Apple allows the two models side by side. Guideline 3.1.2(a) says subscriptions may be offered alongside a la carte offerings, with a library subscription plus a single film rental as the worked example. Three limits come with it. An auto-renewable subscription has to provide ongoing value, its period must last at least seven days, and it has to be available on all of the user's devices. Those limits apply to Apple's own subscription product, not to a membership you bill yourself, so a weekly plan for classes is fine while a four day auto-renewing in-app subscription is not.
On the question people keep asking, which option has to be shown first: nothing in the guidelines sets an order, a default selection or a prominence rule. What Apple requires is clarity about the deal. Guideline 3.1.2(c) says that before asking a customer to subscribe you should clearly describe what the user will get for the price, and 3.1.2(b) says people should have a seamless upgrade and downgrade experience and should not be able to inadvertently subscribe to multiple variations of the same thing. One caution about mixing: the opening line of 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 on the United States storefront and in the cases set out in 3.1.1(a) and 3.1.3(a). If any part of your app sells something digital, keep the two payment paths separate rather than nudging between them.
Apple, App Store Review Guidelines, sections 3.1.1 to 3.1.3, read 14 October 2026
What does Google Play require for a membership?
Read the first half of Google's Payments policy and a membership looks doomed. Apps accepting payment for in-app features or services must use Google Play's billing system, and the examples of what needs it include subscription services, with fitness listed first among them. Keep reading. The policy then sets out cases where Play's billing system must not be used, and the first is where payment is primarily for the purchase of physical services. Google names gym memberships in that list, next to transportation services, cleaning services, airfare, food delivery and tickets for live events.
So Android lands in the same place as iOS by a different route. The test is what the money is primarily for, not whether it arrives once or every month. Classes in your building, appointments with your staff and a clean house are physical services and must not go through Play billing. A fitness video library people watch in the app is a content subscription and must. A plan that bundles both is where people get stuck, and the fix is to stop selling it as one thing: a membership for the real world service, a separate in-app product for the digital part. If what you sell is a seat in a room at a fixed time, a class schedule app is the shape to start from.
Two further lines in the same policy shape your checkout screen. Developers must clearly and accurately inform users about the terms and pricing of any in-app features or subscriptions offered for purchase. And in-app pricing must match the pricing displayed in the user-facing Play billing interface, which matters the moment you have anything going through Play billing alongside your own checkout. Google also notes that in some markets it offers Google Pay for apps selling physical goods or services, which is the route for the exempt side.
The part to take seriously is the steering rule. Outside the exempt cases and the alternative billing programmes, apps may not lead users to a payment method other than Play billing, and the policy spells out the ways that counts: the store listing, in-app promotions, webviews, buttons, links, messaging, adverts and sign-up flows that walk a user out to another payment method. For a pure bookings app none of that applies, because nothing you sell belongs in Play billing. For a mixed app it is the trap, and it is the same trap as on iOS: one screen that offers a digital unlock and a real world plan side by side is the screen that gets your update rejected.
What breaks when you run both at the same time?
The first break is double charging, and it is almost guaranteed on the first build. A member books, the booking screen reaches for a card because that is what booking screens do, and the included visit is never spent. The fix is boring and structural: the booking flow has to ask whether this person has an entitlement before it asks for money, and the included visit has to be decremented by the same action that confirms the booking. Two separate steps and you will get both failures, a charge on a member and a free visit for someone who is not one.
The second is the balance you owe. Included visits create a running total of work people have paid for and not taken, and the only honest designs are expiry at the end of each cycle or rollover with a cap. Pick one, print it on the screen where the money changes hands, and show the member their remaining count every time they open the app. One Apple line is worth knowing even though it probably will not bind you: guideline 3.1.1 says any credits or in-game currencies purchased via in-app purchase may not expire. Visits for a real world service are not bought through in-app purchase, so that sentence does not reach them, and expiry becomes a matter of your own terms and your local consumer law.
The third is a line most people have never read. Guideline 3.1.3(d), Person-to-Person Services, lets you use payment methods other than in-app purchase for real-time person-to-person services between two individuals, and names tutoring, medical consultations, real estate tours and fitness training. Then it adds that one-to-few and one-to-many real-time services must use in-app purchase. So a one-to-one video session you deliver through the app can be billed on your own card entry, while a live group class streamed inside the app lands on the other side of that sentence. A group class people attend in your studio is a different thing again, consumed outside the app and covered by 3.1.3(e). If you plan to stream, work out which of the three you are selling before you build the paywall.
The fourth is the failed card, which is quiet and expensive. Recurring billing retries a declined payment on a schedule and then hands the decision back to you: Stripe's own billing documentation, read on 14 October 2026, describes choosing what happens after the final retry, with the subscription left past due, moved to unpaid, or cancelled. None of those three tells your front desk anything. Decide what a lapsed member sees in the app, whether bookings they already hold still stand, who gets a message and on what day, and what happens to their included visits. Without that, your most loyal customer keeps turning up for two months on a dead card and you find out at the month end.
Apple, App Store Review Guidelines, 3.1.1 and 3.1.3(d), read 14 October 2026
The same business, billed two ways
| What you are comparing | Pay as you go | Membership | Needs a written policy |
|---|---|---|---|
| What the customer decides | Each visit, one at a time | Once, and then it keeps going | No |
| Revenue you can forecast | No | Yes | No |
| Paid before the work happens | No, you are paid for what you did | Yes, so you owe service you have not given | Yes |
| Store route for a real world service | Your own card entry or Apple Pay | Your own recurring billing | No |
| Unused value left on the account | No | Yes | Yes |
| What a failed card costs you | One booking | Access, until you define what lapsed means | Yes |
| Capacity you have to hold back | No | Yes | Yes |
The store route row holds for a service people turn up for. A plan that unlocks something inside the app goes through store billing instead, on both platforms. Google Play, Payments policy, read 14 October 2026
Where this lands if a builder generated your app
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. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, builds a standalone Android APK, and keeps two-way GitHub sync so the code is never trapped in a tool. It is $25 a month with no free tier. What it does not do is submit to the App Store for you, because guideline 4.2.6 says apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content. You are that provider, so you press submit and you own the pricing answers.
That matters here because the model is not a feature you can order. Ask for a booking app and you get a booking app; ask for memberships, included visits and an entitlement check at booking time and you get those too. Either way you are the one who decides whether the plan price divides into the visits your customers actually book, how many slots you hold back for members, and what an unused visit is worth at the end of the month. Those are the answers the code renders, and no generator can supply them.
The honest shortcut is to ship one model first. Build per visit, take real bookings for a month, then read the gap between visits in your own data and price the plan against it. Adding recurring billing to a working booking flow is a small job. Working out that you priced a membership against a repeat rate you did not have is not, because by then you have members who will notice when you change the deal.
Questions people ask about per visit and membership pricing
Neither is better in the abstract. The deciding number is how often the same customer comes back. Divide the membership price you have in mind by your single visit price. That is the number of visits a month at which a member stops paying you more than a walk-in. If your real repeat rate is below it, the membership is a discount handed to people who were already paying full price. If it is above it, the membership is a volume commitment and your constraint moves from the card to the diary. A business where most customers return once every six weeks is a pay as you go business whatever the plan looks like on paper.
Ship one model, read the diary, then add the other
Describe the bookings you take today and get a working app you can charge through this week. The membership question answers itself once you can see how often the same name comes back.
Start building