A native PrestaShop module that sends the validated order to the Meta Conversions API from your server, carrying the same event_id as the pixel so Meta merges the two instead of counting twice. It rebuilds the _fbc click cookie from the fbclid when no pixel wrote one, which is exactly when the browser event is missing too.
The problem
Meta only knows what reaches it. Between an ad click and a validated order, a PrestaShop checkout crosses several places where the browser event does not survive.
The PrestaShop pixel fires on order-confirmation. A 3-D Secure redirect, a wallet, a closed tab, and the page never renders. The order is in your back office, the sale is nowhere in Events Manager.
Teams that add a server call next to the pixel usually send it without a shared event_id. Meta has no way to know it is the same purchase, so it counts both, and the reported ROAS becomes fiction.
A purchase without email, without _fbp and without _fbc is a purchase Meta struggles to attribute. Event Match Quality drops, and with it the value Meta can give your campaigns.
The fix
The module sends the browser event AND the server event for the same order, both stamped with the same event_id built from the PrestaShop order id. Meta deduplicates them and keeps the richer one.
Both events carry event_id order_<id>. That is Meta’s documented deduplication key, and it is derived from the order rather than from a random draw, so the two paths always agree.
The module captures fbclid on arrival and stores its own _dfss_fbc copy. A shop with no pixel, or a browser that dropped the cookie, still sends a usable _fbc with the purchase.
Email, phone and name are hashed in your shop before they leave, never sent in clear. The purchase reaches Meta with the identifiers it needs to attribute, and your Event Match Quality reflects the sale you actually made.
Setup
A standard ZIP in the module manager, PrestaShop 1.7 and 8. No core override, no theme change, nothing added to your checkout.
One key from your DataFirefly console identifies the site. It is the only thing your shop holds: no destination credential ever lives in your store.
Your Meta CAPI settings go into the console, stored encrypted on our side. Rotating them later touches nothing in the shop.
The same connector feeds every other destination from the same events, so Meta CAPI is a starting point rather than a silo. See the PrestaShop connector in detail or the Meta Conversions API across all platforms.
Same connector
One installation, one key. The events you already send reach every destination you switch on.
Pricing
10,000 events a month free, no card. Paid plans from 39 €/month when your volume grows. Every destination is included in every plan: Meta CAPI is never an add-on.
FAQ
No, provided both events share an event_id, and that is exactly what the module does: the browser event and the server event both carry order_<id>. Meta merges them and keeps the more complete one. Double counting happens when a server integration is bolted on without that key, which is the usual result of a hand-written Conversions API call.
Keep it. The pixel sees browsing behaviour the server never will, and Meta uses both signals. The module runs the two layers together and splits the funnel so the server owns the purchase. If you would rather run server-only, that works too, at the cost of the browser signals.
By sending, with the purchase, the identifiers a browser event often lacks: hashed email and phone from the validated order, the _fbp cookie, and an _fbc rebuilt from the fbclid when the pixel never wrote one. Hashing happens in your shop, so no raw identifier leaves your infrastructure.
The server event does not depend on the browser. PrestaShop validates the order, the module sends the purchase to the Conversions API. The pixel event is simply missing, and Meta receives the server one, which now carries the click id and the hashed identifiers.
Yes. Each shop can point at its own pixel and its own access token, or share them, and every event carries the shop it belongs to. The connection key is per site in your DataFirefly console.
On our side, encrypted at rest, never in your PrestaShop database and never in a template. Your shop only ever holds the connection key, which is scoped to your account and revocable in one click.
Install the module, paste one key, connect your pixel and your access token. The next order that pays through a redirect reaches Meta, deduplicated, with its identifiers.
