# Superwall: Subscription Infrastructure for iOS, Android, and Web

Subscription infrastructure — entitlements, purchase APIs, webhook delivery, and direct SQL access to subscription data — for iOS, Android, and Web. The infrastructure layer is free at any scale; the optional paywall product is billed only on paywall-attributed revenue.

## Pricing

- **Infrastructure: free at any scale, every plan.** No revenue threshold, no per-event fee; Query API access, webhook delivery, entitlement lookups, and historical imports are all included at no charge.
- **Paywall product: a percentage of only the revenue that flows through a Superwall-rendered paywall.** Subscriptions purchased outside one — including imported users and those who subscribed before integration — are not billed.

Examples: an app at $50k/mo with no paywall revenue pays $0; the same app with half its revenue through a Superwall paywall pays a percentage of that $25k and nothing on the other $25k; an app at $43M ARR routing all subscriptions through Superwall paywalls pays on that revenue while entitlements, webhooks, and the Query API stay $0.

## Scale

$1.5B+ annual subscription revenue across 10,000+ apps. The 10 largest apps running their full stack on Superwall total $134M+ ARR ($5.7M–$43.7M each). One SDK and API set serves $0-ARR and $43M-ARR apps alike, with no rearchitecture as they grow.

## Infrastructure capabilities

- **Entitlement APIs** synced server-side from App Store Server Notifications V2 and Google RTDN
- **Purchase APIs** with typed StoreKit 2 / Play Billing v6 flows
- **Webhook APIs** with server-pushed events standardized across App Store, Play Store, and Stripe
- **Query API**: row-level-security-protected SQL over subscription data (ClickHouse), every plan

Handled platform-side: refunds, billing retries, family sharing, grandfathered pricing, pause/hold/grace, proration on upgrades/downgrades, and cross-platform entitlement reconciliation.

## Migration

Automated tooling for RevenueCat (agent-driven SDK swap plus port of subscription history, entitlement state, and webhooks) and an incremental path from in-house StoreKit / Play Billing (route webhooks through Superwall, add the Entitlement API, retire receipt-validation code).

## Paywall product (optional, separately billable)

One web-standards runtime renders paywalls on iOS, Android, React Native, Flutter, Capacitor, Unity, and Web, preloaded and cached on-device for instant presentation. Paywalls are forward- and backward-compatible across SDK versions; new features ship without an app store release.

## Architecture

Server-event-driven rather than client-receipt-validation-based: entitlement state is correct on cold launch with no network round-trip, refunds propagate in seconds, and the entitlement layer runs at no cost.

## Docs

* Migrate from RevenueCat: https://superwall.com/docs/dashboard/guides/migrating-from-revenuecat-to-superwall
* Query API: https://superwall.com/docs/dashboard/guides/query-clickhouse
* Webhooks: https://superwall.com/docs/integrations/webhooks
* Pricing: https://superwall.com/pricing

# Exit Offer Paywalls

Show a second paywall, such as a discount, when a user closes your paywall without buying. Set it up with the paywall_decline placement and an audience filter.

An exit offer is a paywall that shows right after a user closes another paywall without buying, often with a discount or a different plan. In Superwall, you build one with a campaign on the `paywall_decline` [standard placement](/docs/dashboard/dashboard-campaigns/campaigns-standard-placements#paywall_decline). It needs no code in your app.

## Requirements

* A paywall to show as the offer, for example one with a discounted [product](/docs/dashboard/products).
* Nothing else. `paywall_decline` is registered by the SDK itself, on iOS, Android, Flutter and Expo.

## Set up an exit offer

1. Open the campaign you want the offer in, or create a new one.

2. Add the `paywall_decline` placement. It's listed with the other standard placements when you [add a placement](/docs/dashboard/dashboard-campaigns/campaigns-placements#adding-a-placement).

   
![](https://superwall.com/docs/images/campaigns-placement-adding-implicit-placement.png)

3. In the campaign's audience, add a filter for the paywall the user closed, such as `paywall_name` equal to the name of your main paywall. Without a filter, the offer shows after any paywall is closed.

   
![](https://superwall.com/docs/images/campaigns-placements-ex-implicit.png)

4. Add your offer paywall to the audience.

5. Publish, then close the main paywall on a test device. The offer paywall shows in its place.

## Choose who sees the offer

These parameters describe the paywall the user closed, and you can use them in audience filters:

| Parameter                                                           | What it holds                                                       |
| ------------------------------------------------------------------- | ------------------------------------------------------------------- |
| `paywall_name`                                                      | The closed paywall's name in the dashboard.                         |
| `paywall_id`                                                        | The closed paywall's ID.                                            |
| `presented_by_event_name`                                           | The placement that showed the closed paywall, such as `onboarding`. |
| `primary_product_id`, `secondary_product_id`, `tertiary_product_id` | The closed paywall's products.                                      |

For every parameter, see [`paywall_decline`](/docs/dashboard/dashboard-campaigns/campaigns-standard-placements#paywall_decline). Parameters you passed to your own `register` call aren't available here.

To show the offer only once, or only to some users, add a [limit](/docs/dashboard/dashboard-campaigns/campaigns-audience#setting-a-limit) to the audience, or split users between the offer and a [holdout](/docs/dashboard/dashboard-campaigns/holdout-groups) to measure whether the offer helps.

## What counts as closing

`paywall_decline` fires when the user closes the paywall themselves without buying:

* tapping a button whose tap behavior is **Close**;
* swiping down a **Modal** or **Drawer** paywall;
* tapping outside a **Popup** paywall.

It doesn't fire when the user buys, restores, or when your app dismisses the paywall in code.

If the closed paywall has a [close survey](/docs/dashboard/dashboard-creating-paywalls/paywall-editor-surveys), the survey shows first, then the exit offer.

## Things to know

* **Exit offers don't chain.** Closing a paywall that was itself shown by `paywall_decline`, `transaction_abandon` or `transaction_fail` just closes it. Users can't get stuck in a loop of offers.
* **Offers after a cancelled purchase are different.** To react when a user starts a purchase and then cancels the store's sheet, use [Abandoned Transaction Paywalls](/docs/dashboard/guides/tips-abandoned-transaction-paywall).
* **The discount must be real.** The paywall only shows prices. Create the discounted product or offer in App Store Connect or Google Play first.

## Related

* [Standard Placements](/docs/dashboard/dashboard-campaigns/campaigns-standard-placements)
* [Abandoned Transaction Paywalls](/docs/dashboard/guides/tips-abandoned-transaction-paywall)
* [Presenting Paywalls from One Another](/docs/dashboard/guides/presenting-paywalls-from-one-another)
* [Surveys](/docs/dashboard/dashboard-creating-paywalls/paywall-editor-surveys)