Proxies are getting caught by payment processor

[dnrdnr]

Hello guys!
As the title suggests, I'm trying to register for a paid subscription via a proxy, and my proxy is getting rejected by Recurly with a "fraud_gateway" error code.

I've tried with Residential Proxies from EU (had them on static for the registration), and also Static Premium ISP proxies. Both of them failed with the same issue.

Anybody else had a similar issue? Should I use mobile proxies for this?

 

[turelink]

try another profile & IP address

 

[app_pilot]

Switching to mobile proxies may help, as they are less likely to be flagged compared to residential or ISP proxies

 

[iproxyonline]

You can check Recurly's documentation on fraud prevention by visiting the section on their website at /product/fraud-management/. There, you'll find a link to a more detailed description of their methods. They mention that "Upon activation, for every new card transaction, Recurly communicates with Kount’s Fraud Service, sharing essential transaction details like IP address, email address, shipping address, card details, billing info, and more."

Certainly, they won't disclose all their verification methods, but the key point is that services like these always employ multifactor analysis. This includes IP checks and literally everything else they can access -- from proxy details to comprehensive assessments like the reputation of the card-issuing bank or the email domain.

When it comes to proxies specifically, you should check your proxies on "whoer" (google it) to identify any vulnerabilities. Also, using mobile IPs and choosing a reliable proxy provider can help. There are many options available on BHW marketplaces.

 

[dnrdnr]

You can check Recurly's documentation on fraud prevention by visiting the section on their website at /product/fraud-management/. There, you'll find a link to a more detailed description of their methods. They mention that "Upon activation, for every new card transaction, Recurly communicates with Kount’s Fraud Service, sharing essential transaction details like IP address, email address, shipping address, card details, billing info, and more."

Certainly, they won't disclose all their verification methods, but the key point is that services like these always employ multifactor analysis. This includes IP checks and literally everything else they can access -- from proxy details to comprehensive assessments like the reputation of the card-issuing bank or the email domain.

When it comes to proxies specifically, you should check your proxies on "whoer" (google it) to identify any vulnerabilities. Also, using mobile IPs and choosing a reliable proxy provider can help. There are many options available on BHW marketplaces.

Thanks for the detailed rundown mate! I have actually read this on their website, and tried to search the forums for "Kount's Fraud Service" or Recurly fraud prevention, but nobody shared their experience on how to go around them. I have spent the last couple of days testing some theories, and from what I can see, the usage of proxies was the biggest problem. I have had mixed success with various proxy providers & types... nothing to write home about yet

 

[needjapanstuff]

Thanks for the detailed rundown mate! I have actually read this on their website, and tried to search the forums for "Kount's Fraud Service" or Recurly fraud prevention, but nobody shared their experience on how to go around them. I have spent the last couple of days testing some theories, and from what I can see, the usage of proxies was the biggest problem. I have had mixed success with various proxy providers & types... nothing to write home about yet

so which proxy is best?

 

[dnrdnr]

Still haven't found any that works... I only had partial success with mobile proxies. Are you in the still boat with Recurly?

 

[BartProxy]

Look for static residential proxy provider with 0 fraud score IPs. If the IP you get does not work, tell him to give you a different subnet replacement until you find the working IP.

 

[razmah]

Hello guys!
As the title suggests, I'm trying to register for a paid subscription via a proxy, and my proxy is getting rejected by Recurly with a "fraud_gateway" error code.

I've tried with Residential Proxies from EU (had them on static for the registration), and also Static Premium ISP proxies. Both of them failed with the same issue.

Anybody else had a similar issue? Should I use mobile proxies for this?

No proxy will works, because they not support UDP protocol. all payment processor sites works on QUIC http/3 protocol, that socks5 are not support at all.
so, when you use socks5 you seems as not usual user, and get flagged. socks5 is easy to detect now.

here only Residential VPNs on Wireguard protocol may helps. like resvpn.net or others, with IPs on real users devices.

 

[needjapanstuff]

No proxy will works, because they not support UDP protocol. all payment processor sites works on QUIC http/3 protocol, that socks5 are not support at all.
so, when you use socks5 you seems as not usual user, and get flagged. socks5 is easy to detect now.

