Early Account Creation
Create user accounts when the email is collected, then activate them when payment completes.
The Problem
You want to create a user account in your system as soon as the visitor provides their email in the funnel — before they reach the paywall. This gives you early access to the user's data (email, quiz answers, app_user_id) for purposes like abandoned cart recovery, personalized follow-up emails, or pre-creating an account that is later activated on payment.
How It Works
The end-user goes through your Zellify funnel. At the email collection step, they enter their email and proceed
The Registration Webhook fires immediately, sending the user's email, quiz/form answers, and context (including
app_user_id) to your backendYour backend creates a user account in an inactive or unpaid state, storing
app_user_idas the identifierThe end-user continues through the funnel and reaches the paywall. They complete checkout via Stripe or Paddle. Zellify sets the same
app_user_idin the payment provider's metadataStripe or Paddle sends a webhook to your backend. Your backend reads
app_user_idfrom the metadata, finds the pre-created account, and activates it with the correct entitlementsThe end-user lands on the success page and taps the Deep Link Button, which carries
app_user_idto your app or web productYour product looks up the user by
app_user_id— the account is active and entitlements are granted
What Zellify Handles
Fires the Registration Webhook when the user submits their email, before payment
Generates a unique
app_user_idincluded in both the Registration Webhook payload and Stripe/Paddle metadataSets
app_user_idandemailon Stripe Customer/Subscription metadata or Paddle Customer/Transaction custom data at checkoutProvides the Deep Link Button on the success page with
app_user_idinterpolation
What You Need to Set Up
1. Configure the Registration Webhook
Set up the Registration Webhook in your Zellify dashboard:
Go to Dashboard → Settings → Developers (https://dash.zellify.app/settings?tab=developers)
Click Configure
Enter your webhook endpoint URL
Save and securely store the webhook secret
For full details on the payload structure and signature verification, see Registration Webhook.
2. Handle the Registration Webhook in your backend
When the Registration Webhook fires, your backend receives:
email— the visitor's email addressanswers— all quiz/form responses collected so farcontext.appUserId— theapp_user_id(note: camelCase in the webhook payload, snake_case in Stripe/Paddle metadata)context.funnelId,context.campaignId,context.experimentId— funnel attribution data
Your backend should:
Verify the webhook signature
Create a user account with email and
app_user_idin an inactive/unpaid stateOptionally store quiz answers for personalization or segmentation
3. Register a payment webhook endpoint
Set up your own webhook endpoint in Stripe or Paddle to receive payment events.
If you use Stripe:
Listen for events like checkout.session.completed. The Customer and Subscription metadata will contain app_user_id.
Refer to: Stripe: Webhooks
If you use Paddle:
Listen for events like transaction.completed. The Customer and Transaction custom data will contain app_user_id.
Refer to: Paddle: Webhooks Overview
4. Handle the payment webhook in your backend
When the payment webhook fires:
Extract
app_user_idfrom the metadata/custom dataFind the pre-created account by
app_user_idActivate the account and grant entitlements based on the purchased product
5. Configure the Deep Link Button on your success page
Add a Deep Link Button to the page after your paywall. Configure it with app_user_id interpolation to route users to your app or web product.
The Linking Key
This pattern uses app_user_id as the thread that connects three events:
Registration Webhook —
context.appUserIdin the payload, used to create the accountPayment Webhook —
app_user_idin Stripe/Paddle metadata, used to activate the accountDeep Link Button —
app_user_idin the URL, used to identify the user in your product
The same identifier flows through all three steps. Your backend matches on it at every stage.
When to Use This
This pattern is most useful when you need to:
Capture leads before payment — if many users drop off at the paywall, you still have their email and quiz data for follow-up
Store quiz answers server-side — if your product personalizes the experience based on funnel responses
Pre-create accounts — if your onboarding flow benefits from having the user already in your system when they arrive
If you do not need early data capture, the simpler approach is to handle everything from the payment webhook alone. See Mobile App with Custom Backend or Web App with Signup Page for those patterns.
Related
Last updated

