Connecting Square Online to Meta Conversions API
Square Online orders settle into the same Square account as the card taken at the counter, which is a genuine advantage: the online and in-person halves of the business are already denominated in one ledger. Meta's pixel loses a large share of conversions to Safari, ad blockers and iOS, and the Conversions API exists because of it. The join between them succeeds or fails on one thing: whether the fbc and fbp values reaches the Square Online order before the conversion happens, because Meta can only match a conversion it can tie back to a click it recognizes.
Free30 minutesNo obligation
Specific to this pair
Square Online to Meta: the built-in pixel and the counter sales
Check whether Square Online's built-in Meta connection already sends Purchase; if you can't share an event_id with it, keep one side. Send server events for online-channel orders only, with value net of tips and tax and the order ID as event_id, because counter receipt emails would credit Meta with walk-ins. Send restaurant orders when paid.
Square Online can connect a Meta pixel through its own settings, and Square has offered Facebook and Instagram selling features; check what your account currently supports and whether its Meta connection sends Conversions API events itself. If Square's built-in pixel fires Purchase and you add your own server events, you need a shared event_id, and a built-in integration may not let you set one. If it does not, keep one side and turn the other off.
If you send server events yourself from Square transactions, filter to the online channel first, then send Purchase with the order total net of tips and tax and the order ID as event_id. Counter sales are a specific risk with Meta: card payments where the customer gave an email for a receipt can match real Meta accounts with high quality, and Meta will cheerfully credit ads with walk-in customers who never saw them.
Store fbc and fbp on your own domain before shoppers move to a Square-provided store domain or Square-hosted payment page, and carry them into the order if your setup allows; otherwise matching relies on hashed email and phone from the order. For restaurants, send each online order when it is paid, not when it is picked up; the pickup can be hours later, and Meta's deduplication only works when the browser and server events arrive close together.
Square Online → Meta · what breaks
Why this join usually fails — Square Online → Meta
- 01
The fbc and fbp values never reaches Square Online
Square Online sites are frequently on a Square-provided domain, and checkout may hand off to Square-hosted payment pages depending on configuration.
- 02
Counter sales counted as online conversions
The convenience of one ledger is also the trap. If the sales channel is not filtered, every card swipe at the register lands in your ad reporting as a conversion you paid for.
- 03
Double counting from broken deduplication
Server and browser both fire, the event_id does not match, and Meta counts two purchases. Reported ROAS goes up, the business does not, and it can run for months before anyone reconciles against the store.
- 04
Nothing reconciles afterwards
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
Square Online → Meta · the fix
What working looks like — Square Online → Meta
The fbc and fbp values on every order
Conversions arriving in Meta
Events appear in Events Manager with an Event Match Quality score, deduplicated against the pixel, and become usable for optimization and attribution.
Reconciled against the source
Square Online → Meta · architecture
How Square Online and Meta actually connect
- 1
Square Online holds the truth
The filter is the whole job. Square's default reporting cheerfully sums counter sales and online orders, and that total is not something any ad platform should be optimizing toward.
- 2
Meta Conversions API needs a click to match
Meta matches server events to people using whatever identifiers you send, hashed with SHA-256 where required. There is no single mandatory key, which is why quality varies so much between implementations — a poorly matched event is accepted, reported, and worth much less than it appears.
- 3
The identifier is the bridge
The fbc and fbp values, captured at the visit and carried into the Square Online order.
- 4
The event source decides reliability
Send net of tips and taxes. Tips on food orders are substantial and are not your revenue.
- 5
Deduplication at the destination
Meta deduplicates on the pair of event_name and event_id. The browser pixel and the server event must send the same event_id for the same conversion, within the deduplication window. Get this wrong and every purchase counts twice — which is by far the most common Conversions API failure and it inflates reported ROAS rather than reducing it.
Square Online → Meta · normal or broken
Working vs. broken, side by side — Square Online → Meta
Normal, not a fault
The fbc and fbp values present on the order
Sent from the Square transaction record
Deduplicated correctly
Meta deduplicates on the pair of event_name and event_id. The browser pixel and the server event must send the same event_id for the same conversion, within the deduplication window. Get this wrong and every purchase counts twice — which is by far the most common Conversions API failure and it inflates reported ROAS rather than reducing it.
Reconciles with the source
Actually broken
The fbc and fbp values missing on most records
Square Online sites are frequently on a Square-provided domain, and checkout may hand off to Square-hosted payment pages depending on configuration.
Sent from the browser
The convenience of one ledger is also the trap. If the sales channel is not filtered, every card swipe at the register lands in your ad reporting as a conversion you paid for.
Counted twice, or not at all
Server and browser both fire, the event_id does not match, and Meta counts two purchases. Reported ROAS goes up, the business does not, and it can run for months before anyone reconciles against the store.
Nobody has reconciled it
Square Online → Meta · diagnose
Diagnostic order — Square Online → Meta
- 01
Count orders carrying the fbc and fbp values
- 02
Follow one real conversion end to end
- 03
Filter by sales channel and re-check the total
Compare the filtered online total against Square Online's own order count. If they disagree, the filter is wrong before the tracking is.
- 04
Read Event Match Quality and the deduplication indicator
In Events Manager, open the event and check both. A low match quality means weak identifiers; a missing deduplication indicator means your event_id pairing is broken.
- 05
Read the match rate, not the success message
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
Square Online → Meta · prove
How it gets proven — Square Online → Meta
Source of truth
Square transactions filtered to the online sales channel, by location.
- The fbc and fbp values confirmed present on a live order.
- Deduplication confirmed in Events Manager on a real purchase, with the browser and server events visibly paired rather than counted twice.
- Online-channel transactions reconciled against imported conversions for a settled week.
Square Online → Meta · free audit
What we check in the free audit
- Count orders carrying the fbc and fbp values
- Follow one real conversion end to end
- Filter by sales channel and re-check the total
- Read Event Match Quality and the deduplication indicator
- Read the match rate, not the success message
Checked against
Square transactions filtered to the online sales channel, by location.
Free30 minutesNo obligation
Square Online → Meta · when not to buy
When you don't need this — Square Online → Meta
- Measure identifier coverage yourself first — pull your last hundred orders and count how many carry the fbc and fbp values.
- If Square Online is a small side channel next to your counter business, measure it on order count and do not build an import for it.
- If you are not running Meta ads at meaningful spend, the Conversions API is effort without payoff. It earns its cost when the optimization signal is worth improving.
Square Online → Meta · what we deliver
What gets built — Square Online → Meta
Identifier capture into Square Online
Persist the identifier in first-party storage on your own domain before the handoff, and reattach it to the order at the point the transaction is written.
Event source: the Square transaction record
Send net of tips and taxes. Tips on food orders are substantial and are not your revenue.
Dispatch to Meta
Server-side events to the Conversions API with the event_id matched to the pixel, action_source set correctly, and customer data hashed before it leaves your infrastructure.
Reversals where they exist
Refunds appear in Square as their own records and should be sent as reversals.
Written guarantee
95%+ tracking accuracy
Measured against Square transactions filtered to the online sales channel, by location.. Miss it and we keep working at no cost.
From $400 · See packages
FAQ
Square Online → Meta questions, answered
Check the Meta or Facebook settings in your Square account for what is currently offered. If you add your own server events alongside a built-in pixel, both must send the same event_id.
Unfiltered Square transactions include counter sales, and customers who gave an email for a receipt match Meta accounts. Filter to the online channel before sending.
Almost always because the fbc and fbp values never reached the Square Online order. Square Online sites are frequently on a Square-provided domain, and checkout may hand off to Square-hosted payment pages depending on configuration. Measure coverage before debugging the dispatch.
Two things. The _fbc cookie, derived from the fbclid parameter on the landing URL in the format fb.1.<timestamp>.<fbclid>, is the click identifier. The _fbp cookie is the browser identifier. Beyond those, Meta matches on hashed customer information — email, phone, name, city, country — and every additional field raises the Event Match Quality score. Unlike Google, Meta does not need a click ID at all if the customer data is good, but match quality drops noticeably without it.
The Square transaction record. Send net of tips and taxes. Tips on food orders are substantial and are not your revenue.
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
More on Square Online → Meta
- Square Appointments → MetaConnecting Square Appointments to Meta Conversions API
- Square + Meta CAPIMeta Conversions API setup for Square
- Stripe → MetaConnecting Stripe to Meta Conversions API
RELATED GUIDES
Where Square Online → Meta fits in the rest of your tracking
- Meta · RestaurantsMeta Ads conversion tracking for restaurants
- Meta · CateringMeta Ads conversion tracking for catering companies
- Meta × POS SystemHow to reconcile Meta Ads against your point-of-sale system
- Meta · Reactivation → repeat purchaseHow to track lapsed customer reactivation to repeat purchase for Meta Ads
- Otter → MetaConnecting Otter to Meta Conversions API
- Square Online → RedditConnecting Square Online to Reddit
- CateringConversion tracking for catering, measured in confirmed events
- DoorDash → MetaConnecting DoorDash to Meta Conversions API
Free · 30 min
Get Square Online and Meta joined properly
WhatsAppFree30 minutesNo obligation
