Reference

Troubleshooting.

Common issues operators hit, with the actual fix. If your problem isn't here, hit reply on any Backstop email — a founder reads everything within one business day.

“My customers aren't syncing.”

Three usual causes, in order of likelihood:

1. Stripe Connect token was revoked

Someone in your Stripe team revoked the Backstop integration. Reconnect from Dashboard → Connect Stripe; we'll re-mirror everything we've missed. The dashboard surfaces a red banner when this happens.

2. You're in test mode but watching livemode (or vice versa)

We mirror the mode you connected with. The header shows testmode or livemodebelow your workspace name; if it doesn't match what you expect, reconnect with the right mode.

3. Webhook delivery to us is failing

Rare, but check Stripe's webhook delivery dashboard for failed sends to our Connect endpoint. If you see 5xx responses from us, hit reply — that's on us to fix.

“Dunning emails aren't going out.”

Recovery is paused

Check Settings → Pause recovery. We pause all recovery sends globally when the operator flips the toggle (e.g., during a Stripe outage on your side or a dispute over what's billable). The workspace dashboard shows an amber banner when paused.

Send domain isn't verified

Until your custom send domain is verified, we send from the shared sender — but if you've added an unverified custom domain and not finished DNS, sends are blocked. Either finish verification or remove the domain to fall back. See Custom send domain.

Customer unsubscribed

Customers who hit the unsubscribe link on any email get customers.unsubscribed_at set; we then skip the marketing-tone sends — the reactivation / win-back email and offer-reminder emails. Dunning (the failed-payment recovery sequence) is transactional and bypasses this — but customers can still mark dunning as spam, which we honor. A hard bounce sets bounced_at and suppresses the re-engagement sends the same way.

“My customer says they can't reach the cancel / update-card page.”

If the customer reports ERR_NAME_NOT_RESOLVED, DNS_PROBE_FINISHED_NXDOMAIN, or a similar “site not found” error — the page itself is up; their network is refusing to resolve trybackstop.com. The two patterns we've seen:

Corporate firewall in newly-registered-domain mode

Some DNS-filtering services (Zscaler, Cisco Umbrella, NextDNS, certain VPNs) quarantine domains under ~30–90 days old. A domain ages out of this window automatically, so if you ever see it on trybackstop.com it is temporary. While a customer is affected, they can:

You want to skip this class of issue entirely

Configure a custom cancel domain on your own root (cancel.yourcompany.com). Your customers never see trybackstop.com at all, and the domain inherits your established reputation with DNS filters.

“The cancel page is throwing 404.”

Most often: no cancel flow has been published yet. The token is valid but the runtime can't find a flow to render. Go to Cancel flows → New flow, pick a starter template, click Publish. Default traffic is 100% on v1 once you publish.

Less often: token expired (24h for embed cancel links, 21d otherwise) or was already consumed. Re-mint via the portal-link button on the customer's drilldown.

“Embed snippet returns signature_required.”

Your workspace has embed_require_signature=true but the request either had no signature or the signature failed verification. The usual culprits:

Copy-paste signing snippets (Node, and the “{ url } means it worked” check) live in the embed snippet doc.

“Save rate looks wrong.”

Save rate is computed as saved / (saved + canceled), excluding abandoned sessions. If your dashboard shows 0% but you're sure you saved someone, check that the session reached a terminal step — abandoning at the survey doesn't count toward either side of the ratio.

Still stuck?

Hit reply on any email from us. Include the workspace slug and a screenshot if you have one. We answer within one business day.