Authorize.NET and Miva Customer IP Addresses

[MGWben]

While laying the groundwork to add our site to the Cloudflare CDN, we noticed that the IP address associated to customer orders are passed to Authorize.NET as the REMOTE ADDRESS. This IP address is dependent on the Cloudflare server that the client is currently viewing the site from.

Since Authorize.NET has been setup to use customer IP in aid of fraud prevention (i.e. out-of-country orders and logging IP's to a customer), this Remote Address is not reliable and may cause false-positives for fraud.

I am unable to find where in Miva the Client IP (assuming s.remote_addr) is being issued to the AuthNET API push - is this a baked-in feature of the module?

We would like to use the FORWARDED address (s.http_x_forwarded_for) as this gives the accurate client-side IP regardless of CDN.

Thanks for any help!

[ILoveHostasaurus]

This can be worked around on the server side, where configuration can be added to trust IP addresses sourced from Cloudflare and have them treated as the remote IP. This will allow the address to log correctly, display correctly in the admin, and pass through to Authorize.net.

There is unfortunately one huge caveat to that. Cloudflare mandates sites be accessible via IPv6, and those real source addresses will pass through and be treated as the remote address just like IPv4. This is going to require you turn off their fraud filters, because even 15 years after IPv6 came in to common use, Authorize.net still doesn't support it. If Miva Merchant passes a remote IPv6 address in the remote address field, the transaction will be declined. For that reason, the software passes the site's own IP as the remote address if the requesting party is using IPv6, because otherwise the customer will never be able to pay as they'll consider the address given to be invalid. Since it's now passing its own IP for any transaction where the shopper is on IPv6, fraud filtering becomes useless as it will trigger declines since geographic mapping is now wrong, velocity filtering is triggered, etc.

A site being accessible via IPv6 has significant advantages for mobile users, those on hotspots, those in IPv6-enabled high density areas, and pretty much anyone on Comcast since they've deployed IPv6 nationwide many years ago now. These users are able to connect to your site IPv6 end to end where with IPv4 they may have to traverse several layers of internet provider equipment to go from private internal IP to public IP, which can add significant latency and/or even result in error if that equipment is having any issues. This can also result in SEO benefit.

So, at this point in time, my recommendation would be a payment gateway that properly supports IPv6 if it also offers fraud filtering based on shopper IP, or third party fraud services that work properly with both address families, because there's been no indication Authorize.net will ever fix this.

[Kent Multer]

Hi David, thanks for the explanation. Do you happen to know of any gateways that meet those criteria, supporting IPv6 and also having fraud protection?

[ILoveHostasaurus]

I asked around a bit and there's some belief internally that Braintree may have fraud filter functionality that is also v6-compatible. It would need to be tested but that's easy enough via a dev site that's v6-enabled, which we can do without enabling it on the primary site, with or without Cloudflare.

[MGWben]

David, thank you for your input on this matter. We unfortunately had to delay our CloudFlare rollout over this issue.

Also an unfortunate situation - we are only able to use Auth.NET as our payment processor. So we will keep this all in mind and hope that we'll be able to find a solution to IPv6 and CloudFlare in the future.

[ILoveHostasaurus]

Ugh, yeah I hear you, they mandate it be on and Authnet can't handle it on the fraud side; it's a frustrating situation given the benefits of v6. They used to let you disable it but stopped a couple years ago.

[Jim Cockerham]

This can be worked around on the server side, where configuration can be added to trust IP addresses sourced from Cloudflare and have them treated as the remote IP. This will allow the address to log correctly, display correctly in the admin, and pass through to Authorize.net.

There is unfortunately one huge caveat to that. Cloudflare mandates sites be accessible via IPv6, and those real source addresses will pass through and be treated as the remote address just like IPv4. This is going to require you turn off their fraud filters, because even 15 years after IPv6 came in to common use, Authorize.net still doesn't support it. If Miva Merchant passes a remote IPv6 address in the remote address field, the transaction will be declined. For that reason, the software passes the site's own IP as the remote address if the requesting party is using IPv6, because otherwise the customer will never be able to pay as they'll consider the address given to be invalid. Since it's now passing its own IP for any transaction where the shopper is on IPv6, fraud filtering becomes useless as it will trigger declines since geographic mapping is now wrong, velocity filtering is triggered, etc.

A site being accessible via IPv6 has significant advantages for mobile users, those on hotspots, those in IPv6-enabled high density areas, and pretty much anyone on Comcast since they've deployed IPv6 nationwide many years ago now. These users are able to connect to your site IPv6 end to end where with IPv4 they may have to traverse several layers of internet provider equipment to go from private internal IP to public IP, which can add significant latency and/or even result in error if that equipment is having any issues. This can also result in SEO benefit.

So, at this point in time, my recommendation would be a payment gateway that properly supports IPv6 if it also offers fraud filtering based on shopper IP, or third party fraud services that work properly with both address families, because there's been no indication Authorize.net will ever fix this.

David, I assume my problem is related to what you mentioned about IPV6. I am using Auth.net and Cloudflare. I am getting subscriptions declined due to regional IP address filter. The IP is showing as Brazil. Why would subscriptions processing via MivaPay show an IP in Brazil? I just had 3 in a row.

[ILoveHostasaurus]

Jim can you email me about this; I'd like to take a look.