Paddle for mobile

With developments in legislation around the App Store, you can now link users in the United States to an external checkout for purchases in iOS apps. But, selling outside the App Store comes with complexity: payments, currency conversion, refunds, chargebacks, sales tax, and compliance become your responsibility.

Paddle is a merchant of record platform for mobile app developers. As a merchant of record, you can integrate with Paddle and we take care of payments, tax, fraud, and compliance for you.

Companies like HubX, Runna, PhotoMyne, and Letterboxd use Paddle to power their business.

Key features for mobile app developers

The link-out architecture

When you integrate with Paddle, you don't need to plug in an entirely new billing stack or build a custom checkout page. Instead, you link out to a checkout and bounce users back to your app when they complete their purchase.

A typical flow looks like this:

sequenceDiagram
    participant App as Your app
    participant Browser as Checkout
    participant Paddle as Paddle
    participant Backend as Backend/RevenueCat

    App->>Browser: 1. Open checkout URL
    Browser->>Paddle: 2. Customer pays
    Paddle-->>Browser: Checkout completed
    Browser->>App: 3. Redirect back to your app
    App->>Backend: 4. Verify purchase
    Backend-->>App: Entitlement granted, feature unlocked

The work splits cleanly:

• Paddle handles the entire checkout process, including payment processing, tax, fraud, and compliance.
• RevenueCat or your backend handles entitlement, using webhooks or your own database.
• Your app handles opening a URL and listening for the return deeplink.

Integration options

Depending on your needs, you can choose to host the entire checkout with Paddle, or build your own checkout page with Paddle.js.

You can always start with a hosted checkout, then build your own checkout page using the starter kit or Paddle.js if you need more control.

Identity across the boundary

While mobile users are signed into your app, the browser they open for checkout is anonymous. You can pass identity information through URL parameters when you open the checkout, so you can match the purchase back to the right user on your side.

If you're using RevenueCat, you can pass the app_user_id (or a custom RevenueCat ID) through the checkout URL, and RevenueCat receives the entitlement event from Paddle. Your app uses the standard RevenueCat SDK to check entitlements on resume.

When the customer returns via deeplink, include a transactionId query parameter on the redirect URL so your app can match the return to the original checkout. The Paddle.js checkout.completed event exposes this transaction ID.

Grant entitlements

Using RevenueCat

If your team already manages entitlements through RevenueCat, the RevenueCat x Paddle integration syncs Paddle purchases automatically.

Using Paddle webhooks and your backend

If you're not using RevenueCat, or you want complete control over the entitlement workflow, you can use webhooks and your own backend to handle entitlement.

Your backend listens for transaction.completed, updates your database, and exposes an entitlement endpoint your app calls on resume:

1. The app opens the checkout URL with app_user_id set to your user ID.
2. The customer pays. transaction.completed occurs in Paddle.
3. Your webhook handler matches the customer to the user and updates entitlements in your database.
4. The app resumes via deeplink and calls your entitlement endpoint.
5. Your backend returns the current entitlement state. The app unlocks features.

Paddle has webhooks for the full subscription lifecycle, so you can use webhooks to handle subscription creation, updates, and cancellations, too.

Next steps