Skip to main content
Paddle integration / Go-live checklist.
It’s pretty simple: once you’ve synced your web products, add them to a standard paywall and link a simple hosted web paywall. A purchase action on a web product opens that web paywall in the browser.When the user subscribes or dismisses the web paywall, Helium takes them back into your app.Here’s the full paywall-building guide.
Follow the on-device testing guide to test App2Web using Helium’s triple-tap flow.
We recommend starting with App2Web previews. Use a real purchase on an eligible US device to test entitlement delivery; simulated purchases don’t charge you or grant entitlements.Then make a real purchase through your app’s trigger and check that access unlocks when you return. See the Paddle tests.You can use Paddle’s webhook simulator to test delivery separately; it doesn’t create a real purchase.Using RevenueCat? Also check that:
  • Paddle webhooks reach RevenueCat for the correct user.
  • Web products grant the right entitlement tier.
  • Paddle and RevenueCat webhooks reach Helium as configured, and the purchase appears there.
We recommend analytics forwarding for supported analytics destinations: manage your connections in one place, and let Helium forward events with user, product, paywall, and experiment details.Already tracking Helium’s purchase-success events? That still works when users return to your app. StoreKit-only tracking won’t capture web purchases.Once your events arrive, you can forward conversions to Meta through destinations such as PostHog or Amplitude. Our setup guide covers each provider and other MMP routes.Here’s how to connect your analytics provider or MMP.
We make the browser experience look as similar to your app as possible. Your hosted paywall opens in a browser, with clickthrough.to visible in the address bar. After checkout, users return to your app.Payment sheet: we’ve optimized the payment sheet to keep checkout simple. Here’s what users will see:
  • Price: we calculate it from the selected offer. Free trials show $0.00 due today in USD; paid trials show the initial charge.
  • Names: make both product and price names customer-facing. We recommend leaving dollar amounts out; checkout already shows the price. Paddle’s Apple Pay title uses the product name.
We recommend Paddle’s automatic regional tax pricing, which adds sales tax to US purchases where applicable.
Your Manage Subscription button takes users to the Paddle customer portal. If they cancel at the end of the billing period, they keep access until then.
The billing email captured by Paddle at checkout is used for cancellation, retention, and win-back emails. With Apple Pay, this comes from the user’s Apple Pay billing information, so you don’t need to collect an email in your app. It may differ from their app login email.
  1. Create both audiences: one with the Paddle eligibility preset AND user_id_bucket <= 10, and one with just the Paddle eligibility preset.
  2. Select the smaller audience and launch a 50/50 experiment: your current IAP paywall versus App2Web.
  3. Monitor conversion rates and checkout/access issues for 24 hours.
  4. If the data looks good, use the same experiment and change its audience to the full eligible audience.
See the rollout steps.
Start with conversion rate: compare trial starts or direct purchases per exposed user. This is your early signal that the flow is working and users are converting.Once trials have converted and enough paid-purchase data is in, evaluate take-home ARPU: revenue after fees, taxes, and refunds, divided by all exposed users. Compare cohorts of the same age so both variants have had the same time to convert and generate revenue. For offers without trials, wait for enough paid purchases to make a meaningful comparison.Check confidence intervals before calling a winner; a conversion count alone does not establish significance.Proceeds is still in beta, so we’d cross-check it with your actual revenue and fees. Incorrect RevenueCat Small Business Program dates can skew its commission data.Example: $10 gross ARPU, 60% web / 40% IAP revenue, assumed fees of 2% web / 30% IAP:
  • App2Web: $10 x (0.60 x 0.98 + 0.40 x 0.70) = $8.68 (24% more).
  • IAP-only: $10 x 0.70 = $7.00.
Use your own fees here; these are illustrative rates. Weight by revenue share, not conversion share, unless revenue per conversion is equal.This example excludes taxes, refunds, and renewals. Revisit equal-age cohorts as revenue accumulates; stronger web renewals can increase lift.