RavelinJS & Ad-blockers

This document outlines how to prevent ad-blockers from interfering with RavelinJS fraud detection by routing API requests through either a custom subdomain or a server-side proxy.

Browser ad-blockers are widely used; on average over 30% of users - and as high as 53% in some countries - have one installed according to GWI. Ad-blockers interfere with legitimate scripts like RavelinJS by intercepting & blocking API requests made directly to Ravelin’s endpoint at https://live.ravelin.click. This results in missing device information for many customers and orders, impacting fraud detection performance.

Suggested solutions

We outline two solutions to this problem. Our preference is for custom subdomains, which are used by Ravelin clients around the world at scale, and require less work and maintenance.

1. Create a custom subdomain for RavelinJS requests

2. Use a proxy for RavelinJS requests to Ravelin

Implementation of a custom subdomain

1. Client chooses a custom subdomain name and notifies Ravelin
2. Ravelin creates a static IP address and shares with Client
3. Client adds a DNS A Record for the new subdomain, pointing to the static IP address provided by Ravelin
4. Client notifies Ravelin, Ravelin performs backend configuration & confirms completion (~30 minutes required)
5. Client configures RavelinJS to point to the new subdomain, using the api property - RavelinJS developer documentation
6. Client tests this configuration in a sandbox environment, and receives confirmation from Ravelin that everything works as expected before deploying to production

Example RavelinJS configuration with a custom subdomain:

var rav = new Ravelin({
  key: 'publishable_key_xyz...',
  api: 'https://ravdeviceevnts.yourdomain.com'
});

Implementation for proxy-based solution

Clients who opt for this solution should be aware that both the upfront work and ongoing maintenance is greater than with custom subdomains.

1. Client writes server-side code to intercept and proxy HTTP requests to Ravelin

• Endpoint for requests in all environments:https://live.ravelin.click
• Ensure the end user’s user agent is forwarded with all requests in the HTTP header User-Agent
• Ensure the end user’s IP Addresses are sent in all requests in the HTTP header X-Ravelin-For in the same format as provided in the X-Forwarded-For header see here
• The bespoke header is used to ensure Ravelin gets exactly what was on the customer request without any additional IPs attached via intermediaries between client servers and Ravelin servers
• Populate this by taking the X-Forwarded-For header and stripping out any IPs from internal infrastructure (e.g. load balancers or NAT gateways)

2. Client confirms the IP address range from which Ravelin will receive proxied requests, and shares this with Ravelin
3. Client configures RavelinJS to point to the new subdomain, using the api property - RavelinJS developer documentation
4. Client tests this configuration in a sandbox environment, and receives confirmation from Ravelin that everything works as expected before deploying to production

Feedback

Was this page helpful?

Thanks for the feedback. If you'd like to provide more detail, please email support@ravelin.com.