Migrate to Voidhash

Moving to Voidhash from another subscription platform, such as RevenueCat, Adapty, Superwall or Qonversion, or from your own receipt validation, works best as a parallel run. Voidhash watches the same purchases in observer mode while your current system stays in charge. You compare the two, then switch ownership behind a flag.

The strategy

1. Observe. Ship the Voidhash SDK in observer mode next to your current SDK. Your current system keeps selling, finishing transactions and granting access.
2. Compare. Check that Voidhash grants the same perks to the same people as your current system.
3. Switch. Move purchase UI and transaction ownership to Voidhash together, behind one flag.
4. Remove. Delete the old SDK once every user is on Voidhash.

Nothing changes for subscribers at any step, and you can turn the flag off to roll back.

Set up the catalog

Before the first observer release, recreate your catalog in Voidhash:

• Products. Create one product per thing people buy, and map each to its App Store, Google Play or Stripe product, including offers. Import products on the Products page lists the store catalog for you. See Products and perks.
• Perks. Translate each access level of your current system (often called an entitlement) into a perk, such as premium, and attach it to the products that grant it.
• Stores. Connect App Store, Google Play and Stripe (Help center) as you use them.

Bring over existing subscribers

How earlier purchases reach Voidhash depends on where they were made.

App Store and Google Play have no history import. A subscriber appears once they open a version of your app that includes the SDK, or when the store sends a notification about their subscription. A notification for a purchase the SDK hasn't reported yet is recorded on an anonymous stand-in, which merges into the right person when the app reports the purchase. Subscribers who lapsed before you connected, and never return, don't appear, so your Voidhash reports start at the migration.

To report purchases your current SDK makes from then on, call reportTransaction after each one. See Report purchases your billing SDK makes.

Store notifications

App Store Connect accepts one server notification URL per environment, and Google Play publishes to one Pub/Sub topic.

• App Store. Point the production and sandbox URLs at Voidhash, then set Voidhash's forwarding URL to the URL your current system used, so it keeps receiving every notification.
• Google Play. Add Voidhash's push subscription to your existing topic. A topic can have several subscriptions, so your current one keeps working. Voidhash can also forward notifications to your backend.

Keep the same user IDs

Call identify with the same user ID your current system uses, right after sign-in. Purchases then land on the same people in both systems, which makes comparing them straightforward, and later links your backend's records to Voidhash without a mapping table. For Stripe, set voidhash_distinct_id on existing customers before you import; see Link existing customers (Help center).

How anonymous and identified people relate is explained in People and identity.

Move your backend

Your backend probably checks access or receives webhooks from your current system. Move it in the same phases:

1. During the parallel run, add a Voidhash webhook endpoint and log what it receives next to your current webhooks. Don't act on it yet.
2. Compare access checks: check access for a sample of users, with a server library or over HTTP, and compare with your current answer.
3. When you switch ownership, make Voidhash the source your backend trusts. Keep handlers idempotent, because each system may send its own event for the same purchase.
4. After removal, delete the old endpoints and credentials.

A phased timeline

Next steps

• Run in observer mode
• Test purchases (Help center)
• Go-live checklist