In-App Purchase or Payment Gateway? Integration Guide

In-app purchase is mandatory whenever your app unlocks digital content, features or subscriptions, and Apple and Google take 15-30% of those sales. When you sell physical goods or services consumed outside the app, store commission is 0% — you must use a payment gateway such as Stripe, or iyzico and PayTR in Turkey.

Teams that miss this distinction pay for it twice. Some ship a subscription app wired to a card gateway and get rejected in review. Others bolt in-app purchase onto an e-commerce app that sells physical products and hand roughly a third of their revenue to a store that never required it.

The money at stake is not small. Business of Apps puts combined iOS and Android consumer spending at $166.8 billion in 2025, with iOS accounting for 70% of it and subscription revenue reaching $79.5 billion (App Revenue Data).

Every rule below comes from Apple's and Google's own developer documentation, and every rate from their published fee tables. Figures are current as of September 2026.

Table of Contents

• Store Billing or Payment Gateway? Start With What You Sell
• Apple and Google Rules: When In-App Purchase Is Mandatory
• Commission Rates: Stores Versus Payment Gateways
• The Regional Split: US, EU and Everywhere Else
• Selling in Turkey: Gateways, Wallets and 3D Secure
• Technical Integration: Server-Side, WebView and Receipts
• Subscriptions: In-App Purchase or Web Checkout?
• Seven Mistakes That Break Payment Integrations
• Cost and Timeline: What to Budget
• Frequently Asked Questions

Store Billing or Payment Gateway? Start With What You Sell

There are two ways to take money inside a mobile app, and they are not interchangeable. What you sell decides which one applies — not your preference, and not your developer's.

In-app purchase (IAP). Apple or Google collects the money. The user has a card on file with the store, so checkout is a single tap. Your payout arrives net of commission on the store's schedule, and in most countries the store handles invoicing and sales tax as merchant of record.

Payment gateway. You collect the money. Card details flow through Stripe, Adyen, iyzico, PayTR or your bank's virtual POS, and funds settle into your own merchant account. Refunds, instalments, invoicing and chargebacks are yours to manage.

The difference goes beyond the fee. In-app purchase converts better because nobody types a card number. A gateway gives you control over pricing, promotions, instalments and customer data — and in markets like Turkey, instalment payments are not a nice-to-have.

The decision rule fits in one line: if the thing being bought is consumed inside the phone, use in-app purchase; if it is consumed outside the phone, use a gateway.

Apple and Google Rules: When In-App Purchase Is Mandatory

Both companies publish the rule, so there is nothing to guess at.

Apple's App Review Guidelines section 3.1.1 states: "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." The same section bans workarounds — licence keys, QR codes, cryptocurrency — and restricts digital gift cards to in-app purchase only.

Section 3.1.3(e) points the other way: "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." Adding IAP to a retail app is not merely wasteful; it breaks the guideline.

Google's Payments policy draws the same line. Play's billing system is required for in-app purchases (virtual currencies, extra lives, add-on items, characters), subscription services (fitness, games, dating, education, music, video), app functionality or content such as an ad-free version, and cloud software services like storage or productivity tools.

Google's exemption list is explicit: physical goods and rentals (groceries, clothing, housewares, electronics), physical services (transportation, cleaning, airfare), credit card and utility bill payments, peer-to-peer payments, online auctions, and tax-exempt donations.

Apple's less-publicised carve-outs decide a surprising number of product roadmaps:

Read 3.1.3(d) literally, because reviewers do. A one-to-one live tutoring session can be billed through a gateway. The same lesson sold as a recording cannot — Apple writes that "one-to-few and one-to-many real-time services must use in-app purchase."

Commission Rates: Stores Versus Payment Gateways

Outside the US and the EU — which covers Turkey and most of the world — these are the rates in force as of September 2026:

Apple's Small Business Program threshold is $1 million in proceeds in the prior calendar year, and proceeds from all associated developer accounts are combined. Cross the threshold mid-year and you move to 30% for the rest of it; fall back below and you can re-qualify the following year.

On subscriptions Apple frames the same maths as revenue share rather than commission: you receive 70% of the subscription price during a subscriber's first year, rising to 85% after a subscriber accumulates one year of paid service. Google's service fee table sets subscriptions at 15% from day one in these markets.

The gap matters most at scale. A digital subscription app billing $100,000 a month through IAP under the Small Business Program pays $15,000 in commission. The same $100,000 in physical goods through a gateway at 2.5% costs $2,500. Six times the difference — decided by product category, not by negotiation.

The Regional Split: US, EU and Everywhere Else

Store economics are being rewritten, but unevenly. Treat the three blocs separately or you will plan around rules that do not apply to your market.

United States. Apple's own guideline now says the external purchase link entitlements "are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps." The commission question is still open: the Supreme Court granted Apple's petition on 30 June 2026 in Apple Inc. v. Epic Games (No. 25-1311), limited to the first question presented, and as of late September 2026 the case remains in merits briefing with no argument date (Supreme Court docket).