here only Residential VPNs on Wireguard protocol may helps. like resvpn.net or others, with IPs on real users devices.

are you sure?

 

[razmah]

are you sure?

of cource. i may give you checkers, where to check how you seems with socks5 and with vpn... but links not allowed here.

 

[needjapanstuff]

add my tele @wantjapan

 

[dnrdnr]

Hey do they take BH niche like MRR, NS, CF,...?

Sorry, I don't understand these abbreviations

 

[iproxyonline]

Oh man, I see quite a few inaccuracies in your thesis. I'm going to comment on some of them so that readers can see different perspectives.
Please don’t take this as impolite; I’m not arguing, I just want to show everyone that these points should be critically assessed.

No proxy will works, because they not support UDP protocol

That's not true -- there are already several proxy providers that support UDP, and we are personally among them.

all payment processor sites works on QUIC http/3 protocol

This is nonsense. It simply isn't true. Yes, payment systems are capable of working with HTTP/3, but they also continue to support other protocols because not all client software supports HTTP/3 yet!
For example, my home router doesn't support HTTP/3 because it was purchased several years ago. And I still manage to make all my online purchases perfectly fine without HTTP/3. Additionally, some residential providers just block UDP. That's the reality.

Here’s an interesting statistic: HTTP/3 is used by 31.1% of all the websites (https://w3techs.com/technologies/details/ce-http3)

all payment processor sites works on QUIC http/3 protocol, that socks5 are not support at all

Man, SOCKS5 indeed supports UDP-QUIC.
Here's proof from the official SOCKS5 documentation: https://datatracker.ietf.org/doc/html/rfc1928

so, when you use socks5 you seems as not usual user, and get flagged.

No, it's not about SOCKS5. The flag is simply the fact of using an intermediary server between you and web resources. Proper configuration can conceal this flag. The protocol used doesn't really matter.

 

[needjapanstuff]

Oh man, I see quite a few inaccuracies in your thesis. I'm going to comment on some of them so that readers can see different perspectives.
Please don’t take this as impolite; I’m not arguing, I just want to show everyone that these points should be critically assessed.


That's not true -- there are already several proxy providers that support UDP, and we are personally among them.


This is nonsense. It simply isn't true. Yes, payment systems are capable of working with HTTP/3, but they also continue to support other protocols because not all client software supports HTTP/3 yet!
For example, my home router doesn't support HTTP/3 because it was purchased several years ago. And I still manage to make all my online purchases perfectly fine without HTTP/3. Additionally, some residential providers just block UDP. That's the reality.

Here’s an interesting statistic: HTTP/3 is used by 31.1% of all the websites (https://w3techs.com/technologies/details/ce-http3)


Man, SOCKS5 indeed supports UDP-QUIC.
Here's proof from the official SOCKS5 documentation: https://datatracker.ietf.org/doc/html/rfc1928


No, it's not about SOCKS5. The flag is simply the fact of using an intermediary server between you and web resources. Proper configuration can conceal this flag. The protocol used doesn't really matter.

so i want konw vpn or socks5 which is best for Payment？

 

[proxygo]

Hello guys!
As the title suggests, I'm trying to register for a paid subscription via a proxy, and my proxy is getting rejected by Recurly with a "fraud_gateway" error code.

I've tried with Residential Proxies from EU (had them on static for the registration), and also Static Premium ISP proxies. Both of them failed with the same issue.

Anybody else had a similar issue? Should I use mobile proxies for this?

try a 4g proxy as they are more trusted .

 

[Mi C]

Try any proxy not yet detected by IP2Proxy.

 

[dnrdnr]

Try any proxy not yet detected by IP2Proxy.

Not working sadly. I'm getting mixed results when I test my proxies on various IP quality checkers.
I'm always looking for 0 Fraud scores, and those in the same DNS country as the IP.
Still no luck with Recurly.

 

[711Proxy_]

If you use the HTTP protocol, the DNS will be the same as the IP address of the proxy you are using.

 

[needjapanstuff]

Not working sadly. I'm getting mixed results when I test my proxies on various IP quality checkers.
I'm always looking for 0 Fraud scores, and those in the same DNS country as the IP.
Still no luck with Recurly.

i think get 0 Fraud scores very hard