What Square sends — and what ReviewNudger requires
The integration starts from a specific provider event, then resolves only the payment and customer facts listed here.
Accepted provider event
payment.created or payment.updated → COMPLETED
ReviewNudger accepts Square payment.created and payment.updated events only after the payment status is COMPLETED. Pending, approved, canceled, and failed payment updates do not start a review request.
A completed payment with an amount
The Square payment must be COMPLETED and include amount_money. Missing amount facts fail visibly instead of starting a request.
Buyer email or attached customer
A buyer email on the payment is enough. Otherwise, the payment must reference a Square customer with a usable email address or phone number.
A usable sending route
The location must have automation enabled, and the customer must pass cooldown, do-not-contact, and channel opt-out checks.
See the connection and its latest event
The connected-apps view shows whether Square is connected, whether ReviewNudger has received an event, and whether that event was processed or needs attention.
Illustrative product walkthrough using fictional Summit Plumbing data — not a customer case study.
From paid event to request, every step stays visible
The request journey records the trigger, initial delivery, follow-ups, stops, and outcomes in one timeline.
- 1Connect your Square account to ReviewNudger with a secure OAuth authorization — no API keys to copy and nothing to install at the register.
- 2When a payment is completed in Square — a card at the register, an invoice paid online, or a Square Appointments checkout after a visit — ReviewNudger receives the event, resolves the customer from the payment record, and applies your sending rules. It can then send one neutral Google review request by SMS or email.
- 3Every send is tracked with delivery status, opt-outs, and review click-through, so you always know what went out and what came back.
Illustrative product walkthrough using fictional Summit Plumbing data — not a customer case study.
What happens when the clean path is not available
Skipped and failed events are recorded with a reason. Nothing silently guesses a customer or sends around an opt-out.
Retries collapse onto one journey
Provider retries and repeated updates reuse the same provider payment identity. They cannot create a second ReviewNudger review-request journey.
Missing facts fail visibly
ReviewNudger requires the provider's amount and customer contact facts. If either is missing, the incoming event records the failure and no customer is guessed.
Sending rules can suppress the request
Disabled automation, an active cooldown, do-not-contact state, or an opt-out on the usable channel suppresses the request with a visible reason.
Refunds do not create or rewind journeys
Refund and reversal events do not create another request. They also do not automatically cancel a journey that already exists; an operator can cancel a queued request or stop later follow-ups.
Walk-in payments need contact data
A completed card payment with neither buyer email nor an attached customer is recorded as a visible failure. ReviewNudger never guesses which customer paid.
Repeated updates and split tenders remain one journey
Square can update the same payment more than once, and one order can contain multiple tenders. Payment IDs collapse repeated updates; when Square supplies an order ID, that order keeps split tenders tied to one review-request journey.
Full and partial refunds behave differently
A fully refunded payment is skipped when the refund is present before the first journey is created. A partially refunded payment remains one completed-payment journey. A later refund never creates a second journey and cannot recall a message that has already sent.
Email can carry the first request while SMS waits
A newly registered SMS number must be approved before it can send customer messages. ReviewNudger never sends from a number that is still pending.
Use email when it is allowed and usable
If the customer has email, the location has email enabled, and the required business address is configured, email carries the initial request while SMS is under carrier review.
Otherwise, keep the event recoverable
If no usable email route exists, the event is visibly suppressed as sms_not_ready. After SMS approval, an operator can recover it from recent events instead of asking the provider to send it again.
Connect Square and prove the trigger end to end
Have these provider and ReviewNudger details ready before you connect.
Before you start
- A Square account and permission to approve the secure OAuth connection.
- Buyer email captured on the payment or an attached Square customer with email or phone.
- A completed ReviewNudger location with its Google review destination and sending channels configured.
- 1Start a ReviewNudger trial and finish the short signup.
- 2Choose Square as your payment trigger and approve the OAuth connection.
- 3Take a real payment in Square to confirm the trigger end to end.
- 4Done. Each completed payment can now start one automatic review request under your sending rules.
Square integration questions
Do I need a Zapier account to connect Square?
No. The Square integration is native: you connect it directly inside ReviewNudger, with no middleware account, no per-task automation fees, and no field mapping to maintain.
What exactly triggers a review request?
Each time a payment is completed in Square, ReviewNudger records the event and evaluates it against your per-location send delay, cooldown, contact, and channel rules. One matching event can create one review-request journey by SMS or email.
Can a retry or duplicate webhook double-text a customer?
No. Every incoming event is deduplicated before any message is sent, and each event can create at most one review request. Provider retries and replays collapse onto the same request instead of sending twice.
What about customers who opt out?
SMS recipients can reply STOP at any time and email recipients can unsubscribe. Opt-outs are recorded per customer and honored across every future Square-triggered event.
Do all Square payment updates trigger a request?
No. ReviewNudger accepts payment.created or payment.updated only when the payment status is COMPLETED. The payment also needs amount_money plus either buyer email or an attached customer with email or phone.
What happens with refunds or split-tender payments?
A fully refunded payment is skipped if the refund is already present when ReviewNudger processes it. A partial refund remains one completed-payment journey. If two tenders pay the same Square order, the shared order ID keeps them to one journey instead of sending twice. A later refund does not recall a request that was already queued; you can cancel a queued request from the dashboard.
Does this work with Square Appointments?
Yes. A Square Appointments checkout is a regular completed Square payment, so when you check out a client after their visit, the same automatic review request can follow — nothing extra to set up. Two timing notes: if you require prepayment at booking, the request follows that payment (add a send delay so it arrives after the visit), and a cancellation or no-show fee you charge also counts as a completed payment.
Questions before you start? Email support@reviewnudger.com and a human will answer.