# 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

# Purchases

How checkout works, and how to take it over.

> **Warning:** **Beta**The Web SDK is in beta and its API may change between releases.

## The default: Superwall handles it

Create an instance without a `purchaseController` and the SDK runs the standard checkout itself: Stripe checkout from the paywall, `?code=` redemption on return, and polling for the resulting entitlements.

```ts
const sw = createSuperwall({ apiKey: "pk_…" });
```

Products come from the paywall you configured in the dashboard. Subscription status updates on its own once the purchase settles.

## Reading the catalog

```ts
const products = await sw.purchases.getProducts();
```

Products come from the parsed config. Expect an empty array before configuration lands, or when the config carries no products.

## Restoring

```ts
await sw.purchases.restore();
```

## Discount codes

When a paywall is on screen, `sw.activePaywall` exposes controls for Stripe promotion codes.

```ts
const active = sw.activePaywall.value;

if (active) {
  const outcome = await active.redeemDiscount("LAUNCH20");
  if (!outcome.valid) console.log("rejected:", outcome.reason);
}
```

Redeeming validates the code against the checkout backend, re-prices the paywall's Stripe products, and forwards the code to every Stripe web checkout session created afterwards, including rebuilding sessions that were already prefetched.

```ts
active.clearDiscount();
```

`clearDiscount` is fire-and-forget and returns `void`. The paywall sends no acknowledgement, so there is nothing to await.

Behavior to know:

* `redeemDiscount` resolves after roughly ten seconds with `{ valid: false, reason: "timeout" }` if the paywall never replies, which happens when it has no Stripe products loaded.
* A second `redeemDiscount` while one is in flight supersedes the first, which settles as `{ valid: false, reason: "superseded" }`. `clearDiscount()` settles an in-flight redemption the same way.
* It rejects with a `DiscountError` for an empty or whitespace-only code, when no paywall is presented (including a stale `activePaywall` handle from a paywall that has since been dismissed), and when the presenter has no message channel.
* A discount does not survive dismissal. Re-apply it after each presentation.
* `reason` is an open union. Known values include `code_not_found`, `code_invalid`, `no_valid_products`, `no_applicable_products`, `error`, `timeout`, `superseded`, and `paywall_dismissed`. Do not write an exhaustive `switch` over it.

> **Note:** This is the programmatic equivalent of the **Apply Discount** tap action in the paywall editor.
> See [Discount codes](/docs/web-checkout/web-checkout-discount-codes) for setting the code up in Stripe.

## Running your own checkout

To bill through your own system while keeping the SDK's paywalls and placements, push the outcome in yourself:

```ts
sw.purchases.setSubscriptionStatus({
  status: "ACTIVE",
  entitlements: [
    { id: "pro", type: "SERVICE_LEVEL", isActive: true, productIds: [] },
  ],
});
```

The SDK treats what you push as truth for client-side state. It is still not a security boundary. See [Server-side gating](/docs/web/guides/server-side-gating).

## Taking over the controller

For full control of the transaction, pass a `purchaseController` at creation. It replaces the built-in automatic controller entirely, including `?code=` redemption and entitlements polling, so you own those too.

```ts
const sw = createSuperwall({
  apiKey: "pk_…",
  purchaseController: myPurchaseController,
});
```

There is no runtime setter. The controller is wired once, at `createSuperwall`.