A weekend inside KYC pushes the funded-deposit event to the edge of Meta's seven-day window

The post's two numbers do not agree with each other. The architecture diagram puts 24 to 72 hours between the registration that stores the click IDs and the payment gateway webhook that clears the deposit ^[5]. The prose puts KYC document review alone at anywhere from two hours to three business days ^[1]. Three business days that start on a Thursday finish on Monday, which is 120 hours before anyone funds anything ^[18]. Meta's standard click-through attribution window is seven days ^[14]. Give that trader one more day to wire the money and six of the seven days are spent ^[19].

The load-bearing part of this design is the row written at registration. A client-side helper reads _fbp and _fbc out of document.cookie and posts them to /api/register alongside the email and navigator.userAgent ^[16]. The dispatcher that fires later takes fbp, fbc, clientIp and userAgent as arguments ^[10]. At webhook time there is no browser to ask, so every one of those values has to come back out of the database.

hashParam trims a value, lowercases it, and returns a SHA-256 hex digest ^[8]. The post says Meta requires email, phone and name to be normalized and hashed before transmission ^[9]. Lowercasing a phone number does nothing, and the helper removes no punctuation, spaces or country-code formatting, so anyone extending user_data past the single hashed email in the sample payload ^[10] is writing their own normalizer.

Delivery is one POST to graph.facebook.com pinned at API version v19.0 ^[7]. A non-ok response logs "Meta CAPI Error" and returns false; a network failure logs and returns false ^[17]. There is no queue and no retry in the sample, so a lost FundedAccount event is a conversion that no browser will re-fire. The event_id is the transaction ID, which the post calls critical for deduplication ^[11]; that only dedupes against a second sender using the same ID, so the pixel side has to be built to agree. The payload also declares action_source as "website" on an event triggered by a payment gateway ^[12].

The claim carrying the whole argument is that optimizing only on top-of-funnel form fills trains Meta and Google to flood the funnel with bot signups and unverified users who never deposit ^[3]. The sources measure none of it. There is no bot rate, no cost per funded account before and after, and no volume floor at which a FundedAccount event starts moving the optimizer at all. The same walkthrough appears on dev.to twice under different slugs ^[20], which is one author's assertion published twice.

For the mechanism to transfer to your funnel, two things have to hold: enough verified deposits per week for the platform to learn from the event, and a click ID still attached to the user when it fires. The second one is cheap and I would do it regardless of whether you ever call the Conversions API. Reading two cookies at registration costs a column and a write ^[16]. You cannot backfill a cookie you never read, and the deposit webhook does not arrive for another 24 to 72 hours ^[5].