Dating App Subscriptions and Credits: App Store Billing

Anything a member buys inside a dating app that unlocks features, such as a subscription, a boost, credits or a gift, is a digital good, and the app stores expect it to be sold through their own billing. Apple requires in-app purchase on iOS. Google Play lists virtual currencies and dating subscriptions among the things its billing covers. Web checkout and PayPal sit on the other side of that line, and the line has exceptions that change.

This post maps each thing a dating app sells to the payment path it needs and the duties that follow. If you are building on a ready-made Bumble clone, the plans, in-app purchases and credits are in the product, and the pricing decisions below come before any code. Rules are described as of October 2026 and come only from Apple's and Google's own policy pages; check them before you submit. For the general rules across creator apps, read our Apple and Google in-app purchase rules explainer; this post applies them to a dating app.

Why billing decides your pricing design

Founders usually design pricing first and ask about payment later. On a dating app that order costs time, because the store path decides three things you cannot easily change afterward.

• What you can sell as what. A recurring plan, a one-off boost and a bundle of credits are different product types in each store, with different rules about expiry, restore and refunds.
• What you keep. Store billing carries a fee that comes out of every purchase. We do not quote percentages here because they differ by program and country and change; look up the current figures on each store's fee pages and build them into your plan prices.
• What you must show. Both stores require clear terms before purchase. Your paywall copy, trial wording and cancellation instructions are policy matters, not only design matters.

The question of how dating apps earn is in how dating apps make money. This post starts where that one ends: you have chosen the levers, and now you need to know how members pay for each one.

What you sell and how it is billed

Use this table as a first pass. It describes the standard path for each product type; confirm it against the current policy pages for your markets and accounts.

In the Bumble-style build, premium plans and in-app purchases run through the stores on your own accounts, and credits can also be bought through PayPal on the Android app and the website. Other payment gateways can be set up for your build, and we confirm the scope with you at kickoff. Two cautions before you rely on a non-store route. On iOS, Apple's App Review Guidelines state that unlocking features or functionality, including subscriptions and in-game currencies, must use in-app purchase, and the listed exceptions in section 3.1.3 cover things such as reader apps, person-to-person real-time services and goods or services used outside the app, none of which describes a dating app's premium features. On Android, Google's payments policy says Play billing is required for virtual currencies and subscription services, and it names dating among the subscription examples. It also describes alternative billing programs for developers in eligible countries who enroll and meet extra requirements. Whether your accounts and markets qualify is a question for the Play Console and for counsel, not for this post.

Subscriptions: renewals, cancellation and receipts

A subscription is a promise to charge a member again. Both stores and most consumer laws focus on whether the member understood that promise.

What the stores require

Apple's guidelines say an auto-renewable subscription must provide ongoing value, must last at least seven days and must be available across the member's devices. Before asking someone to subscribe, you should clearly describe what they get for the price. Google Play's subscription policy asks you to state the offer terms explicitly: how much the member is charged, how often and whether a subscription is required to use the app. The information must be visible without extra steps. The policy also requires an easy online way to cancel and clear disclosure of how to manage or cancel. Names must match the actual offer; a subscription named "Free Trial" is an example Google gives of a misleading label.

What the law may add

Consumer rules for subscriptions differ across countries and states and are the operator's responsibility. In the United States, the FTC's page on the Restore Online Shoppers' Confidence Act says sellers must clearly disclose all material terms of an online transaction and obtain the consumer's express informed consent to the charge. Other markets add notice, withdrawal or cancellation duties of their own. Ask counsel in each market; this is not legal advice.

A practical paywall checklist

1. Show the price, the billing period and the renewal in the same view as the buy button.
2. Say what the plan unlocks in plain terms: unlimited swipes, boosts, location changes, analytics, enhanced visibility, an ad-free experience, whichever your admin has set.
3. If you offer a trial or a local discount, state what the price becomes afterwards.
4. Tell members where to manage or cancel, and link to the store's subscription settings.
5. Offer a restore option so a member who reinstalls or changes phone regains access.
6. Keep receipts or confirmations available through the store and your own account page.
7. Make sure cancelling does not need an email or a call to your team.

Plan contents are set in the admin panel, so you can change what a plan includes without a release. That is useful, but each change to what a paying member receives is a change to the terms they agreed to. Keep a record of what each plan included on each date.

Credits and gifts as consumables

Credits and gifts are consumables: a member buys a bundle, spends it, and may buy again. The rules concentrate on how the balance behaves.

• Expiry. Apple's guidelines say credits or in-game currencies purchased with in-app purchase may not expire. If you want expiry as a business rule, apply it only to promotional credits you gave away, not to purchased ones, and check the wording with the store's current guideline.
• Restore. The same guideline asks for a restore mechanism for restorable in-app purchases. Consumable bundles that were spent are not restorable, but a balance that exists should survive reinstalling the app. Store the balance on your server tied to the member account.
• Ledger. Keep one clear record of every credit added, spent, refunded or granted, with dates and reasons. When a member says credits are missing, the ledger is your evidence and theirs.
• Clear prices. Show what a gift or a feature costs in credits, and what the credits cost in money, before the member confirms. Google's payments policy requires terms and pricing to be accurate and to match the billing screen.
• Refund wording. Do not write vague promises such as "credits are non-refundable" without checking that the statement is lawful where you operate. Say what happens to unused credits when an account is closed, and keep the wording consistent across the app, terms and support replies.
• Fraud. Credits are the part most exposed to chargebacks and stolen payment methods. Set limits, agree a refund routine and watch revenue reports. The admin panel includes fraud prevention controls and revenue reports for this purpose.

