Server-side tracking for Square
The Square server-side build has two halves that behave completely differently. Square Online orders are ordinary ecommerce sourced from a payment webhook. In-person payments have no click, no session and no identifier, so the work is building a bridge — usually an appointment or an identified customer — and measuring what share of counter revenue that bridge actually reaches.
Free30 minutesNo obligation
Square server-side · what breaks
What goes wrong on Square
- 01
Most transactions happen in person
A card at a terminal has no click, no session and no identifier. That is not a bug to fix; it is a boundary to measure.
- 02
Online and in-person blended into one number
Two channels with different margins and completely different attribution potential.
- 03
Appointments and orders in separate Square products
Square Appointments, Square Online and the POS each hold part of the picture.
- 04
No native path from a click to a counter payment
The bridge has to be built, usually through an appointment or an identified customer.
Square server-side · the fix
What changes — Square server-side
Online orders attributed properly
From Square's webhooks, server-side, with the identifier carried through checkout.
In-person revenue bridged where a bridge exists
Through appointment bookings or the customer directory, honestly, with the join rate stated.
The unattributable share reported openly
Rather than a number that quietly implies more coverage than exists.
Square server-side · architecture
What Square exposes to a server container
The server-side build on Square specifically.
- 1
Source online orders from the payment webhook
Not from a confirmation page.
- 2
Use the appointment as the bridge for in-person work
Capture the identifier at booking and join it to the eventual payment via the customer record.
- 3
Tag transactions by channel
Online and in-person must be distinguishable at the destination.
- 4
Measure and publish the join rate
The share of in-person revenue you can actually attribute. It will not be high and it should be stated.
- 5
Wire refunds
Square exposes them clearly.
Square server-side · diagnose
Where Square tracking breaks, in diagnostic order
Each check rules out a class of cause, so by the last one there is usually a single explanation standing.
- 01
Split Square revenue by channel first
Online versus in-person. Every subsequent number depends on it.
- 02
Measure what share of in-person payments have an identifiable customer
That is the ceiling on in-person attribution and it is usually low.
- 03
Check whether the identifier survives Square Online checkout
One real order answers it.
- 04
Check whether appointments carry the identifier
If they do not, the only available bridge is broken.
- 05
Confirm refunds reverse
Usually they do not.
Square server-side · prove
The QA evidence — Square server-side
Run on Square specifically, on a live conversion rather than in preview mode.
Source of truth
Square's transaction records — completed payments by date, with the online and in-person channels separated
- An online test order with the identifier confirmed on the Square order.
- An appointment booked from a paid click, followed through to the in-person payment and confirmed joined.
- The in-person join rate measured and stated as a number before any claim is made about coverage.
- Square transactions reconciled by channel against each platform for a closed window.
- A refund confirmed to reverse.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
Square server-side · free audit
What we check in the free audit
- Split Square revenue by channel first
- Measure what share of in-person payments have an identifiable customer
- Check whether the identifier survives Square Online checkout
- Check whether appointments carry the identifier
- Confirm refunds reverse
Checked against
Square's transaction records — completed payments by date, with the online and in-person channels separated
Free30 minutesNo obligation
Square server-side · when not to buy
When you don't need this on Square
Worth reading before you buy anything, from us or anyone.
- If nearly all your revenue is in person with no appointments and no identified customers, there is very little here to attribute and we will tell you that rather than build a bridge to nothing.
- If you only sell online through Square Online and the numbers already reconcile, this is working.
- Measure your online-versus-in-person split yourself first. It determines whether any of this is worth doing.
- If you are not running paid media at meaningful spend, the channel split alone is the useful deliverable.
Square server-side · what we deliver
What the server-side build gives you on Square
Container on your own subdomain
Your domain, your certificate, hosting in an account you control.
Money events from Square's transaction records
Square's transaction list is authoritative for revenue. Split it by channel before comparing against anything, because online and in-person have completely different attribution potential and blending them makes both unreadable.
Deduplicated at every destination
On a shared event ID, verified before any existing path is removed.
Consent enforced before dispatch
A denied destination receives nothing, verified by capture rather than configuration.
Written guarantee
95%+ tracking accuracy
Measured against Square's transaction records — completed payments by date, with the online and in-person channels separated. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies the browser-side setup you already have, on a live conversion. Honest about its ceiling on this platform.
- Root cause fixed, not worked around
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, so the browser can no longer lose them.
- First-party server container on your own subdomain
- Money events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, with monitoring so the next break surfaces in days.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring on every destination
FAQ
Square server-side questions, answered
For Square Online alone, a webhook handler is enough. A container earns its place once you are bridging appointments to in-person payments across several destinations, because that logic wants to live in one place.
Capture the click identifier when the appointment is booked and store it against the Square customer. When that customer pays in person, the payment webhook carries the customer ID, which joins back to the identifier. It works, and only for customers who booked.
Lower than you would like, and it depends entirely on what share of your business is booked in advance. Measure it before promising anyone a number — this is the figure we insist on publishing rather than burying.
Where you have them and consent allows, hashed. It improves the join rate for businesses that take bookings by phone, which in this category is many of them.
Free · 30 min
Move Square events off the browser
WhatsAppFree30 minutesNo obligation
