BotRefund Plugin Conflicts: What Happens and How to Fix Them

If BotRefund conflicts with other plugins on your site, the most visible symptom is that bot detection stops working or checkout errors appear. The usual root cause is duplicate JavaScript event listeners — two scripts listening to the same mouse or click events and interfering with each other. Open the browser console, find the error, then fix the load order or disable the conflicting script.

What a "conflict" actually means for a tracking script

BotRefund is a lightweight JavaScript snippet, not a heavy server-side plugin. It attaches event listeners to track clicks, mouse movement, scrolling, and session behavior. It runs up to 106 independent behavioral checks to decide whether a visit is human or automated.

A conflict happens when another script interferes with those listeners. One script might call stopPropagation(), which prevents BotRefund from seeing the events it needs. Another might override handlers or fire in an unexpected order. The result is incomplete data, missed bot detections, or a broken checkout flow.

BotRefund captures video proof for each detected bot. If a conflicting script prevents that capture, the evidence your refund claim depends on never reaches your account.

Symptoms that point to a plugin conflict

Run through this list when you suspect a conflict:

• Bot detection stops flagging visits that previously got flagged.
• Checkout throws JavaScript errors after the tracking snippet loads.
• The browser console shows errors like "duplicate listener" or "Uncaught TypeError: Cannot read properties of undefined".
• Refund claims come back without video evidence.
• Page load time increases noticeably after adding the script.

These symptoms don't always mean a conflict. A missing order ID in a webhook, incorrect script placement, or an aggressive caching layer can produce similar signs. Use the diagnostic sequence below to separate conflicts from other problems.

The diagnostic sequence: find the conflicting script

Work through these steps in order. Stop when you identify the cause. Don't skip steps — each one rules out a different problem class.

Step 1 — Open the browser console

Press F12 in Chrome, Firefox, or Edge. Go to the Console tab and reload the page. Red errors are your starting point. Note which script each error references. Most conflicts produce a clear error message that names the offending file.

Step 2 — Classify the error

Duplicate listener errors point to two scripts fighting over the same event. Reference errors suggest a missing variable or a script that loads out of order. Different error types need different fixes. Don't jump to disabling plugins before you know what you're dealing with.

Step 3 — Disable scripts one at a time

Turn off plugins one by one. After each disable, test BotRefund's detection. If detection starts working after you disable a specific plugin, you found the culprit. Keep notes on which plugins you tested.

Step 4 — Check script load order

Some scripts depend on others. If BotRefund loads before a script that sets a global variable BotRefund needs, initialization fails. Move the BotRefund snippet to the end of the header or into the footer, then test again.

Step 5 — Test in isolation on a staging site

Create a staging copy. Load only BotRefund plus one other script. Repeat for each script until you find the pair that breaks. This takes time but eliminates guesswork.

Step 6 — Confirm the fix

With the problem sorted, run a test transaction. Verify that detection triggers and that video proof is captured. Re-check the console for errors.

Common causes of tracking-script conflicts

Duplicate JavaScript event listeners

This is the most frequent cause. Two scripts listen for the same click or mouse event. One calls stopPropagation() and the other never fires. The fix is to change load order or add a guard check so the listener only attaches once.

Global variable collisions

Both scripts write to the same global variable name. One overwrites the other's value. This usually shows up as "undefined is not a function" errors. Renaming one script's namespace fixes it.

Script load order problems

BotRefund needs certain browser APIs to be available when it initializes. If another script defers or blocks those APIs, BotRefund may fail silently. Move the snippet to a later load position.

Content Security Policy (CSP) restrictions

A strict CSP can block external scripts from loading. If your CSP blocks the BotRefund script, detection never starts. Check the console for CSP violations and add the script source to your allowlist.

Ad blockers and privacy extensions

These can strip tracking scripts before they load. The symptom looks like a conflict, but it's actually a browser extension. Test in an incognito window with extensions disabled to confirm.

How to apply each fix correctly

Not every fix works for every situation. Here's how to match the fix to the cause:

• Duplicate listeners: Reorder scripts so BotRefund loads first or last, depending on which direction the conflict runs.
• Global variables: Wrap BotRefund in an IIFE namespace, or update the conflicting plugin to use a scoped variable.
• Load order: Move BotRefund to the footer if it doesn't need to capture events from the top of the page.
• CSP: Add the BotRefund domain to your allowlist, or use a build served from your own domain.
• Browser extensions: This isn't a plugin conflict. Add a note asking users to whitelist your site.

A good rule: change one variable at a time. If you reorder scripts and update the CSP in the same session, you won't know which fix worked.

When it's not a conflict at all

BotRefund cross-checks signals. A single anomaly is not a bot verdict, as the detection documentation makes clear. Privacy tools, corporate networks, and unusual devices can produce unexpected behavior for genuine people.

If detection accuracy seems off but there are no console errors, the problem may not be a conflict. Check whether your snippet is on every page where tracking should run. Confirm the site ID in the snippet matches your account. Verify that webhooks are configured with the right order ID field.

A conflict also isn't the cause if BotRefund works in staging but fails in production. That pattern points to a hosting-level issue — a caching rule, a CDN setting, or a server-side filter — rather than a plugin interaction.

Key facts about BotRefund detection

FAQ

Can BotRefund and analytics tools like GA4 run on the same page?

Yes, in most cases. Both attach event listeners, and conflict happens only when one script stops propagation. Load GA4 first, then BotRefund, and test.

What if the conflict breaks my checkout?

Temporarily disable the BotRefund snippet while you troubleshoot. Your checkout is more important than tracking. Re-enable the snippet after you identify the conflicting plugin.

Does BotRefund work with WordPress, Shopify, and other platforms?

BotRefund works with any platform that allows custom JavaScript. You add the snippet to the header or the checkout page. A plugin conflict is specific to your site, not the platform.

How do I know if the conflict is on BotRefund's side or the other plugin's side?

Test BotRefund alone on a staging site. If it works, the issue is in the interaction with another script. If it fails alone, the problem is in your BotRefund installation.

Will a conflict stop refunds that are already in progress?

No. Refund claims that are already submitted are handled by the ad platform. A conflict only affects future detection. Fix the conflict before the next claim cycle.

How much money can bot clicks cost if I ignore a conflict?

Bot clicks can steal up to 20% of your Google and Meta ad budget. Every day without detection is budget lost to invalid clicks.

Is there an official support path for conflicts beyond self-diagnosis?

Contact BotRefund support with your console output and a list of active plugins. Include the exact error message and the script names involved. This helps the team identify whether the issue is on their side.