If your model also lets members go live and receive gifts, income sharing with hosts and payouts is a separate matter with its own rules. We set up payout flows for your build when your model needs them. For a deeper look at how a coin economy behaves under store rules in another category, see our post on app store billing for drama coins; the ledger principles carry over.

A worked example with invented numbers

All numbers here are invented to show the method. They are not real store fees or prices.

Say you plan a monthly plan at 10 in your local currency and the combined cost of store fees and tax comes to 30 percent for a particular member, a figure you would replace with the real number for your accounts. You keep 7 per subscriber per month before your own costs. Now say a boost costs 3 and the same 30 percent applies: you keep 2.10. A credit bundle priced at 5 leaves 3.50.

Two things follow. First, price points are set before the fee: if you need to keep 7 after the store takes its share, the price must already include it. Second, test the same offer on the web only if the store's current rules allow your app to point to it; otherwise the comparison is not one you can run. The full model for how an operator combines these levers is on the how a Bumble-style app earns page, which covers plans, credits, gifts and local offers.

Web checkout, PayPal and linking out

The website and the app are separate shops, and the stores care about the point where one sends members to the other. A member who buys credits on your website with PayPal and then spends them in the app is a common pattern, and it is the reason a credits balance should live on your server, tied to the account, not to a device or a store receipt.

What the stores allow in the app itself is a separate question from what you may do on your own site. Apple's guidelines list the exceptions where other payment methods are permitted, and a dating app's premium features are not among them. Google describes alternative billing only for developers in eligible countries who enroll in a program. Rules on whether an app may mention or link to an outside purchase have been changing, so we do not summarize them here; read the current text in both policies and in our general post on Apple and Google in-app purchase rules, and ask counsel before building a revenue plan that depends on a link-out.

Refunds deserve a line of their own. Store-billed purchases are normally refunded through the store under its rules, so your support team should point members there instead of promising a refund it cannot issue. Gateway purchases, such as PayPal on the web, are yours to refund, and a member can also dispute a charge with their payment provider. Write one refund policy that covers both routes and keep it in the editable policy pages.

Your accounts, your relationship

Three kinds of account sit behind billing, and in a white-label set-up they belong to you, not to us.

• Apple Developer and Google Play developer accounts. The apps are published to your accounts, under your name, and the stores contract with you.
• Payment and tax set-up in each store. Banking details, tax forms and payout settings are yours to complete.
• Your own payment gateway account for PayPal or any other method you use outside the stores.

This is a normal division of work. We deliver and configure the software, rebrand it, deploy it on your servers and publish to your accounts. You pay fees to the stores and gateways, hold the member relationship, answer to consumer rules and handle refunds and support. The stores decide whether to approve the app and its in-app products, and we cannot promise approval. What we can do is help you set up the product list, the restore flow and the cancellation information so a submission is complete. See the Bumble clone features for the plans, purchases and admin controls that support this.

Checklist before submission

1. Every digital item is in the store's product list with the right type: subscription, consumable or one-time.
2. Prices, billing periods and renewal terms appear next to the buy button and match the store's billing screen.
3. A restore purchases action exists and works on a fresh install.
4. Cancellation and management instructions are visible in the app and link to the store settings.
5. Purchased credits do not expire on iOS, and the balance is stored on your server.
6. Free trials and discounts are named accurately and state the price afterwards.
7. Any non-store payment route is limited to what each store's current policy allows.
8. Terms, privacy text and the refund policy are published and editable in the admin panel.
9. Report and block tools work and contact details are published. Apple's section 1.2 and Google's user-generated content policy both look for these, and you can read how to set up the workflow in our post on dating app moderation.
10. Account deletion works from inside the app, as Apple's section 5.1.1(v) asks.
11. A test purchase for each product has been made in each store's sandbox.

Common billing mistakes on dating apps

• Selling credits through PayPal inside the iOS app. The guidelines describe in-app purchase as the route for in-app currencies.
• Naming plans for the offer, not the product. A plan called a free trial invites a rejection under Google's rules.
• Letting credits expire silently. It breaks Apple's expectation for purchased credits and creates complaints.
• Hiding cancellation. Both the store and consumer law look for an easy way out.
• Changing plan contents without a record. A member can say they bought something different from what they now have.
• Ignoring tax. Digital sales carry tax duties that vary by country; set up with your accountant before the first sale.
• Planning margins on list price. Always model on what you keep after fees.

Where to go next

Whether you start from a white-label dating app like Bumble or something else, write down every item you plan to sell and fill in the table in this post for it: type, iOS path, Android path, web path. Then open the current Apple and Google pages and check each row. Decide your refund wording, your credit expiry rule and your cancellation text before you configure the plans in the admin panel. Our published pricing is on our pricing page, and the delivery steps are on how it works. If you want to confirm the payment set-up for your build, contact us and we will confirm the scope at kickoff.

GetFame is an independent vendor and is not affiliated with Apple, Google, Bumble, Tinder or any dating brand named here; the names describe a category of app or a platform you publish to. Store rules are described as of October 2026 from their own policy pages and change. This is not legal advice; ask counsel about consumer, tax and subscription rules in each market.