How to Add Direct Billing to Your iOS App Without Rebuilding Your Payment Stack
Summary
- Switching from Apple's 30% In-App Purchase fee to direct billing can save you $245,000 annually for every $1M in revenue.
- The Epic v. Apple ruling permanently allows US developers to offer direct billing, making it a fully compliant way to bypass high commissions.
- You can add direct billing to your app in an afternoon without rebuilding your existing StoreKit integration.
- Allocents offers a drop-in SDK that handles the entire process, from a 15-minute setup to gradual rollouts and user migration campaigns.
You've poured months into building your iOS app. You've nailed the product, grown your subscriber base, and crossed $1M in ARR. Then you look at your Stripe dashboard and feel the gut punch: Apple just took $300,000 of that. And there's nothing you could do about it — until now.
The April 2025 Epic v. Apple ruling permanently barred Apple from forcing US developers to use its In-App Purchase (IAP) system. For the first time, you can offer direct billing inside your iOS app, legally, in the US. But if you've been hovering over the "take action" button and feeling paralyzed — is this compliant? Will I get rejected? Do I need to rebuild my entire mobile app payment processing stack? — this guide is for you.
The short answer: no, you don't need to rebuild anything. You can go from zero to a live direct billing rollout in a single afternoon. Here's exactly how.
The $245,000 Question: Quantifying the Post-Epic Opportunity
Let's start with the math, because it's genuinely staggering.
At $1M ARR on Apple IAP, you're handing Apple $300,000 a year — Apple's standard 30% commission. That's not a rounding error. That's a salary, a marketing budget, or a full engineering hire, gone.
Now look at what direct billing changes:
| Before (Apple IAP) | After (Direct Billing) | |
|---|---|---|
| Gross Revenue | $1,000,000 | $1,000,000 |
| Platform Fee | -$300,000 (30%) | -$55,000 (~5.5%) |
| Your Net Revenue | $700,000 | $945,000 |
That's $245,000 back in your pocket — annually, from the same revenue base, with the same users.
As Forbes noted, the ruling has unlocked more than $150 billion in annual IAP volume for potential disruption. The developers who move early capture the most upside.
Want to see your personal savings number? Contact us to calculate your savings →
Your Afternoon Integration Plan: 5 Steps to Direct Billing
This walkthrough uses Allocents to illustrate the process. Allocents provides a single SDK that enables mobile app developers to offer direct billing alongside or instead of Apple's StoreKit, with a 15-minute integration. It's the most direct path from "interested" to "live" for mobile app payment processing on iOS.
Step 1: Install the SDK (~15 minutes)
The biggest fear most developers have is that adding direct billing means ripping out StoreKit and rebuilding from scratch. It doesn't. You're adding a layer on top of what you already have.
Allocents ships a single SDK supporting Swift/SwiftUI, Kotlin, Flutter, and React Native. For iOS, install it via Swift Package Manager:
- In Xcode, go to
File > Add Package Dependencies... - Enter the repository URL:
https://github.com/allocents/AllocentsKit - Select the
AllocentsKitlibrary and add it to your app target.
Then configure it in your app lifecycle:
import AllocentsKit
// In your AppDelegate or SwiftUI App struct
Allocents.shared.configure(.init(
publishableKey: "pk_live_your_key",
environment: .production,
syncStoreKitTransactions: true
))
That's it. You haven't touched your existing StoreKit implementation. You've just added an intelligent layer that can intercept, route, and present direct billing flows when appropriate.
Step 2: Sync Your StoreKit Products (Automatic)
One of the biggest operational headaches developers dread is managing products in two separate systems — App Store Connect on one side, a new billing provider on the other. Prices drift. Product IDs get out of sync. It becomes a maintenance nightmare.
Allocents solves this with automatic StoreKit product sync from App Store Connect. The moment the SDK initializes with syncStoreKitTransactions: true, it pulls your existing subscription and consumable products directly. No manual re-entry. No duplicate catalog to maintain. Your App Store Connect setup remains your single source of truth, and Allocents mirrors it automatically, as described in the developer documentation.
Step 3: Configure a Gradual, Risk-Free Rollout (~5 minutes)
Here's where the fear of a "big bang" launch gets addressed head-on. You do not need to flip a switch and expose 100% of your users to a direct billing flow on day one. In fact, you shouldn't.
From the Allocents dashboard, set your initial direct billing offer to reach just 10% of your users. This is configured server-side — no code push required, no App Store re-submission. You're essentially running a live test on a small cohort before committing.
If something feels off — say, conversion rates dip or you get unexpected support tickets — you can dial it back to 0% instantly. This mirrors the kind of gradual rollout best practices recommended by industry leaders for any significant paywall change.
Step 4: Launch a "Switch & Save" Campaign (~30 minutes)
Once you're confident in the 10% rollout, it's time to start actively moving your existing subscribers off Apple IAP and onto direct billing. This is where the real revenue recovery happens, and it's more straightforward than it sounds.
Allocents provides pre-built, native-feeling UI flows that don't feel like a pop-up from 2012:
- Switch & Save: A modal that surfaces to existing StoreKit subscribers offering a discount — say, 20% off — to re-subscribe through direct billing. The user gets a better price; you recover the margin spread.
- Sign Up & Save: A paywall for new users that presents both options side-by-side — the App Store price and a lower direct price — and lets the user choose. Transparency without pressure.
Both flows are fully configurable from the dashboard. You can A/B test the discount amount, the copy, the timing (post-session vs. on cancellation intent), and the visual design without shipping a new app version. Think of it as a conversion optimization layer built directly into your mobile app payment processing infrastructure.
Step 5: Monitor Cohort Adoption & Revenue Impact (Ongoing)
The integration isn't done until you can see what's happening. Allocents's analytics dashboard gives you a real-time view into:
- Migration rate: What percentage of your StoreKit subscribers are accepting the Switch & Save offer.
- Cohort adoption: How new users are splitting between App Store and direct billing sign-ups.
- Revenue impact: The actual dollar delta in fees saved, broken down by period.
This is the data you'll use to decide when to expand your rollout from 10% to 25%, to 50%, and eventually to all new users. The decisions are driven by numbers, not gut feel.
Answering Your Toughest Questions
The process above is simpler than most developers expect. But the questions below are valid, and they deserve direct answers.
Q: Is this actually compliant with Apple's rules? Will my app get rejected?
Yes, for US users, this is compliant. The Epic v. Apple injunction explicitly grants developers the right to "include in their apps and their metadata buttons, external links, or other calls to action that direct customers to purchasing mechanisms," as analyzed by Greenberg Glusker. App Review inconsistencies are a real frustration — developers on r/iOSProgramming have documented how "it depends on your reviewer" — but the legal foundation for this practice in the US is now solid and court-enforced.
Q: What happens for my users outside the US, where the Epic ruling doesn't apply?
This is handled automatically. Allocents uses jurisdiction-aware routing — the SDK detects the user's country at runtime. If they're outside a compliant jurisdiction, the SDK silently falls back to the standard StoreKit IAP flow. You don't need separate app builds, conditional logic in your codebase, or manual geo-targeting. One SDK, one integration, the right behavior everywhere.
Q: What if I want to roll back entirely?
You can do it instantly, without a new App Store submission. Because the direct billing offer is controlled by the rollout percentage in your dashboard, setting it to 0% effectively deactivates the feature for all users immediately. This is one of the key reasons a gradual rollout architecture matters — your risk exposure at any point is exactly as large as you choose it to be.
Q: Do I have to become a Merchant of Record and handle taxes, fraud, and chargebacks myself?
You have two paths:
-
Hands-Off (Recommended for most teams): Let Allocents act as your full Merchant of Record. We handle global sales tax remittance across 190+ countries, chargebacks, fraud protection, refunds, and customer support — for a flat 5% + 50¢ per transaction. You get Apple-quality billing infrastructure at a fraction of Apple's price.
-
Full Control (For larger teams): Use our Bring Your Own Stripe (BYOS) mode — connect your own Stripe account, act as your own MoR, and use the SDK for its checkout UI and migration flows. The fee drops to 0.5% of migrated revenue. This is the path for teams that already have payment ops in place and want maximum margin.
Neither path requires you to rebuild your existing payment stack from the ground up.
Stop Leaving $245,000 on the Table
The days of mandatorily forfeiting 30% of your iOS revenue — on every transaction, every month, every year — are over for US developers. The Epic v. Apple ruling created a real, enforceable opening. The tools to act on it exist today.
What's changed is the tooling. A few years ago, acting on this would have meant stitching together a payment processor, a tax solution, a migration flow, and a new paywall — a multi-month engineering project with no guarantee of App Store approval. Today, a single SDK handles all of it, with a 15-minute setup and a gradual rollout that lets you test before you commit.
If your app is doing meaningful revenue on iOS, the conversation has shifted from should I do this? to how long can I afford not to?
Frequently Asked Questions
What is the Epic v. Apple ruling and how does it allow direct billing?
The Epic v. Apple ruling is a US court decision that permanently prevents Apple from forcing developers to exclusively use its In-App Purchase (IAP) system. This means you can now legally include buttons, links, or other calls to action inside your US iOS app that direct users to your own payment systems, thereby bypassing Apple's 30% commission.
How much money can I save by switching to direct billing?
You can save a significant portion of the 30% fee Apple charges, typically recovering around 24.5% of your gross revenue. For an app generating $1,000,000 in annual revenue, switching from Apple's 30% IAP fee to a direct billing provider that charges around 5.5% can put an extra $245,000 back into your business each year.
Is it difficult to add direct billing to an existing iOS app?
No, it is not difficult. Modern solutions like Allocents allow you to add direct billing in as little as 15 minutes using a single SDK, without needing to remove or rebuild your existing Apple StoreKit integration. The process involves adding the SDK to your project, which then works as a layer on top of your current setup and can automatically sync your products from App Store Connect.
Will my app get rejected by Apple if I offer direct payments?
For users in the United States, your app should not be rejected for offering direct payments, as this practice is protected by the Epic v. Apple court injunction. While App Review can sometimes be inconsistent, the legal precedent is firmly established in the US. For users outside the US, a jurisdiction-aware SDK will automatically fall back to the standard Apple IAP flow to ensure compliance.
How do I move my existing subscribers from Apple IAP to my direct billing system?
You can migrate existing subscribers by presenting them with an in-app offer, such as a "Switch & Save" campaign that gives them a discount for re-subscribing directly with you. This is often done using pre-built UI flows that surface a modal offering a better price. The user gets a discount, and you increase your net revenue by avoiding Apple's large commission.
What happens to my international users if I implement direct billing?
Your international users will automatically be shown the standard Apple In-App Purchase flow, ensuring your app remains compliant in regions where the Epic v. Apple ruling does not apply. Modern SDKs use jurisdiction-aware routing to detect a user's country and default to using StoreKit where required, with no extra coding needed from you.
Do I have to handle sales tax and fraud myself with direct billing?
No, you do not have to handle it yourself. You can use a Merchant of Record (MoR) service, like the one offered by Allocents, which manages all global sales tax, fraud, chargebacks, and compliance for you. An MoR service acts as the seller on your behalf, taking on the operational burden of payment processing for a simple fee.