European Union. Apple updated the Developer Program License Agreement on 18 August 2026, and unified EU business terms take effect on 1 October 2026 (Apple's DMA page). The new structure:

• 26% commission on sales processed by Apple in-app purchase; 15% for Small Business Program, Mini Apps Partner Program and Video Partner Program members, and for auto-renewable subscriptions after year one.
• 20% on sales processed through alternative payment processing inside the app; 10% at the reduced tier.
• 15% on out-of-app offers, applied only to sales completed within seven days of the link tap; 10% at the reduced tier.
• The per-install Core Technology Fee is replaced by a 5% Core Technology Commission on digital transactions in apps distributed outside the App Store. The Initial Acquisition Fee and Store Services Fee are eliminated.

Two operational details are easy to miss: developers must keep their chosen payment options in place for 12 months, and when an alternative payment provider processes the sale, you become responsible for collecting and remitting tax and for sending Apple a monthly transaction report within 15 days of month end. Google runs a separate fee schedule for the EEA, UK and US that has applied since 30 June 2026.

Everywhere else. None of the above applies. In Turkey, Brazil, the Gulf, most of Asia and Africa the classic rules still hold: IAP mandatory for digital goods, 30% or 15%, and no in-app links to outside payment. Apple's 3.1.1(a) is unambiguous that in every storefront except the US, "apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase."

Selling in Turkey: Gateways, Wallets and 3D Secure

Turkey is worth a section of its own, both because it is a large mobile commerce market and because several defaults you would assume from the US or EU simply do not hold.

The market is growing fast. The Ministry of Trade's ETBİS data puts 2025 e-commerce volume at 4.57 trillion lira, up 52.2% year on year, with retail e-commerce at 2.46 trillion lira (Turkey's E-Commerce Outlook Report 2025). Cards account for 62.5% of that volume, bank transfers 29.2%, cash on delivery 3.5%.

Three constraints shape any integration there:

Stripe does not operate in Turkey. Turkey is absent from Stripe's list of supported countries as of September 2026, so a Turkish-registered company cannot open a Stripe account directly. Local gateways — iyzico, PayTR, or a bank virtual POS — are the practical route, and they also accept foreign-issued cards. Our payment gateway fees in Turkey guide breaks down the rate bands and the central bank caps.

Apple Pay is unavailable; Google Pay is not. Turkey does not appear in the Apple Pay country list on Apple's own feature availability page, while Google lists Turkey among the countries where Google Pay works on participating websites and apps. In practice iOS users must type card details into your checkout while Android users can tap once — which makes saved cards and tokenisation a higher priority on iOS than most teams expect.

3D Secure is a legal requirement. Article 27/A(7) of Turkey's Regulation on Bank Cards and Credit Cards requires acquirers and merchants to build card infrastructure that includes 3-D Secure, or cardholder authentication technology meeting at least the same protections, for cardholder-initiated internet transactions — and to observe PCI DSS when processing, storing or transmitting that data. Mandating it on every transaction is left to the merchant, and the market takes that latitude: 64.1% of card-based e-commerce transactions in 2025 used 3D Secure, per the same ETBİS report. On the remaining third, the chargeback sits with the merchant.

One more legal point that catches product teams: providing payment services in Turkey requires authorisation from the central bank under Law No. 6493. If your roadmap includes wallet balances, user-to-user transfers or collecting on behalf of third-party sellers, that is a licensing question before it is an engineering one.

Technical Integration: Server-Side, WebView and Receipts

Expect the architecture of a local gateway integration to look different from a Stripe integration, because the tooling is different.

iyzico's official documentation lists Checkout Form, a 3DS API, subscriptions, marketplace (sub-merchant) flows, card storage and pre-authorisation. Its "Platforms" section covers WooCommerce, OpenCart, PrestaShop, Magento, IdeaSoft, Ticimax, ikas, T-Soft, Shopify, WIX and nopCommerce — all e-commerce plugins. There is no native iOS or Android SDK in the documentation index. PayTR's common path is its iFrame API, where your server requests an iframe_token and the app renders the hosted form.

So the working pattern looks like this:

1. Server-side session. Your backend, never the app, calls the gateway and receives a token. API keys stay on the server — APK and IPA files are trivially unpacked.
2. Hosted payment screen. The app opens the tokenised form in a WKWebView or SFSafariViewController on iOS, or Custom Tabs on Android. Card data never touches your app's memory, which keeps your PCI DSS scope small.
3. 3D Secure redirect. The issuer's challenge page loads in the same web view and returns to the app through a deep link.
4. Server-to-server confirmation. Treat the gateway's webhook — not the message coming back from the client — as the source of truth for a completed payment. Skipping this is the single most common way payment flows get manipulated.
5. Idempotent order handling. Webhooks get retried. Without deduplication keyed on the order reference, retries produce double charges and duplicate orders.

In-app purchase follows the same principle: validate receipts on your server using the App Store Server API or the Play Developer API, never on-device. On Android, watch the library timeline as well — Google requires that, as of 31 August 2026, all new apps and updates use Play Billing Library version 8 or later, with extensions available until 1 November 2026. Apps already published on older versions keep working; you simply cannot ship updates.

