Paddle vs RevenueCat vs ZeroSettle for iOS External Billing

Summary

• Stacking Paddle and RevenueCat to bypass Apple's 30% commission introduces significant operational complexity, including managing two SDKs, fragmented user data, and stacked platform fees.
• The biggest challenge with the two-tool approach for established apps is the lack of a unified migration path for existing StoreKit subscribers, requiring custom engineering that risks revenue loss and user churn.
• Allocents offers a single SDK that replaces both tools, providing a full Merchant of Record, native iOS checkout flows, and a controlled migration engine to help mobile-first apps reclaim revenue safely.

Your iOS app just crossed $1M ARR. The Epic v. Apple ruling has permanently unlocked the door to app store external payment options in the US, and you're finally serious about reclaiming some of that 30% Apple tax. You've heard of Paddle. You've heard of RevenueCat. Someone on Reddit told you to use both. But now you're staring at two sets of documentation, two billing relationships, and a migration problem nobody warned you about.

As one developer put it on r/iOSProgramming: "payments are much more complicated than people usually expect and Apple handles most of that for you." That's the honest truth — and it's exactly why picking the right stack from day one matters enormously.

This article runs an honest head-to-head comparison of Allocents, Paddle, and RevenueCat across five dimensions that scaled iOS apps actually care about:

1. iOS SDK Native Feel
2. StoreKit Migration Support
3. Merchant of Record (MoR) Scope
4. Fee Breakdown at Scale
5. Setup Time

By the end, you'll know exactly which stack fits your situation — and where the hidden operational costs are buried.

Why Developers Stack Paddle + RevenueCat (And Where It Breaks)

After the Epic v. Apple ruling paved the way for external payment links, developers exploring external billing quickly land on the same two-tool answer: Paddle for payments, RevenueCat for subscription management.

Here's the logic. Paddle acts as a full Merchant of Record (MoR) — meaning they handle global sales tax, chargebacks, fraud, and compliance across jurisdictions. This is the stuff Apple used to quietly absorb for you. RevenueCat's own integration page describes this neatly: Paddle manages "global taxes, chargebacks, and compliance" while RevenueCat becomes the "unified source of truth" for user entitlements and subscription data.

It sounds clean in theory. In practice, it creates three serious friction points:

1. Two separate integrations. You're maintaining two SDKs, two sets of API keys, and two backend event streams. As developers note, using an external payment mechanism introduces "a slew of new development, logic, and UI requirements that aren't going to be a problem if you just use StoreKit2." (Source)

2. Fragmented billing and user data. A user's payment lives in Paddle. Their entitlement status lives in RevenueCat. Keeping these perfectly synced is a non-trivial ongoing responsibility — "you need to make sure your mobile app is aware of changes in the status of that payment later." (Source) What happens when a chargeback fires in Paddle and RevenueCat doesn't catch it fast enough? Your user keeps accessing paid content. That's a real revenue leak.

3. No unified StoreKit migration flow. This is the dealbreaker for established apps. You have thousands of paying subscribers on Apple IAP right now. How do you safely move them to direct billing without their subscriptions lapsing, without confusing them, and without a mass churn event? The Paddle + RevenueCat stack has no cohesive answer to this. RevenueCat's migration docs focus on migrating subscription data to RevenueCat — not migrating a user's payment method from Apple to an external processor. That's a completely different problem, and it requires significant custom engineering to solve safely.

Head-to-Head: Five Dimensions That Matter

1. iOS SDK Native Feel

Allocents was built from the ground up as a mobile-first, native iOS experience. Its single SDK ships with pre-built UI flows — Sign Up & Save paywalls that let users choose between App Store billing and a discounted direct option, embedded payment sheets with native Apple Pay, and Switch & Save campaigns that prompt existing StoreKit subscribers to migrate. No web redirects. No jarring context switches. The checkout feels like it belongs in your app.

Paddle provides an SDK, but the checkout experience typically surfaces as a hosted web view — functional, but a noticeable seam in an otherwise native app. For mobile-first apps, this matters: developers consistently report that "conversion is a lot lower with external payments," (Source) and a web paywall transition is one of the primary culprits.

RevenueCat offers excellent native paywall templates for its own UI layer — but it's not a payment processor. The moment a user taps "Subscribe," they're handed off to Paddle's web checkout. The hand-off is the friction point, and no amount of RevenueCat polish eliminates it.

