# 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

# Abandoned Transaction Paywalls

Learn how to respond when a user starts a purchase, then cancels the transaction.

When a user opens the store purchase sheet and dismisses it before completing the purchase, Superwall tracks a `transaction_abandon` event. You can respond to that in three ways:

1. Run an **On Abandon** action from the purchase button.
2. Show another paywall with a `transaction_abandon` placement.
3. Keep the user on the current paywall and reveal a drawer, offer, or survey using the `didAbandonTransaction` paywall state.

## Run an On Abandon action

Use the purchase action's **On Abandon** section when the response belongs to the button that started the purchase. This is the simplest option for cases like closing the paywall, moving to a recovery page in the same Flow, setting a state variable, or registering a custom placement after the user cancels the purchase sheet.

To set it up, select the purchase button, open its **Tap Behavior**, and add one or more actions under **On Abandon**. The actions run after Superwall receives the abandon result, so `state.didAbandonTransaction` and `products.abandoned` are already available when they execute.

For the full list of outcome actions and SDK requirements, see [Purchase outcome actions](/docs/dashboard/dashboard-creating-paywalls/paywall-editor-styling-elements#purchase-outcome-actions).

## Show another paywall instead

You can add `transaction_abandon` as a placement in a campaign. If a matching paywall is available, Superwall closes the current paywall and presents the new one.

Use this approach when the recovery experience should be a completely separate paywall, such as a dedicated discount page, a transaction-abandon survey template, or a later campaign with its own audience filters.

For campaign setup details and available audience filter parameters, see [`transaction_abandon`](/docs/dashboard/dashboard-campaigns/campaigns-standard-placements#transaction_abandon).

<iframe width="560" height="315" src="https://www.youtube.com/embed/-LeBeSHTs4g?si=DH7sWlyF-ppoO8tp" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen" referrerpolicy="strict-origin-when-cross-origin" />

## Use `didAbandonTransaction` in the current paywall

Use the `didAbandonTransaction` state when you want the recovery offer to feel like part of the same paywall instead of closing one paywall and opening another.

`didAbandonTransaction` is a boolean state variable that Superwall manages for you. It starts as `false` when the paywall opens or when a new purchase begins. If the user cancels the store purchase sheet, Superwall sets it to `true`.

You can use that state to open a drawer after the abandoned transaction:

## Add a drawer for the recovery offer

In the paywall editor, add a [Drawer](/docs/dashboard/dashboard-creating-paywalls/paywall-editor-drawer-component) element. Put the follow-up offer, survey, or personalized message inside the drawer.

## Bind the drawer to the transaction state

Select the drawer and set its open state to use a dynamic value. Use the `state.didAbandonTransaction` variable as the condition so the drawer opens when the value is `true`.

## Add the follow-up purchase action

Add a button inside the drawer that starts the purchase you want to offer next. For example, you might show the same product with clearer copy, a discounted product, or a lower-priced alternative.

## Publish and test the paywall

Preview the paywall on a device, tap the purchase button, then dismiss the App Store or Google Play purchase sheet. The drawer should appear on the same paywall after the transaction is abandoned.

> **Tip:** If you need to edit or preview the drawer in the paywall editor, open the **Variables** panel and
> temporarily set `state.didAbandonTransaction` to `true`.

## Personalize the recovery offer

When a transaction is abandoned, Superwall also stores the abandoned product reference. This lets you personalize copy based on the product the user tried to buy.

For example, if the user attempted to purchase the annual product, you can use the abandoned product variables to show annual-specific copy or pricing inside the drawer:

```liquid
Still interested in {{ products.abandoned.periodly }} access?
```

You can use the same product fields available for your other product variables, such as `products.abandoned.price`, `products.abandoned.periodly`, or `products.abandoned.trialPeriodText`.

> **Note:** `products.abandoned.*` refers to the product on the current paywall that the user attempted to
> purchase. Campaign audience filters use a separate `abandoned_product_id` value, which is the
> store product identifier.