Last updated: 31/07/2026
The short answer
You do not get to pick your payment rail. The platforms pick it for you, and the rule is about what you are selling, not how big your company is. If the thing being bought is consumed inside the app — a subscription, premium content, an ad-free tier, in-game currency — Apple guideline 3.1.1 is blunt: "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." Google says the same thing about its side of the fence: apps "requiring or accepting payment for access to in-app features or services, including any app functionality, digital content or goods (collectively 'in-app purchases'), must use Google Play's billing system for those transactions".
Now the half that surprises people. If the thing being bought is a physical good or a service consumed outside the app, the rule inverts. Apple guideline 3.1.3(e) states that in that case "you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry". Google's Payments policy is equally direct: its billing system "must not be used" where payment is primarily for the purchase or rental of physical goods, or for physical services — the policy names "transportation services, cleaning services, airfare, gym memberships, food delivery, tickets for live events". So the restaurant ordering app, the salon booking app, the retail app and the logistics app are not paying a 30% store commission on their order value. They are not permitted to route it through the store at all.
Where the line actually falls
The test both stores apply is consumption, not delivery. A yoga studio app selling a ten-class pass is selling a physical service — the class happens in a room, outside the app — so it takes card payment. The same studio selling an on-demand video library is selling digital content consumed in the app, so that has to go through in-app purchase and Play billing. Same business, same app, two different rails, and the decision is made by the store's policy rather than by your finance team.
| What you are selling | Apple | Google Play |
|---|---|---|
| Subscription to content or features in the app | In-app purchase required (3.1.1) | Play billing required |
| Ad-free tier, premium features, new levels | In-app purchase required (3.1.1) | Play billing required (policy names "an ad-free version of an app or new features not available in the free version") |
| Cloud storage, SaaS, productivity software sold to consumers | In-app purchase required (3.1.1) | Play billing required (policy names "cloud software and services") |
| Physical goods — groceries, clothing, electronics | Other payment methods required (3.1.3(e)) | Play billing "must not be used" |
| Physical services — food delivery, transport, cleaning, gym memberships, event tickets | Other payment methods required (3.1.3(e)) | Play billing "must not be used" |
| Real-time one-to-one services — tutoring, medical consults, property tours, personal training | Other payment methods permitted (3.1.3(d)); one-to-few and one-to-many "must use in-app purchase" | Assess against the physical-services exclusion |
| Peer-to-peer payments, online auctions, tax-exempt donations | Assess against 3.1.3 and the charity provisions | Play billing "must not be used" |
Rules as published by Apple (App Store Review Guidelines, section 3.1) and Google (Play Console Help, Payments policy), both retrieved 31 July 2026. This table is a reading aid, not legal or review advice — edge cases go to the store, not to a blog post.
What Apple requires
Apple's section 3.1 splits into a default and a list of exits. The default is 3.1.1: anything that unlocks features or functionality inside the app goes through in-app purchase, and "Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc." That last clause catches a surprising number of workarounds owners propose in kick-off meetings, including the popular one where the app is free and a code emailed after a web purchase turns on the paid tier.
The exits sit in 3.1.3. Beyond the physical-goods rule at 3.1.3(e), two matter commercially in Singapore. 3.1.3(d) Person-to-Person Services permits other payment methods where the 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)" — but it draws the line immediately after: "One-to-few and one-to-many real-time services must use in-app purchase." A one-to-one telehealth consult and a twelve-person live class are on opposite sides of that sentence. 3.1.3(c) Enterprise Services covers apps "only sold directly by you to organizations or groups for their employees or students", and closes with "Consumer, single user, or family sales must use in-app purchase" — so a B2B tool that later opens a self-serve individual plan has changed rails without changing a line of business logic.
There is one more constraint that catches teams who assume "not required to use IAP" means "free to advertise the alternative". Apple's chapeau 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 forth in 3.1.1(a) and 3.1.3(a)", though "Developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase". Singapore is not the United States storefront. Plan your upsell copy accordingly, and plan it before the screens are designed rather than after review bounces them.
What Google Play requires
Google's Payments policy is structured the same way but states the exclusions as a list, which makes it easier to scope against. Play billing is mandatory for "in-app purchases of: Items (such as virtual currencies, extra lives, additional playtime, add-on items, characters, and avatars); subscription services (such as fitness, game, dating, education, music, video, service upgrades, and other content subscription services); app functionality or content (such as an ad-free version of an app or new features not available in the free version); and cloud software and services (such as data storage services, business productivity software, and financial management software)". Note that "fitness" and "education" appear there as content subscriptions — the studio selling recorded classes is squarely inside; the studio selling a slot in a physical room is not.
The anti-steering rule is where Android builds most often go wrong, because it is written broadly. Outside the stated exceptions, "apps may not lead users to a payment method other than Google Play's billing system", and the prohibition explicitly covers "In-app webviews, buttons, links, messaging, advertisements, or other calls to action" as well as "In-app user interface flows, including account creation or sign-up flows, that lead users from an app to a payment method other than Google Play's billing system as part of those flows". A sign-up screen that quietly routes a new user to your website to enter a card is caught by the last clause even if no button says "pay on the web". If your product plan depends on that flow, it needs to be re-planned at scoping, not discovered in review.
What the store commission actually costs
Where store billing does apply, the rates are published and tiered, and the tier most Singapore SMEs land in is 15% rather than 30%. Apple's App Store Small Business Program "features a reduced commission rate of 15% on paid apps and In-App Purchases", open to "Existing developers who made up to 1 million USD in proceeds in the prior calendar year for all their apps, as well as developers new to the App Store". Apple also states the consequence of success: "If a participating developer surpasses the 1 million USD threshold in the current calendar year, the standard commission rate will apply to future sales", with re-qualification possible "the year after" if proceeds fall back below it.
Subscriptions have their own curve. Apple's auto-renewable subscriptions page explains that "During a subscriber's first year of service, you receive 70% of the subscription price at each billing cycle, minus applicable taxes. After a subscriber accumulates one year of paid service, your net revenue increases to 85%". Small Business Program members skip the wait: they "receive 85% of the subscription price at each billing cycle (minus applicable taxes), regardless of whether or not the subscription has accumulated one year of paid service". Two details worth writing into your model: days of paid service "are specific to each subscription group", and if a subscription lapses and is renewed within 60 days the accumulated days "resume from the recovery date" rather than resetting.
On the Android side, one point of local nuance is easy to miss. Google has published a restructured fee schedule "For transactions with users in the EEA, UK, or US starting June 30, 2026", built around whether an install is new or existing. Singapore is not in that set. The Service fees page keeps a separate schedule "For all remaining markets until the announced updated service fees are rolled out globally", and that is the one that governs your Singapore revenue today. Google also publishes the population figures behind the tiers: "97% of developers distribute their apps and take advantage of all Google Play has to offer at no charge", and of those who do pay a fee, "99% are eligible for a fee of 15% or less".
| Store | What is charged | Rate |
|---|---|---|
| Apple — Small Business Program | Paid apps and in-app purchases | 15% commission (eligibility: up to USD 1M proceeds in the prior calendar year) |
| Apple — above the threshold | Paid apps and in-app purchases | "the standard commission rate will apply to future sales" |
| Apple — auto-renewable subscriptions | Each billing cycle, year 1 | Developer receives 70% of the subscription price, minus applicable taxes |
| Apple — auto-renewable subscriptions | Each billing cycle, after 1 year of paid service | Developer receives 85%, minus applicable taxes (85% from day one for Small Business Program members) |
| Google Play — Singapore and other remaining markets | First USD 1M of annual earnings, 15% tier | 15% |
| Google Play — Singapore and other remaining markets | Earnings above USD 1M per year | 30% |
| Google Play — Singapore and other remaining markets | Auto-renewing subscriptions | 15% "regardless of revenue earned by the developer each year" |
Rates as published by Apple (Small Business Program; auto-renewable subscriptions) and Google (Play Console Help, Service fees), retrieved 31 July 2026. The separate EEA/UK/US schedule effective 30 June 2026 is not reproduced here because it does not govern Singapore transactions.
What a payment gateway costs instead
When the store rules push you off store billing, you are a merchant taking card payments, and the cost structure changes shape entirely: a percentage plus a fixed cent amount per transaction, with surcharges for cross-border cards and currency conversion. Rates are published per provider and per country, so they are checkable rather than negotiable folklore. Stripe's Singapore pricing page, for example, lists "3.4% + $0.50 per successful transaction for domestic cards", with "0.5% for international cards" and "2% if currency conversion is required" added on top, and "1.3% per successful PayNow transfer" for the local bank rail. Other providers publish their own; the point is that you compare published pages, not sales decks.
Here is what the published rates work out to on a single SGD 100 transaction. This is arithmetic, not a quote from anyone, and the two halves of the table are not alternatives for the same sale — the policy decides which row you are on.
| Rail | Published rate | You receive on SGD 100 (derived) |
|---|---|---|
| Store billing, 15% tier (Apple SBP or Google Play first USD 1M) | 15% | SGD 85.00 |
| Store billing, 30% tier (Google Play above USD 1M) | 30% | SGD 70.00 |
| Apple subscription, year 1, not in Small Business Program | Developer receives 70% | SGD 70.00 |
| Card, domestic (Stripe published SG rate) | 3.4% + SGD 0.50 | SGD 96.10 |
| Card, international (Stripe published SG rate) | 3.4% + 0.5% + SGD 0.50 | SGD 95.60 |
| PayNow (Stripe published SG rate) | 1.3% | SGD 98.70 |
Derived — each figure is straight arithmetic applied to the published rates cited above; no organisation publishes these totals. Amounts are before GST and before any provider-specific dispute, refund or payout fees. Critically, these rows are not interchangeable options: for any given product, Apple's and Google's policies determine which rail is permitted, so this table shows the cost of the rail you are on, not a menu to shop from.
The Singapore layer nobody scopes
Below the store rules sits a licensing question that has nothing to do with Apple or Google, and it is the reason serious builds integrate a regulated provider rather than moving money themselves. The Payment Services Act 2019 is, by its long title, "An Act to provide for the licensing and regulation of payment service providers, the oversight of payment systems, and connected matters". Its Part 2 is headed "LICENSING OF PAYMENT SERVICE PROVIDERS", and the Act's own interpretation section describes an exempt provider as one "exempt under section 13(1) from the requirement under section 5(1) to have in force a licence that entitles the person to carry on a business of providing that payment service" — which tells you plainly that carrying on a payment service business in Singapore is a licensed activity with a defined exemption route, not an open field. The Act also defines "merchant acquisition service" as one of its regulated payment services, with the meaning "given by Part 3 of the First Schedule".
Whether any of that captures your specific app depends on facts a blog post cannot see: whose money you hold, for how long, and on whose behalf. This is general information, not legal advice, and it is exactly the sort of question to put to a qualified adviser early. But the practical engineering consequence is stable regardless of the answer: the design that keeps you furthest from the licensing question is the one where a licensed provider is the party that touches the funds, your app never stores card data, and your servers hold order records rather than balances. If a proposal has your own backend warehousing customer balances or settling between users, that is a business-model decision with a regulatory tail, and it belongs on the agenda before the first sprint rather than in a late change request.
Apps that need both rails
Plenty of Singapore products need both, and the cost of that is almost always under-scoped. Take a fitness app that sells physical class bookings and a digital on-demand video tier. The bookings run through a payment service provider; the video tier runs through in-app purchase on iOS and Play billing on Android. That is not one payment feature, it is three integrations, and each brings its own tail: separate refund mechanics, separate receipt validation, separate reconciliation into your accounts, separate handling of failed renewals, and separate test matrices in sandbox before release.
Two design habits keep this manageable. First, model entitlements in your own backend rather than in the store: the app asks your server "may this account watch this video?", and your server is the one that reconciles the answer against an Apple receipt, a Play purchase token or your own subscription record. Change providers later and the app barely notices. Second, keep the two rails visibly separate in the interface, because the moment a screen mixes a class booking and a subscription upsell you are one layout change away from a call to action the anti-steering rules do not permit. Both habits cost a little more in week two and save a re-architecture in month six.
What this changes in your build budget
Payments is one of the clearest examples of scope moving a project between tiers. Our published starting points on the Namtech pricing page are SGD 20,000 for a Starter/MVP, SGD 38,000 for a Business app and SGD 90,000 for an Enterprise platform, and payment complexity is one of the things that moves an app up the list — a single card checkout is a different piece of work from dual-rail billing with entitlement sync, refunds and reconciliation. We scope which rails your product legally requires during the scoping call, so the quote reflects the integrations you actually need rather than a placeholder line called "payments".
Budget for the operational tail as well. Store rules and provider rates are revised — Google has already published a schedule change effective 30 June 2026 for the EEA, UK and US — so someone has to be watching the policy pages that govern your revenue. That work lives in maintenance and support, which we publish from 15% of build cost per year, alongside monitoring, OS-version updates and security patches. It is unglamorous and it is the difference between reading about a rate change and discovering one.
Questions to ask before you sign anything
- For each thing we sell, which rail is required? Ask for the answer item by item against Apple 3.1.1 / 3.1.3 and Google's Payments policy — not a blanket "we will use Stripe".
- Does any screen steer users to an outside payment method? Include sign-up and account-creation flows, which Google's policy names explicitly.
- Where do entitlements live? If the answer is "in the store", ask what happens when you add the second platform or change provider.
- Who touches the money? If the design has your backend holding or settling funds, get advice on the Payment Services Act 2019 position before building.
- What are the refund and dispute flows on each rail? Store refunds and card chargebacks are different processes with different evidence requirements.
- Which published pages are we relying on, and who re-checks them? Rates and policies have dates; your model should record them.
Before you argue about the commission rate, confirm which rail the store obliges you to use — because for most Singapore apps selling real-world goods and services, Apple and Google forbid store billing entirely, and the 30% figure everyone budgets for never applies.
Sources
All external rules and rates below are quoted from the organisation that publishes them, retrieved 31 July 2026. Namtech pricing figures are our own published starting points. Nothing here is legal advice.
- Apple — App Store Review Guidelines, section 3.1: 3.1.1 In-App Purchase ("you must use in-app purchase"; no "license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets"), 3.1.3 chapeau (no in-app encouragement of other purchasing methods outside the US storefront), 3.1.3(c) Enterprise Services, 3.1.3(d) Person-to-Person Services ("One-to-few and one-to-many real-time services must use in-app purchase"), 3.1.3(e) Goods and Services 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").
- Apple — App Store Small Business Program: "It features a reduced commission rate of 15% on paid apps and In-App Purchases"; "Existing developers who made up to 1 million USD in proceeds in the prior calendar year for all their apps, as well as developers new to the App Store, can qualify"; "If a participating developer surpasses the 1 million USD threshold in the current calendar year, the standard commission rate will apply to future sales."
- Apple — Auto-renewable subscriptions: "During a subscriber's first year of service, you receive 70% of the subscription price at each billing cycle, minus applicable taxes. After a subscriber accumulates one year of paid service, your net revenue increases to 85% of the subscription price, minus applicable taxes."; Small Business Program members "receive 85% of the subscription price at each billing cycle (minus applicable taxes), regardless of whether or not the subscription has accumulated one year of paid service."
- Google — Payments (Play Console Help): apps accepting payment for in-app features, functionality, digital content or goods "must use Google Play's billing system for those transactions"; "Google Play's billing system must not be used in cases where: payment is primarily: for the purchase or rental of physical goods (such as groceries, clothing, housewares, electronics); for the purchase of physical services (such as transportation services, cleaning services, airfare, gym memberships, food delivery, tickets for live events)"; anti-steering: "apps may not lead users to a payment method other than Google Play's billing system", including via "In-app user interface flows, including account creation or sign-up flows".
- Google — Service fees (Play Console Help): "For all remaining markets until the announced updated service fees are rolled out globally" — "15% for the first $1M (USD) revenue earned by the developer each year", "30% for earnings in excess of $1M (USD) revenue earned by the developer each year", and subscriptions at "15% ... regardless of revenue earned by the developer each year"; also "97% of developers distribute their apps and take advantage of all Google Play has to offer at no charge" and the separate EEA/UK/US schedule "starting June 30, 2026".
- Singapore Statutes Online — Payment Services Act 2019: long title, "An Act to provide for the licensing and regulation of payment service providers, the oversight of payment systems, and connected matters"; Part 2 "LICENSING OF PAYMENT SERVICE PROVIDERS"; interpretation of "exempt payment service provider" as a person "exempt under section 13(1) from the requirement under section 5(1) to have in force a licence that entitles the person to carry on a business of providing that payment service"; "merchant acquisition service" defined by "Part 3 of the First Schedule".
- Stripe — Pricing (Singapore): "3.4% + $0.50 per successful transaction for domestic cards"; "+ 0.5% for international cards"; "+ 2% if currency conversion is required"; "1.3% per successful PayNow transfer". Quoted as one provider's published rates for illustration; not an endorsement and not a Namtech rate.
- Namtech — Pricing: SGD 20,000 / 38,000 / 90,000 published starting points; "Maintenance & Support — from 15% of build cost per year".