Seatext library / BotRefund evidence
How to Stop Coupon Sites from Overriding Your Referral Cookies
Prevent coupon extensions from hijacking your checkout by locking down scripts, hiding coupon fields, and monitoring cookie timestamps. Implement CSP, obfuscate coupon inputs, and use BotRefund's telemetry to detect late-stage cookie changes.
✓ Built for advertisers who need clear, refund-ready traffic evidence.
Coupon‑extension browsers (like Honey or Capital One Shopping) can overwrite your referral cookies at the payment step, stealing the credit for a sale. To stop this, lock down the checkout page, hide the coupon box from scripts, and watch for cookie changes that happen after the cart is built.
What is coupon‑extension abuse?
When a shopper reaches the payment screen, a browser extension injects its own affiliate URL and rewrites the referral cookie. The merchant then pays a commission to the extension instead of the original paid campaign.
Why it matters
If the cookie is overwritten, you lose attribution, pay double commissions, and see a margin drain that is hard to trace without telemetry.
How coupon extensions override referral cookies
The hijack loop starts when a user adds products to their cart and loads the checkout screen. The extension detects the checkout path or coupon entry form. It displays an overlay offering to apply coupons. In the background, it silently executes the extension's affiliate redirect URL. This background call overwrites your tracking cookies, taking credit for referring the sale. The merchant pays a commission fee on top of giving the customer a discount, double‑dipping on transaction margins.
Extensions use several tactics. They scan the DOM for common coupon field IDs like "coupon", "discount", or "promo". They listen for navigation to URLs containing "checkout", "payment", or "billing". They inject iframes or scripts that fire affiliate redirects before the merchant's own tracking fires. The redirect often happens in milliseconds, after the shopper has already committed to purchase but before the order confirmation loads.
Because the extension runs in the user's browser, it has the same origin privileges as your site scripts. It can read and write cookies, modify the DOM, and make network requests. Standard server‑side fraud filters cannot see this activity because it happens entirely client‑side.
How to set a strict CSP on checkout URLs
Content Security Policy (CSP) is an HTTP header that tells the browser which sources are allowed to load scripts, styles, frames, and other resources. On checkout pages, use a restrictive policy that blocks unknown third‑party scripts and frames.
Add a header like: Content-Security-Policy: script-src 'self' https://cdn.yourdomain.com; frame-ancestors 'none'; form-action 'self';. The script-src 'self' directive allows only scripts from your own domain and explicitly whitelisted CDNs. The frame-ancestors 'none' directive prevents your checkout from being embedded in an iframe by another site. The form-action 'self' directive ensures form submissions only go to your domain.
Test the policy in report‑only mode first: Content-Security-Policy-Report-Only: .... This logs violations to a reporting endpoint without blocking resources. Review the reports for legitimate third‑party widgets (payment gateways, address validators, chat widgets) and add their origins to the whitelist. Deploy the enforced header only after the report‑only period shows zero unexpected violations.
Note that CSP does not stop extensions that run entirely in the browser's privileged context. Extensions can bypass CSP by injecting scripts directly into the page context or by using the extension API to modify cookies. CSP is a layer that raises the difficulty, not a complete solution.
How to obfuscate coupon field IDs
Extensions scan the DOM for predictable input identifiers. Common targets include id="coupon", id="discount-code", name="promo", and class="coupon-field". Rename these to random strings that change per session or per deploy.
Generate a unique token server‑side when rendering the checkout page. Use it as the input's id and name attributes: <input type="text" id="cpn_a9f3k2" name="cpn_a9f3k2" autocomplete="off">. Rotate the token on each page load. Avoid any substring that matches known coupon keywords.
Also randomize the surrounding container classes and data attributes. Extensions often look for parent elements with classes like "coupon-form" or "promo-section". Use generic layout classes like "form-row" or "input-group" instead.
Keep the label accessible for humans: <label for="cpn_a9f3k2">Coupon code</label>. The label's for attribute must match the input's id. Screen readers and password managers still work. Extensions that rely on label text rather than IDs may still detect the field, but this raises the bar significantly.
How to monitor referral‑cookie timelines
Track the exact moment each referral cookie is set. Compare that timestamp to the shopper's session milestones: first visit, add‑to‑cart, checkout load, payment submission. A cookie set after add‑to‑cart but before checkout load is suspicious. A cookie set after checkout load is almost certainly an override.
BotRefund's client‑side script records every cookie write with millisecond precision. It captures the cookie name, value, domain, path, and the JavaScript stack trace that triggered the write. The script also logs the page URL, referrer, and a session ID. All data streams to your BotRefund dashboard in real time.
Configure alerts for these patterns: (1) A referral cookie appears after the addToCart event. (2) A referral cookie changes value after the checkoutLoad event. (3) Multiple referral cookies are set within a single session. (4) The cookie's domain or path differs from your standard affiliate cookie configuration.
Export the timeline for any flagged transaction. The evidence shows the original cookie (set by your paid campaign), the override cookie (set by the extension's redirect), and the exact millisecond gap between them. This is the proof you need to dispute the commission.
Trade‑offs and limitations
CSP can break legitimate third‑party checkout widgets. Payment processors, address autocomplete, fraud scoring scripts, and chat widgets often load from external domains. Each must be whitelisted. A missed domain causes a silent failure that may not appear in testing but hits production users.
Obfuscation does not stop extensions that use computer vision or heuristic DOM analysis. Some extensions render the page off‑screen, locate the coupon field by visual position or label text, and simulate keystrokes. Random IDs slow them down but do not guarantee blocking.
Client‑side telemetry adds a small JavaScript payload (~15 KB gzipped) to checkout pages. It runs after the page is interactive, so it does not block rendering. However, it cannot detect overrides that happen before the script loads (e.g., in a redirect chain before the checkout page). Pair it with server‑side logs of the initial landing referrer for full coverage.
BotRefund's payout rejection workflow requires manual review or an automated rule engine. You must integrate the flag data with your affiliate platform's API to void commissions. Not all affiliate networks support programmatic voids; some require a support ticket per transaction.
What to do after an override is detected
When BotRefund flags a transaction, follow this workflow:
- Pull the evidence packet. The dashboard provides a JSON export with cookie timestamps, stack traces, session replay link, and the affiliate network's click ID (if captured).
- Verify the override. Confirm the original cookie was set by your campaign (match the affiliate ID, campaign ID, and timestamp). Confirm the second cookie matches the extension's known affiliate pattern (e.g., Honey's "ref=honey", Capital One's "ref=capone").
- Void the commission. Use your affiliate platform's API or dashboard to reject the payout for that click ID. Document the void reason as "coupon extension override — client‑side telemetry evidence attached".
- Update blocklists. Add the extension's affiliate domain and redirect patterns to your CSP report‑only monitoring. If the same extension appears repeatedly, consider adding its known script hashes to a
script-src'sha256-...'deny list (via CSP Level 3script-src-elemwith'unsafe-hashes'— consult your security team). - Feed the model. BotRefund uses flagged sessions to improve its detection heuristics. Confirming true positives and marking false positives trains the system for your specific checkout flow.
Repeat the test cycle after each deployment. Run a clean purchase (no extensions) and verify the referral cookie remains stable. Then install a known coupon extension and repeat; the BotRefund log should show a "late‑set" event, confirming the guard is working.
Step‑by‑step implementation
- Set a strict CSP. Add directives like
script-src 'self'andframe‑ancestors 'none'to your checkout headers. - Rename coupon input classes/IDs. Use random strings (e.g.,
cpn_input_a9f3) and avoid common names likecouponordiscount. - Enable BotRefund telemetry. Install the BotRefund client‑side script; it records the millisecond timestamp of every cookie write.
- Monitor for late cookie writes. Set an alert when a referral cookie appears after the add‑to‑cart event.
- Reject payouts. Use the BotRefund dashboard to flag transactions where an override was detected and refuse the affiliate commission.
Verification and monitoring
After deployment, run a test purchase without any extensions. Verify that the referral cookie remains unchanged from the moment the cart is created to the final payment. Then install a known coupon extension and repeat; the BotRefund log should show a "late‑set" event, confirming the guard is working.
Common pitfalls
- Leaving default CSP values – a permissive policy lets any script run.
- Using generic field names – extensions scan for common IDs.
- Not reviewing BotRefund alerts – missed overrides keep slipping through.
FAQ
- Can I block coupon extensions entirely? No. Extensions run in the user's browser with full privileges. You can raise the difficulty (CSP, obfuscation, telemetry) but not achieve 100% block.
- What if CSP breaks legitimate third‑party checkout widgets? Test in a staging environment with report‑only mode. Whitelist each required origin explicitly. If a widget cannot be whitelisted (e.g., it uses dynamic subdomains), consider moving that widget to a separate page outside the checkout flow.
- How do I tell a late cookie from a genuine new affiliate click? A genuine new click arrives with a fresh session, a new referrer header, and a click ID from the affiliate network. A late cookie appears in an existing session, after add‑to‑cart, with no new referrer and often with an affiliate ID matching a known coupon extension.
- What evidence do I need to reject a payout? You need: (1) the original cookie timestamp and value, (2) the override cookie timestamp and value, (3) the session ID linking both, (4) the extension's affiliate ID pattern, and (5) the affiliate network's click ID for the override. BotRefund exports all of this in one packet.
- How do I test after deployment? Run three tests: (a) clean browser, no extensions — cookie should stay stable; (b) with Honey installed — BotRefund should flag a late‑set event; (c) with Capital One Shopping — same. Verify the flag appears in the dashboard within seconds.
- Do I need server‑side changes? No, the core fixes are client‑side (CSP header and field obfuscation) plus BotRefund's JavaScript. Server‑side changes are only needed if you want to log the initial landing referrer for correlation.
- Will CSP break my checkout? Test in a staging environment; a strict CSP can block legitimate third‑party widgets, so whitelist only required sources.
- Can I still offer a manual coupon box? Yes – the box works for users; extensions just can't auto‑detect it.
- How fast is BotRefund detection? It logs cookie writes in real time, giving you millisecond‑level evidence.
- Is there a cost? BotRefund offers a free trial; pricing details are on the homepage.
- What if the extension uses a redirect before the checkout page loads? BotRefund's script runs on the checkout page, so it cannot see redirects that happen earlier. Pair it with server‑side landing‑page logs that capture the initial referrer and any redirect chain.
- Can I automate payout rejection? Yes, if your affiliate platform supports an API for voiding commissions. BotRefund provides webhooks for flagged transactions; you can connect them to your affiliate platform's void endpoint.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Protect your checkout from coupon‑extension abuse
Install BotRefund free — no credit card required. The script adds client‑side telemetry to your checkout pages, flags late cookie writes, and gives you the evidence to reject fraudulent commissions.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.