
The April 2025 Epic v. Apple ruling permanently barred Apple from forcing US developers to use its In-App Purchase system, unlocking access to $150B+ in annual IAP volume — and your app's revenue is now yours to keep. This guide walks you through implementing an iOS direct billing SDK in under 15 minutes, so you can stop paying the 30% Apple tax and start keeping more of what you earn.
But first, let's name the elephant in the room. Until now, you've been stuck between two bad options: pay the 30% IAP fee to Apple for the smooth StoreKit experience, or save on fees by using web checkout and "sacrifice the UX by forcing users into a janky Safari redirect that kills conversion." And if you tried to go it alone, you're suddenly on the hook for handling chargebacks, managing recurring billing, and figuring out Slovenian VAT — all by yourself.
A new generation of single-SDK solutions like Allocents—which acts as your full Merchant of Record—gives you the best of both worlds: lower fees and a native-feeling checkout that doesn't tank your conversion rate. Let's walk through the implementation.
Before you write a single line of code, make sure your in-app purchases are configured in App Store Connect. One legitimate concern developers have is that switching to direct billing means "you won't be defining purchasable items in Apple's servers" — but with Allocents, that's not a problem.
The Allocents SDK automatically syncs with your existing App Store Connect product catalog. Your existing product identifiers — pro_monthly, 100_gems, annual_premium, whatever you've already set up — work out of the box. No manual recreation, no duplicated catalog management.
Adding the SDK follows the exact same flow as any other Swift package. In Xcode:
https://github.com/allocents/AllocentsKitAllocentsKit to your app's main target and click Add PackageThat's it for Swift. If you're a Flutter developer, add the package from the command line:
// Flutter
flutter pub add allocents
This is the most important step from a UX perspective. The .acPaymentSheet modifier presents a native sheet — not a web view, not a Safari redirect. To your users, it feels exactly like a standard StoreKit prompt.
import AllocentsKit
struct PaywallView: View {
@State private var showCheckout = false
// Fetched via Allocents.shared.product(for: "pro_monthly")
let product: ACProduct
let user: YourUserType
var body: some View {
Button("Upgrade to Pro") {
showCheckout.toggle()
}
// Presents a native checkout UI — no Safari redirect
.acPaymentSheet(isPresented: $showCheckout, product: product, userId: user.id) { result in
switch result {
case .success(let transaction):
// Purchase successful — unlock content
print("Purchase successful: \(transaction.productId)")
unlockContent(transaction.productId)
case .failure(let error):
// Handle the error gracefully
print("Purchase failed: \(error.localizedDescription)")
showError(error)
}
}
.onAppear {
Allocents.shared.configure(publishableKey: "ac_live_...")
}
}
}
And for Flutter, the flow is equally clean:
import 'package:allocents/allocents.dart';
import 'package:flutter/material.dart';
class PaywallScreen extends StatelessWidget {
@override
Widget build(BuildContext context) {
// Configure once when your app initializes
Allocents.configure('ac_live_...');
return ElevatedButton(
onPressed: () async {
try {
// Fetch from the synced App Store Connect catalog
final product = await Allocents.product('pro_monthly');
// Present the native checkout flow
final result = await Allocents.checkout(product);
print("Checkout successful: ${result.productId}");
} catch (e) {
// Handle error or user cancellation
print("Checkout failed: $e");
}
},
child: Text('Upgrade to Pro'),
);
}
}
Now for the part that used to keep developers up at night: "handling chargebacks from credit card companies, handling recurring billing for subscriptions, and figuring out Slovenian taxes." You have two options here depending on your team's size and infrastructure.
Option 1: Allocents Billing (Full Merchant of Record)
This is the "Apple-like" experience, minus the 30% fee. Allocents acts as your Merchant of Record, handling global tax remittance across 190+ countries, fraud protection, chargebacks, and customer support. You get a clean payout. The fee is 5% + 50¢ per transaction.
Option 2: Bring Your Own Stripe (BYOS)
If your team already has a Stripe account and wants to manage MoR responsibilities in-house, BYOS lets you connect your existing Stripe account and retain full control over your payment stack and customer data. The fee is just 0.5% of direct billing revenue — only on revenue Allocents' offers successfully migrate.
Both modes are configured at SDK initialization:
// Allocents Billing (Full MoR — recommended for most teams)
Allocents.shared.configure(.init(
publishableKey: "pk_live_your_key",
environment: .production,
syncStoreKitTransactions: true // Enables migration tracking in the dashboard
))
For BYOS, you connect your Stripe account directly in the Allocents dashboard — no additional code changes required in your app.
This is the most common question, and the answer for US apps is clear: no. The permanent injunction from the Epic v. Apple ruling legally prevents Apple from rejecting apps that direct users to external payment options in the United States. The "App Review process is insanely hit or miss" anxiety that developers have lived with for years has a legal answer now.
That said, the rules differ by region — and this is where jurisdiction-aware routing becomes your compliance safety net. Allocents' SDK automatically detects the user's region and only surfaces the direct billing option in legally permitted jurisdictions like the US. In every other region, the SDK falls back seamlessly to StoreKit. You don't have to manage this logic yourself.
The concern is completely valid — "I'm just starting to see these apps first hand with the external purchase workflow and it's a disappointment for sure." That reaction is entirely fair when the "external purchase flow" means bouncing users out to Safari and hoping they don't abandon.
But that era is over. As the code above demonstrates, modern iOS direct billing SDKs use native UI components (.acPaymentSheet) that present checkout as a sheet inside your app — supporting Apple Pay and Google Pay — with no browser redirect in sight. Users don't feel like they've left your app, because they haven't.
Beyond UX parity, direct billing actually opens up conversion levers that StoreKit simply doesn't allow. With Apple's 30% cut, there's no margin to offer a meaningful "Sign Up & Save" discount to nudge a hesitant user over the line. At 5% + 50¢, you can offer 20–30% off direct billing vs. the App Store price and still come out ahead. That's a conversion lever that didn't exist before.
You don't have to flip a switch overnight and migrate your entire user base on day one. Allocents' dashboard includes a gradual rollout toggle — a simple percentage slider that controls what proportion of your US users see the direct billing option.
Start at 10%. Watch the analytics dashboard track migration rates, cohort adoption, and revenue impact in real-time. If everything looks good, scale to 25%, then 50%, then 100% at your own pace. If anything looks off, roll it back to 0% instantly — no app update, no App Store review cycle required.
This single feature removes the biggest operational risk of the migration. You're not betting your entire revenue stream on a cold launch — you're running a controlled experiment with a killswitch.
The legal landscape has changed, and the tooling has finally caught up with it. Implementing direct billing on iOS is no longer a risky, complex project that forces you to choose between paying Apple's 30% fee and shipping a broken checkout experience.
With a single iOS direct billing SDK, you can:
The combination of the Epic v. Apple ruling and purpose-built SDKs like Allocents means there's never been a better time to stop leaving money on the table.
Direct billing for iOS apps is a method that allows developers to process payments for in-app purchases through third-party providers, bypassing Apple's In-App Purchase (IAP) system. This became permissible in the US following the Epic v. Apple court ruling and lets developers avoid Apple's 30% commission by integrating an SDK, like Allocents, that handles transactions directly while maintaining a native in-app checkout experience.
Yes, for apps distributed in the United States, it is legal to use direct billing and offer external payment options. A permanent injunction from the Epic v. Apple ruling prevents Apple from rejecting US apps that use alternative payment systems. For other regions, SDKs like Allocents automatically use Apple's standard IAP to ensure full compliance with local App Store policies.
Modern direct billing SDKs are designed to provide a seamless, native user experience that does not disrupt the checkout flow. Unlike early solutions that forced users into a web browser, SDKs like Allocents use native UI components (e.g., a payment sheet) that appear directly within your app. This supports familiar options like Apple Pay, ensuring the checkout process feels just as smooth as using Apple's default StoreKit and helping maintain high conversion rates.
The direct billing option will not be shown; the user will see the standard Apple In-App Purchase flow instead. Purpose-built SDKs like Allocents include jurisdiction-aware routing that automatically detects the user's region. It only presents the direct billing option where it is legally permitted, such as in the US. In all other countries, the SDK seamlessly falls back to using StoreKit, ensuring your app remains compliant everywhere.
No, you do not need to manage a separate product catalog. The Allocents SDK automatically syncs with your existing product catalog configured in App Store Connect. This means all your current product identifiers, pricing, and subscription details work out of the box without requiring manual duplication or extra management.
The fees are significantly lower than Apple's 30%, typically around 5% + 50¢ per transaction. Allocents offers a full Merchant of Record service for this fee, which includes handling all taxes, fraud, and chargebacks. For teams with their own Stripe account, the "Bring Your Own Stripe" (BYOS) option has a fee of just 0.5% of the revenue migrated through the platform.
A Merchant of Record is the entity legally responsible for processing customer payments, including handling tax remittance, managing fraud, and dealing with chargebacks. When you use Apple's IAP, Apple acts as the MoR. By using a direct billing provider like Allocents that also acts as your MoR, you offload all these complex financial and legal responsibilities, saving you from managing global sales tax and payment disputes yourself.
You can switch safely by using a gradual rollout feature that allows you to test and monitor the new system with a small percentage of users first. Platforms like Allocents provide a dashboard with a simple slider to control what percentage of your US user base sees the direct billing option. You can start with 10%, analyze the conversion and revenue data, and gradually increase the percentage as you gain confidence, de-risking the migration.
Ready to ship? Here's where to go next: