> For the complete documentation index, see [llms.txt](https://developer.paddle.com/llms.txt).

# Paddle for mobile

Use Paddle's web checkout from iOS and Android apps — link out, take payment, and return via deeplink. Paddle handles tax, fraud, and global payments outside the app stores.

---

Paddle isn't a native in-app purchase SDK. It's a merchant-of-record alternative to Apple StoreKit and Google Play Billing — your mobile app links out to a Paddle-powered web checkout, the customer pays with Apple Pay, Google Pay, cards, PayPal, or local methods, and returns to your app via deeplink. Paddle handles tax, fraud, subscriptions, and receipts.

What Paddle does **not** do: native StoreKit or Play Billing integrations, on-device receipt validation, or in-app purchases for content categories Apple and Google still mandate native billing for.

{% callout type="note" %}
Already on RevenueCat? Paddle plugs into the [RevenueCat x Paddle integration](https://www.paddle.com/revenuecat-integration-beta) for entitlement management. See [Grant entitlements](#grant-entitlements) below.
{% /callout %}

## What Paddle gives mobile teams

{% card-group cols=2 %}
{% card title="Sell outside the app stores" icon="carbon:globe" %}
Take direct payment relationships, set your own prices, keep more of each sale. Reach price points and markets the app stores can't — including students, regional pricing, and high-value subscriptions.
{% /card %}
{% card title="Link-out architecture" icon="carbon:launch" %}
Open a URL, listen for a deeplink return. The web side handles checkout, payment, and tax; your app code stays small. No native billing SDK to embed or maintain.
{% /card %}
{% card title="Web pages built for you" icon="carbon:application-web" %}
The Web Monetization Kit ships pricing, marketing, and legal pages on Next.js + Vercel — enough to pass website approval and launch without standing up a new web property.
{% /card %}
{% card title="Works alongside RevenueCat" icon="carbon:layers" %}
If your team already manages entitlements through RevenueCat, the Paddle integration syncs purchases automatically. Keep your existing entitlement infra; add web revenue without changing the app side.
{% /card %}
{% /card-group %}

## The link-out architecture

Every Paddle mobile flow follows the same shape:

1. Your app opens a URL — either a Paddle-hosted checkout link or a page on your own website that loads [Paddle.js](https://developer.paddle.com/paddle-js/include-paddlejs.md).
2. The customer pays in their browser. Paddle calculates tax, runs fraud checks, and routes the payment.
3. When payment completes, the browser redirects back to your app using a custom URL scheme or [universal link](https://developer.apple.com/documentation/xcode/allowing-apps-and-websites-to-link-to-your-content/).
4. Your app verifies the purchase against your backend or RevenueCat, then unlocks the feature.

The work splits cleanly: **the web side handles checkout** (UI, payment processing, tax), **your backend handles entitlement** (webhooks, your database), and **the app side handles two small things** — opening a URL and listening for the return deeplink.

{% callout type="info" %}
The deeplink payload isn't trusted. Always verify the purchase against your backend (or RevenueCat) before unlocking access. The deeplink is a signal that the user has returned, not proof that payment completed.
{% /callout %}

## Choose your path

Pick the integration based on how much of the web checkout you want to host yourself.

{% card-group cols=3 %}
{% card title="Hosted checkout" icon="carbon:cloud" %}
Paddle hosts the entire checkout. You configure a checkout link in the dashboard and open it from your app. Lowest setup. Requires Paddle approval on live accounts.
{% /card %}
{% card title="Web Monetization Kit" icon="carbon:rocket" %}
Recommended default. A Next.js app you deploy to Vercel — includes pricing, marketing, and legal pages so you can pass website approval. Tightly integrated with Paddle.js.
{% /card %}
{% card title="Custom workflow" icon="carbon:code" %}
Your own website with Paddle.js, your own backend creating transactions. Most control. Works when you already have a web property you want to extend.
{% /card %}
{% /card-group %}

The Web Monetization Kit is the recommended starting point for most teams — see [the starter kit tutorial](https://developer.paddle.com/get-started/starter-kits/web-monetization.md). For full hosted checkout setup, see [Add a hosted checkout to your mobile app](https://developer.paddle.com/build/mobile-apps/link-out-mobile-app-hosted-checkout-app.md). For a custom Paddle.js implementation, see [Build a custom mobile checkout](https://developer.paddle.com/build/mobile-apps/link-out-mobile-app-custom-workflow.md).

## Identity across the boundary

Mobile users are signed into your app, but the browser they open for checkout is anonymous. Pass identity through URL parameters when you open the checkout — Paddle attaches them to the resulting transaction, so you can match the purchase back to the right user on your side.

The most important is your internal user ID, passed as `app_user_id`. RevenueCat and most webhook handlers use this to associate the purchase with the user. Email, country code, and postal code can also be passed for pre-fill and localization. See [Hosted checkout URL parameters](https://developer.paddle.com/paddle-js/hosted-checkout.md) for the full reference.

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`](https://developer.paddle.com/paddle-js/events/checkout-completed.md) event exposes this transaction ID.

## Grant entitlements

Webhooks are the source of truth for entitlement — never trust the deeplink alone. Two patterns:

### Using Paddle webhooks and your backend

Your backend listens for [`transaction.completed`](https://developer.paddle.com/webhooks/transactions/transaction-completed.md) (and the subscription lifecycle events if you're selling subscriptions), 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. Paddle fires `transaction.completed`.
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.

This is the canonical pattern — see [Provision access with webhooks](https://developer.paddle.com/build/subscriptions/provision-access-webhooks.md).

### Using RevenueCat

If your team already manages entitlements through RevenueCat, the [RevenueCat x Paddle integration](https://www.paddle.com/revenuecat-integration-beta) syncs Paddle purchases automatically. You pass `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.

The trade-off: RevenueCat owns the entitlement model, which is a good fit if you already have iOS apps using StoreKit alongside web checkout. If Paddle is your only billing platform, the webhook pattern keeps the entire flow on your infrastructure.

## Regulatory context

App store rules around external purchase links are still in flux. Following the December 2025 *Epic Games v. Apple* ruling in the US and the Digital Markets Act in the EU, both Apple and Google may charge commissions on linked-out purchases at rates that are still being determined.

Plan for fees that may shift. Paddle's web checkout gives you direct payment relationships, full pricing control, and global payment methods that the app stores can't match — but treat any commission claim with a date attached.

<!-- TODO: link to /concepts/regulations/mobile-app-stores once it exists -->

For Paddle's current compliance and approval requirements, see [Hosted checkout for mobile apps](https://developer.paddle.com/concepts/sell/hosted-checkout-mobile-apps.md).

## Where to start

{% card-group cols=3 %}
{% card title="Web Monetization Kit" icon="carbon:rocket" url="/get-started/starter-kits/web-monetization" %}
Deploy the recommended Next.js + Vercel starter kit, including all the pages you need for website approval.
{% /card %}
{% card title="Hosted checkout (iOS)" icon="carbon:cloud" url="/build/mobile-apps/link-out-mobile-app-hosted-checkout-app" %}
Step-by-step iOS tutorial — link out to a Paddle-hosted checkout, handle webhooks, take a test payment.
{% /card %}
{% card title="Custom workflow (iOS)" icon="carbon:code" url="/build/mobile-apps/link-out-mobile-app-custom-workflow" %}
Build your own checkout page with Paddle.js, then link out from your iOS app.
{% /card %}
{% /card-group %}