Capture Leads from Embedded Funnels & Stripe

Once the BusinessMCP script is on your site, it turns any email a visitor types into an identified CRM contact — no custom forms or code required. It listens for native form submits, for a valid email in any email field the moment it loses focus (which catches AJAX and single-page-app forms that never fire a real submit), and for an email passed in the page URL such as a ?email= parameter on a thank-you page. Each captured email is stitched to that visitor’s anonymous browsing journey and, for business domains, enriched with company firmographics.

This covers the vast majority of sites, including form tools that embed inline — where the provider’s script injects the form directly into your page’s HTML. Because those fields live in your page, our listeners see them and capture the email exactly like a native form.

Some funnel builders — Heyflow, Typeform and others — embed as a cross-origin iframe: an <iframe> pointing at the provider’s own domain. The browser’s Same-Origin Policy deliberately walls that iframe off from your page. No analytics tool — not BusinessMCP, not Google Analytics, not Segment — can read the fields inside it or listen to its events. This is a browser security guarantee, not a limitation of any one script. So if your email is only ever typed inside a cross-origin iframe, direct field capture is simply not possible.

The good news: there are three reliable ways to bridge that boundary, and BusinessMCP supports all three.

Many embed tools post a message to the parent page when their form is submitted. Heyflow emits a heyflow-submit event and Tally emits a Tally.FormSubmitted event, both carrying the submitted fields. Our script now listens for these messages and lifts the email out automatically — you do not have to configure anything beyond having the tracking script installed. If your provider is Heyflow or Tally, an iframe embed just works.

Note that some providers — Typeform and Calendly among them — do not include the email in the message they broadcast, by design. For those, use one of the next two bridges.

Almost every funnel tool lets you redirect to a URL after completion and pass answers as query parameters. Point that redirect at a page on your own tracked domain and include the email, for example https://yoursite.com/thanks?email={{email}}. Our script reads email, user_email, email_address, contact_email and e parameters on page load and identifies the visitor — stitched to their journey because they are back on your tracked domain. This is the most universal bridge and works with any provider.

For funnels hosted entirely off your domain, or when you would rather not rely on the browser at all, send a webhook. BusinessMCP exposes a simple endpoint at /api/tracker/YOUR_TRACKER_ID/identify that accepts a JSON body of { "email": "person@company.com", "visitorId": "optional", "traits": { } }. Wire your provider’s webhook (or a Zapier/Make step) to POST there and the contact is created in your workspace, company-enriched, and ready in your CRM. If you passed the visitor’s id into the funnel as a hidden field, include it as visitorId to stitch the full journey.

POST /api/tracker/YOUR_TRACKER_ID/identify
Content-Type: application/json

{
  "email": "person@company.com",
  "visitorId": "optional — stitches the full journey",
  "traits": {}
}

If a buyer never fills a form and simply pays, BusinessMCP still captures them. Connect your Stripe in the dashboard and every succeeded charge becomes a customer contact with rolled-up lifetime value and company enrichment, pulled in automatically by our revenue sync.

The subtle part is tying that payment back to the buyer’s browsing journey. To do that we need the anonymous visitor id to travel with the payment. If you use Stripe Payment Links, our script now handles this for you: it decorates links to Stripe checkout with the visitor id as client_reference_id, and our revenue sync reads it back to stitch the journey — no configuration needed. For custom checkouts built with the Stripe API, set metadata.mcph_sid (or client_reference_id) to the visitor id when you create the Checkout Session or PaymentIntent. You can read the current visitor id in the browser at any time with window.mcph.getVisitorId().

Even without any of that, a Stripe buyer whose email was ever identified on your site — through a form, an embed bridge, or a prior visit — is stitched automatically by matching the email. The visitor-id passing only matters for buyers whose very first touch is the payment.