# 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

# Custom callbacks

Handle custom callback requests from paywalls to run app-side logic and return results.

> **Info:** Available from Android SDK 2.7.0.

## Overview

Custom callbacks let a paywall request arbitrary actions from your app and receive results that determine which branch (`onSuccess` / `onFailure`) executes inside the paywall. Common use cases include validating user input, fetching data, or running business logic that lives outside the paywall.

## How it works

1. In the paywall editor, attach a **Custom callback** action to an element (button, form submit, etc.) and give it a name (e.g. `validate_email`).
2. When the user triggers that element the SDK calls your `onCustomCallback` handler with a `CustomCallback` object.
3. Your handler runs whatever logic is needed and returns a `CustomCallbackResult` — either `.success()` or `.failure()` — with optional data.
4. The paywall receives the result and executes the matching `onSuccess` or `onFailure` branch.

## Setting up the handler

Register the handler on a `PaywallPresentationHandler` before calling `register`:

```kotlin
val handler = PaywallPresentationHandler()

handler.onCustomCallback { callback ->
    when (callback.name) {
        "validate_email" -> {
            val email = callback.variables?.get("email") as? String
            if (isValidEmail(email)) {
                CustomCallbackResult.success(mapOf("validated" to true))
            } else {
                CustomCallbackResult.failure(mapOf("error" to "Invalid email"))
            }
        }
        else -> CustomCallbackResult.failure()
    }
}

Superwall.instance.register(placement = "campaign_trigger", handler = handler) {
    // Feature launched
}
```

## CustomCallback

The `CustomCallback` data class is passed to your handler:

<TypeTable
  type="{
  name: {
    type: &#x22;String&#x22;,
    description: &#x22;The name of the callback set in the paywall editor.&#x22;,
    required: true,
  },
  variables: {
    type: &#x22;Map<String, Any>?&#x22;,
    description: &#x22;Optional key-value pairs sent from the paywall. Values are type-preserved (String, Number, Boolean).&#x22;,
  },
}"
/>

## CustomCallbackResult

Return one of the following from your handler to signal the outcome:

```kotlin
// Success — the paywall's onSuccess branch runs
CustomCallbackResult.success(data = mapOf("key" to "value"))

// Failure — the paywall's onFailure branch runs
CustomCallbackResult.failure(data = mapOf("error" to "Something went wrong"))
```

Both `success()` and `failure()` accept an optional `data` map whose values are sent back to the paywall and accessible as `callbacks.<name>.data.<key>`.

## Callback behavior

When configuring the custom callback action in the paywall editor you can choose between two behaviors:

* **Blocking** — the paywall waits for your handler to return before continuing the tap-action chain. Use this when the next step depends on the result (e.g. form validation).
* **Non-blocking** — the paywall continues immediately. The `onSuccess` / `onFailure` handlers still fire when the result arrives, but subsequent actions in the chain do not wait.

## Accessing returned data in the paywall

Inside the paywall you can reference the returned data using the pattern `callbacks.<callback_name>.data.<key>`. For example, if the callback named `validate_email` returns `mapOf("validated" to true)`, the paywall can access `callbacks.validate_email.data.validated`.