# 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

Make the sale with usePurchase — handle completed, abandoned, and failed outcomes, restore purchases, and react to transactions from anywhere.

A purchase is one call: pass a product reference, await the result, react to what happened. The SDK owns the store sheet, the payment, and the receipt.

```tsx
import { usePurchase, useHaptics } from "superwall/hooks";

const { purchase } = usePurchase();
const haptics = useHaptics();

<button
  onClick={async () => {
    haptics.light();
    const result = await purchase("annual");
    if (result.status === "completed") haptics.success();
  }}
>
  Subscribe
</button>
```

## The three outcomes

`purchase()` resolves — it never throws for flow outcomes:

| Status      | Meaning                                                                                                                | Respond by                                                                                                                                                                        |
| ----------- | ---------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `completed` | The sale went through                                                                                                  | `haptics.success()`; the SDK dismisses the paywall if configured                                                                                                                  |
| `abandoned` | The user closed the store sheet                                                                                        | Treat as an ordinary outcome — most people who open a sheet close it. This is the only place *this paywall's own* declined offer is visible: show a last-chance offer, or nothing |
| `failed`    | No transaction happened — `reason` is `"timeout"` or `"superseded"` (a retry or re-presentation replaced this attempt) | Usually nothing; `haptics.error()` at most                                                                                                                                        |

### Never put the buy button in a loading state

No "One moment…", no disabling, no spinner. The store sheet *is* the feedback, and the SDK owns when it appears. A button that visibly waits makes the paywall feel broken in the gap the platform already covers.

### Abandoned is a signal, not a failure

Someone opened the sheet and closed it — that's the closest thing a paywall gets to hearing "not at this price." A common pattern is pushing a last-chance offer:

```tsx
const result = await purchase(selected);
if (result.status === "abandoned") {
  router.push("offer", { transition: "sheet" });
}
```

**One recovery offer, not two.** If the user abandons the discounted offer as well, let them be. The `abandonment-offer` [example](/docs/framework/examples) shows the full pattern — a second product, not a second design.

## Options

```tsx
purchase(reference, { shouldDismiss?, timeoutMs? })
```

Both default to what [`config.ts`](/docs/framework/config) declares (`dismissOnPurchase`, `purchaseTimeoutMs`).

## The two channels

Your `purchase()` call is one channel. The SDK reporting on its own is the other — and it reports transactions **whoever started them**. A successful restore arrives as a `transaction_complete` event with no purchase call in sight.

```tsx
// this paywall's own attempt
const result = await purchase("annual");

// anything the SDK reports — purchase, restore, trial start
useSuperwallEvent("transaction_complete", () => haptics.success());
useSuperwallEvent("freeTrial_start", () => {});
```

Drive *this paywall's* flow from the awaited result; use events for side effects that should fire on any transaction, however it started. The `purchase-states` [example](/docs/framework/examples) shows both channels side by side — and it's the one example that demonstrates the full haptic vocabulary (`success()` and `error()` keyed to outcomes).

See [Lifecycle & events](/docs/framework/lifecycle) for the full event list.

## Restore

```tsx
import { useActions, useHaptics } from "superwall/hooks";

const { restore } = useActions();

<button onClick={() => { haptics.light(); restore(); }}>
  Restore purchases
</button>
```

`restore()` is fire-and-forget — there is no result to await. Success surfaces as a `transaction_complete` event or a dismissed paywall. Every store paywall should offer restore — App Review expects it.

## Haptics on outcomes

iOS fires no feedback of its own inside a paywall, so the vocabulary is yours to supply:

* `haptics.light()` when the buy button is tapped
* `haptics.success()` when a transaction completes — via the event, so restores count too
* `haptics.error()` sparingly, on `failed`

## Selling beyond the App Store

Trials — who's eligible, what to show each side — have their own page: [Free trials](/docs/framework/trials). And a single config key sells the same paywall on the web through Stripe, with `purchase()` unchanged: [Web checkout](/docs/framework/web-checkout).