A place for community members to contribute product ideas and suggestions.

2016 and authnet still hasn't heard of IPv6...

Status: Under Review
by on ‎06-16-2016 12:21 PM

Just posting here in case someone finds my post before wasting further time on this issue.


I have an app that uses authnet's API to take payments.  I also use their fraud detection suite, specifically for many of the IP address-related filters (velocity, shipping mismatch, regional blocking, etc).  I'd been conducting business like normal for some time, no issues.  I recently had my web host enable IPv6 for my site to get the benefits it providers for mobile shoppers who often see faster performance over v6 due to not having to go through carrier NAT for IPv4 in high density areas.  Everything seemed like it was working fine initially, but then I heard from a customer who could not pay.


After some debugging, we found that my payment code was populating the API field customerIP / x_customer_ip with the customer's IP, which is obviously what it is intended for.  I was populating it with both IPv4 and IPv6 addresses.  The field is only usable for IPv4 ;if you pass IPv6, it will decline the transaction.


What's worse, is that since I have fraud suite features enabled, I have to pass an IP.  So what to do for an IPv6 shopper?  I can't pass a placeholder IPv4 address, such as always passing my site's own IP when the shopper is IPv6, because I'd end up triggering the velocity filter.  So ended up having to go back to not having my site IPv6 enabled.


I found someone asking about IPv6 and that field as far back as 2011, and authnet still hasn't caught on.  Comcast is IPv6-enabled nationwide, as is nearly every 4g cell network, so this isn't just a fringe customerbase I'm wanting to support.


Status: Under Review
by Administrator Administrator
on ‎06-16-2016 02:34 PM

Hello @ispcolohost


With your permission, I would like to move this conversation over to our Product Ideas forum where others can vote and comment on your suggestion.



by Administrator Administrator
on ‎10-13-2016 12:51 PM
Status changed to: New
by Administrator Administrator
on ‎02-13-2017 03:49 PM
Status changed to: Under Review
on ‎10-24-2017 08:50 AM

IPv6 was years in the making and dropped the ball. Now IPv6 is a reality and gateway is behind other offerings like Braintree, Stripe, and PayPal. It is near the end of 2017, after the launch on 2012, and IPv6 is more common than ever before. With many transactions causing issues for those of us that use AFDS filters that rely on IPs.


The only "solution" that merchant support seems to be wanting to give you is to remove the offending filter. That's not safe, especially if you care about fraud and the impact on businesses. It seems like is pushing the liability on its customers that support IPv6 and dragging their feet for years.

on ‎10-24-2017 11:27 AM

Yup, Comcast has nearly their whole end userbase IPv6 enabled now, so discarding the ability to use fraud filters on what could potentially be all the users of one of the largest ISP's in the country is ridiculous.  Nearly every mobile network is handing out IPv6, so all the mobile users can't be fraud filtered.  Many offices are starting to enable, so on and so forth.  Really surprised this is still not addressed.

on ‎08-01-2019 09:24 AM
Oh hey, it's 2019, and still NOTHING on this. Congrats authnet, IPv4 runout has occurred, sites are enabling IPv6 in record numbers these days, and your services still don't work properly for IPv6-based sites.
on ‎07-29-2020 10:45 AM

Another year comes and goes, Authnet is still cranking away like it's 1999.  Hopefully once they finish their y2k project they can look into IPv6.

on ‎08-23-2021 04:41 AM

2021, still going strong like IPv6 doesn't exist.

on ‎09-29-2021 02:38 PM

Honestly – 2021 and many internet companies are using ipv6. What's the holdup