2. StoreKit Migration Support

This is where the Paddle + RevenueCat stack falls apart most visibly for established apps.

Allocents treats StoreKit migration as a core product feature, not an afterthought. It automatically syncs your existing products from App Store Connect, then lets you roll out direct billing to a configurable percentage of users — start at 10%, monitor your migration rate and revenue impact on the analytics dashboard, then scale up. If something goes wrong, you can roll back instantly. This is the kind of controlled, data-driven migration that protects your paying subscriber base instead of gambling with it.

Paddle + RevenueCat has no equivalent unified flow. Migrating an existing StoreKit subscriber means cancelling their Apple subscription server-side, enrolling them in Paddle, and ensuring their entitlements never lapse in RevenueCat — all while handling edge cases like users who cancel mid-migration or reinstall the app. This is complex, custom server-side logic that takes weeks to build correctly. And for context, even the internal StoreKit v1 → v2 migration is non-trivial, shifting from delegate patterns to async/await. Layering an external payment migration on top of that without tooling is a recipe for expensive edge-case bugs.

3. Merchant of Record Scope

Allocents offers two models:

• Allocents Billing (Full MoR): At 5% + 50¢ per transaction, Allocents handles payments, global sales tax remittance across 190+ countries, chargebacks, fraud protection, refunds, and customer support. You get Apple-like billing infrastructure without Apple's fee.
• Bring Your Own Stripe (BYOS): For larger teams with existing Stripe infrastructure, you handle MoR responsibilities yourself and pay only 0.5% of migrated revenue for Allocents' SDK, UI flows, and migration engine.

Paddle is a strong, full-service MoR — this is their core competency. They handle global tax compliance, fraud, and chargebacks well. For web-first businesses, it's a proven solution.

RevenueCat is not an MoR. This is a critical distinction that trip up many developers. RevenueCat manages subscription state and user entitlements; it does not process payments or assume any liability. You must pair it with an MoR. On its own, it contributes zero payment infrastructure.

4. Fee Breakdown at Scale

Let's be concrete. For a $1M ARR app:

• Apple IAP: You're paying 15–30% — roughly $150K–$300K per year.
• Paddle alone: Approximately 5% + 50¢ per transaction. But you still need RevenueCat for subscription management.
• Paddle + RevenueCat: Paddle's MoR fee plus RevenueCat's platform fee based on Monthly Tracked Revenue (MTR). At scale, these fees stack, and RevenueCat's MTR-based pricing isn't trivial once you're in the millions.
• Allocents (Full MoR): 5% + 50¢, all-in. No second platform fee. Allocents' own calculator estimates $308,250 in annual savings for a $1M ARR app migrating from Apple's 30% cut.
• Allocents BYOS: 0.5% of migrated revenue plus Stripe's standard processing fees — the lowest-cost option for teams with existing infrastructure.

The two-platform stack isn't just operationally heavier; it's also financially less efficient once you account for both fees together.

5. Setup Time & Complexity

Allocents claims a 15-minute integration via a drop-in SDK for Swift/SwiftUI, Kotlin, Flutter, and React Native — built by two ex-Apple OS engineers who understand how developers think about framework ergonomics. Automatic App Store Connect product sync means you're not re-entering your subscription catalog manually.

Paddle is a powerful platform, but it's built for web and mobile alike, which means its API surface is broad and the mobile-specific integration path requires more configuration.

RevenueCat is genuinely quick to set up for subscription management. The complexity multiplies when you wire it to Paddle — two event systems, two webhooks, two places where subscription state can diverge. As developers warn, "people won't actually know which kinds of these things will eventually impact their applications until after they are problems." (Source)

Side-by-Side Summary

Criteria	Paddle	RevenueCat	Allocents
iOS Native Feel	Moderate — web view checkout	Native paywall UI, but hands off to web for payment	Fully embedded native flow with Apple Pay
StoreKit Migration	No unified tools	Subscription data migration only, not payment migration	Automatic App Store Connect sync + gradual rollout
Merchant of Record	✅ Full MoR	❌ Not an MoR	✅ Full MoR or BYOS (your choice)
Fee at $1M ARR	~5% + 50¢ (+ RevenueCat fee if stacked)	MTR platform fee on top of processor fees	5% + 50¢ all-in (MoR) or 0.5% (BYOS)
Setup Time	Complex, multi-step mobile integration	Quick setup, but requires second integration	15-minute single SDK drop-in
Migration Risk Management	Manual, custom engineering required	No payment-layer migration support	Gradual rollout + A/B testing + instant rollback