Security review deserves its own pass before launch. We covered threat modelling, key storage and data handling in our guide to mobile app security.

Subscriptions: In-App Purchase or Web Checkout?

For a SaaS or content app this is the most expensive decision on the board.

Sell the subscription inside the app and IAP is mandatory at 30% in year one. The alternative is selling on the web and shipping the app as a sign-in client. That is legitimate, and plenty of large subscription businesses run exactly this model — but it comes with a hard boundary outside the US.

What you can do:

• Sell on your website and let the app authenticate existing subscribers, which is the logic behind guideline 3.1.3(f).
• Tell your existing users about other purchase options outside the app. Apple states this plainly: "Developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase."
• Sell directly to organisations under the enterprise carve-out in 3.1.3(c).

What you cannot do, in any storefront except the US, is put a link, a button or a nudge inside the app pointing at your web checkout. This is a leading cause of rejection — see our roundup of common App Store rejection reasons for the rest.

If you are still choosing a revenue model rather than an integration, our comparison of app monetization models sets out the trade-offs between subscriptions, advertising, freemium and transaction fees.

Seven Mistakes That Break Payment Integrations

1. Selling digital subscriptions through a card gateway. Guaranteed rejection. Classify the product first.
2. Adding in-app purchase to a physical goods app. A guideline violation and a needless 30% haircut.
3. Trusting the client for payment confirmation. Always confirm server-side, via webhook or receipt validation.
4. Shipping API keys inside the binary. Mobile packages are not a secret store.
5. Writing non-idempotent webhook handlers. Retried callbacks become double charges.
6. Leaving refunds until after launch. Refund and cancellation flows are consumer-law obligations, not backlog items.
7. Depending on a single provider. One gateway outage stops all revenue; design the second route into the architecture from day one.

Cost and Timeline: What to Budget

Payment work is a line item inside an app project, not a separate product. Rough effort for an experienced team:

Across a full build this usually lands between 8% and 15% of total project cost. To size your own project, run the numbers through our app cost calculator, and work through the app launch checklist before you submit to review.

Where the build happens changes the arithmetic too. If you are weighing an offshore team, our guide to outsourcing software development to Turkey covers rates, time zones and contracting.

Frequently Asked Questions

What is the in-app purchase commission in 2026?

Apple and Google both charge 30% as standard in most markets, dropping to 15% for developers earning under $1 million a year. Google charges 15% on subscriptions from day one; Apple charges 30% in a subscriber's first year and 15% after they accumulate one year of paid service. In the EU, Apple's rate becomes 26% for in-app purchase from 1 October 2026.

When can I use Stripe or another gateway instead of in-app purchase?

Whenever you sell physical goods, or services consumed outside the app — transport, cleaning, food delivery, ticketing, real-time one-to-one services. In those categories Apple's guideline 3.1.3(e) actually requires a payment method other than in-app purchase, and Google exempts them from Play billing.

Can I link users from my app to my website to pay?

Only in the US storefront, where Apple no longer requires an entitlement for external purchase links. In every other storefront, links, buttons and calls to action pointing to alternative purchase methods are prohibited inside the app. Communicating with your existing users outside the app is allowed everywhere.

Does Stripe work in Turkey?

No. Turkey is not on Stripe's supported countries list as of September 2026, so a Turkish-registered company cannot open an account directly. Local options such as iyzico, PayTR and bank virtual POS products handle both domestic and foreign-issued cards.

Is 3D Secure mandatory for mobile payments in Turkey?

The Regulation on Bank Cards and Credit Cards requires merchants and acquirers to implement 3-D Secure infrastructure for cardholder-initiated internet transactions. Enforcing it on every individual transaction is the merchant's choice, but skipping it shifts chargeback liability entirely onto the merchant.

Can I offer Apple Pay in my app in Turkey?

No. Turkey is not listed among the Apple Pay countries on Apple's feature availability page, so Turkish users cannot pay with Apple Pay. Google Pay is available in Turkey, so Android users can check out with a single tap if your gateway supports it.

How long does payment integration take?

A single gateway with one-time payments typically takes 3-6 working days. Adding saved cards, instalments and subscription handling pushes it to two to four weeks. Marketplace models with sub-merchant onboarding and payout splits run 10-20 working days.

Can I offer instalment payments through in-app purchase?

No. Neither Apple nor Google supports local credit card instalment plans inside their billing systems. Instalments are only possible through a local gateway, which is a decisive factor in markets like Turkey where a large share of card purchases are split into instalments.

Payment integration is the part of an app that gets written last and needs to be decided first. Settle the product classification on day one: if what you sell is digital, budget the store commission and price accordingly; if it is physical or consumed off-device, put the gateway, 3D Secure and the instalment table at the centre of the architecture rather than bolting them on.

Teams that defer this decision usually end up rewriting working code. If you want a second opinion on your payment architecture, take a look at our mobile app development service or get in touch with the scope of your project.