Early Account Creation

The Problem#

You want to create a user account in your system as soon as the visitor submits 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#

  1. The end-user goes through your Zellify funnel. At the email collection step, they submit their email
  2. The Registration Webhook fires immediately, sending the user's email, quiz/form answers, and context (including app_user_id) to your backend
  3. Your backend creates a user account in an inactive or unpaid state, storing app_user_id as the identifier
  4. The end-user continues through the funnel and reaches the paywall. They initiate checkout, and Zellify creates the customer and checkout session in Stripe or Paddle with the same app_user_id in metadata
  5. The checkout form renders. The user fills it out and submits payment
  6. Stripe or Paddle sends a webhook to your backend. Your backend reads app_user_id from the metadata, finds the pre-created account, and activates it with the correct entitlements
  7. The end-user lands on the success page and taps the Deep Link Button, which carries app_user_id to your app or web product
  8. Your product looks up the user by app_user_id — the account is active and entitlements are granted

Phase 1: Early account creation (before payment)

Phase 2: Payment and activation


What Zellify Handles#

  • Fires the Registration Webhook when the user submits their email, before payment
  • Generates a unique app_user_id included in both the Registration Webhook payload and Stripe/Paddle metadata
  • Sets app_user_id and email on Stripe Customer/Subscription metadata or Paddle Customer/Transaction custom data at checkout
  • Provides the Deep Link Button on the success page with app_user_id interpolation

What You Need to Set Up#

1. Configure the Registration Webhook#

Set up the Registration Webhook in your Zellify dashboard:

  1. Go to Dashboard → Settings → Developers (https://dash.zellify.app/settings?tab=developers)
  2. Click Configure
  3. Enter your webhook endpoint URL
  4. 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 address
  • answers — all quiz/form responses collected so far
  • context.appUserId — the app_user_id (note: camelCase in the webhook payload, snake_case in Stripe/Paddle metadata)
  • context.funnelId, context.campaignId, context.experimentId — funnel attribution data

For the complete payload structure including all context fields, see Registration Webhook — Payload.

Your backend should:

  • Verify the webhook signature
  • Create a user account with email and app_user_id in an inactive/unpaid state
  • Optionally 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_id from the metadata/custom data
  • Find the pre-created account by app_user_id
  • Activate the account and grant entitlements based on the purchased product

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:

  1. Registration Webhookcontext.appUserId in the payload, used to create the account
  2. Payment Webhookapp_user_id in Stripe/Paddle metadata, used to activate the account
  3. Deep Link Buttonapp_user_id in 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.