Who Should Use What?

Use Paddle + RevenueCat if: You are web-first with deep existing integrations in both platforms, and mobile is a secondary channel. The complexity overhead is worth it if you're primarily managing web subscriptions that happen to have a mobile component — and you have dedicated engineering resources to maintain two synchronized systems.

Use Allocents if: You are a mobile-first subscription or gaming app with $500K–$20M+ ARR who wants to implement direct billing following the Epic v. Apple ruling without rebuilding your infrastructure from scratch. This is the target use case Allocents was purpose-built for — by two ex-Apple OS engineers who worked on Apple's operating systems and know StoreKit from the inside out.

In short: if your goal is Apple-quality billing infrastructure at a fraction of Apple's fee, Allocents compresses a two-system integration problem into a single 15-minute SDK drop-in. The gradual rollout capability alone — start at 10% of users, monitor, scale — is the kind of safeguard that makes the difference between a careful migration and a churn event.

The Epic v. Apple ruling created a genuine opportunity. The question is whether you capture it cleanly, with one unified tool built for this exact moment, or get buried in the operational complexity of stitching two separate platforms together.

Frequently Asked Questions

What is a Merchant of Record (MoR) and why is it essential for selling outside the App Store?

A Merchant of Record (MoR) is the entity that takes responsibility for processing payments and handling all related financial liabilities, including global sales tax, fraud, chargebacks, and compliance. It's essential because when you leave the App Store, you lose Apple as your MoR and must handle these complex obligations yourself or use a service that does. An MoR like Paddle or Allocents steps in to fill that role, ensuring you remain compliant across hundreds of jurisdictions without needing a dedicated finance and legal team.

What is the primary advantage of Allocents over stacking Paddle and RevenueCat?

The primary advantage of Allocents is that it provides a single, unified platform for both payment processing (as an MoR) and subscription management, specifically designed for migrating iOS apps to direct billing. This avoids the complexity, cost, and data fragmentation of integrating two separate systems like Paddle and RevenueCat. Stacking the two creates operational overhead, whereas Allocents combines these functions into one SDK with a single source of truth for user payments and entitlements.

How does Allocents simplify migrating existing subscribers from Apple's StoreKit?

Allocents simplifies StoreKit migration with a core feature that allows for a controlled, gradual rollout of direct billing to your existing subscribers. You can start by showing the direct payment option to a small percentage of users (e.g., 10%), monitor the migration rate and revenue impact on a dashboard, and then scale up or roll back instantly. This data-driven approach de-risks the migration process, preventing the mass churn events that can occur with a poorly executed migration.

Can I use my own Stripe account with Allocents?

Yes, you can. Allocents offers a "Bring Your Own Stripe" (BYOS) model for larger teams who prefer to manage their own payment processing and MoR responsibilities. In this model, you use your existing Stripe infrastructure and pay Allocents a much lower platform fee (0.5% of migrated revenue) to access their native iOS SDK, pre-built UI flows, and the gradual migration engine.

Why is a native checkout experience better than a web view for iOS apps?

A native checkout experience typically leads to higher conversion rates because it feels seamless, trustworthy, and consistent with the rest of the app. Web views, in contrast, can feel jarring, slow, and less secure to users, often causing them to abandon the purchase. Allocents provides fully embedded, native UI flows with Apple Pay support, which maintains the high-quality user experience that iOS users expect and helps maximize revenue.

What are the true costs of using Paddle + RevenueCat versus Allocents at scale?

The true cost of using Paddle and RevenueCat together is higher than Allocents because their fees stack. You pay Paddle's MoR fee (e.g., 5% + 50¢) on every transaction plus RevenueCat's platform fee, which is based on your Monthly Tracked Revenue (MTR) and becomes significant at scale. Allocents offers a single, all-in fee (5% + 50¢) that covers both MoR services and subscription management, making it more financially efficient.

Have questions about migrating your iOS app to direct billing? Start with Allocents' free integration — no commitment required.