Fraudlabs PRO using multiple credits per transaction

[camgullo]

Hello,

I am using Fraudlabs Pro for fraud prevention on my Blesta install.
I noticed, on each order I receive I get at least 3 email's (Usually more) from FLP saying I have a transaction pending review. 
In turn, all of my Fraudlabs Pro credits (Free plan 500 credits) get eaten up with only 100-125 order's.

Has anyone else noticed this or does anyone know of a fix?

Thanks,

Cam

[MineHarvest66]

19 minutes ago, camgullo said:

Hello,

I am using Fraudlabs Pro for fraud prevention on my Blesta install.
I noticed, on each order I receive I get at least 3 email's (Usually more) from FLP saying I have a transaction pending review. 
In turn, all of my Fraudlabs Pro credits (Free plan 500 credits) get eaten up with only 100-125 order's.

Has anyone else noticed this or does anyone know of a fix?

Thanks,

Cam

I haven't at least this time. Every purchase (because I have it configured to do this like that) it only uses one credit each. 

[camgullo]

1 minute ago, MineHarvest66 said:

I haven't at least this time. Every purchase (because I have it configured to do this like that) it only uses one credit each. 

I don't understand, I have mine configured to check on all orders and customer signups.
Do you have yours configured to check on customer sign ups only?
I'm afraid that would open up a security loophole as clients could place an order after their first order.

Thanks,

Cam

[MineHarvest66]

11 minutes ago, camgullo said:

I don't understand, I have mine configured to check on all orders and customer signups.
Do you have yours configured to check on customer sign ups only?
I'm afraid that would open up a security loophole as clients could place an order after their first order.

Thanks,

Cam

Yes that is correct both sign ups and orders. So that that every purchase they make on my site are screened thus there are no "loop holes" in that regards. But one has to understand that these tools only LIMIT illegal activities as it impossible to get 100% of your orders to be "genuine".  

[camgullo]

Just now, MineHarvest66 said:

Yes that is correct both sign ups and orders. So that that every purchase they make on my site are screened thus there are no "loop holes" in that regards. But one has to understand that these tools only LIMIT illegal activities as it impossible to get 100% of your orders to be "genuine".  

Hello,

I completely understand that, I am more curious why it is using multiple credits for one order. 
Hopefully someone knows about a fix.

Thanks,

Cam

[timnboys]

On 1/26/2018 at 11:58 PM, camgullo said:

Hello,

I completely understand that, I am more curious why it is using multiple credits for one order. 
Hopefully someone knows about a fix.

Thanks,

Cam

aren't you from LET? as I recognize the name Cam Gullo, if so welcome to the blesta family 

[camgullo]

2 hours ago, timnboys said:

aren't you from LET? as I recognize the name Cam Gullo, if so welcome to the blesta family 

Hey, 

Yep, I am =D. Thanks for the welcome.

[MineHarvest66]

I can confirm that is happening on my end as well. @Paul and @Tyson given that it seems to occur to both us of this should be looked into. As this isn't even funny that it using an extra credit per order... 

My "theory" on this is that for some reason another report is made when the order is provisioned as it occurred again just seconds away from being 5 minutes... 

[camgullo]

3 hours ago, MineHarvest66 said:

I can confirm that is happening on my end as well. @Paul and @Tyson given that it seems to occur to both us of this should be looked into. As this isn't even funny that it using an extra credit per order... 

My "theory" on this is that for some reason another report is made when the order is provisioned as it occurred again just seconds away from being 5 minutes... 

Im glad Im not the only one.

I spoke with Paul about this. He said that Blesta did not develop the Fraudlabs Pro module so we would need to contact the developer. I asked Fraudlabs Pro support and they didn't develop it either. I checked out the code base and there was no tags left behind. 

Anybody know who developed it?

Thanks,

Cam

[MineHarvest66]

16 minutes ago, camgullo said:

Im glad Im not the only one.

I spoke with Paul about this. He said that Blesta did not develop the Fraudlabs Pro module so we would need to contact the developer. I asked Fraudlabs Pro support and they didn't develop it either. I checked out the code base and there was no tags left behind. 

Anybody know who developed it?

Thanks,

Cam

Are you sure that's the case @Paul ? The label on the Order System saying otherwise as there is no other modules involved for the anti fraud. It shipped with the stock's Order System Plugin. 

[Michael]

Only Paul knows but I thought it was Blesta otherwise I've had it since the start haha and don't know where I got it from.

[Tyson]

The FraudLabs integration is a component used by the Order plugin, but yes, it was originally written by another party (Hexasoft Development). The FraudLabs integration is rather simple, making an API call to verify the customer information against a fraud score to determine whether to deny either:

1. The customer from creating an account during signup
2. The customer from creating an order during checkout

In either case (depending on your configured Anti-Fraud Frequency setting), if the customer encounters an error with these actions and re-submits their information again, another fraud check will be triggered.

[MineHarvest66]

14 minutes ago, Tyson said:

The FraudLabs integration is a component used by the Order plugin, but yes, it was originally written by another party (Hexasoft Development). The FraudLabs integration is rather simple, making an API call to verify the customer information against a fraud score to determine whether to deny either:

1. The customer from creating an account during signup
2. The customer from creating an order during checkout

In either case (depending on your configured Anti-Fraud Frequency setting), if the customer encounters an error with these actions and re-submits their information again, another fraud check will be triggered.

Interesting and I can understand that... But we have the OP doing over 125 orders/month. I also know for a fact that @GosuHost one of the guys there says that their installation is doing the same thing too.  

I doubt with all of these repeated instances that it solely due to select clients needing to re submit payments/info. 

[Tyson]

1 minute ago, MineHarvest66 said:

Interesting and I can understand that... But we have the OP doing over 125 orders/month. I also know for a fact that @GosuHost one of the guys there says that their installation is doing the same thing too.  

I doubt with all of these repeated instances that it solely due to select clients needing to re submit payments/info. 

Do you have a lot of user sign up attempts? There could be spammers/bots continuously making POST requests to the sign up form, but providing insufficient information to create a client, which would a fraud check to be performed each time without resulting in any orders or new user accounts. I can only speculate as to what actually occurred in your particular case, but I can say that Blesta's order plugin will only attempt to perform fraud checks for new sign ups and when checking out.

[camgullo]

10 minutes ago, Tyson said:

Do you have a lot of user sign up attempts? There could be spammers/bots continuously making POST requests to the sign up form, but providing insufficient information to create a client, which would a fraud check to be performed each time without resulting in any orders or new user accounts. I can only speculate as to what actually occurred in your particular case, but I can say that Blesta's order plugin will only attempt to perform fraud checks for new sign ups and when checking out.

Hello,

To help put it in perspective, My Fraudlabs Pro plan reset on the 25th last month. When I got the email I changed my Fraud Check to only check on new client sign ups. Since the 25th I have gotten 36 new clients and at this moment I have 377 credits left. I understand the POST requests, Assuming it is the POST issue with a bot, shouldn't it fraud check after the client has successfully posted?
 

Thanks,

Cam

[MineHarvest66]

28 minutes ago, Tyson said:

Do you have a lot of user sign up attempts? There could be spammers/bots continuously making POST requests to the sign up form, but providing insufficient information to create a client, which would a fraud check to be performed each time without resulting in any orders or new user accounts. I can only speculate as to what actually occurred in your particular case, but I can say that Blesta's order plugin will only attempt to perform fraud checks for new sign ups and when checking out.

For me it not draining when nothing happening. But I don't have enough activity yet to say for certain. BUT according to the recent reply it seems to be ongoing problem. As well as the other entity I mentioned. 

[Tyson]

28 minutes ago, camgullo said:

To help put it in perspective, My Fraudlabs Pro plan reset on the 25th last month. When I got the email I changed my Fraud Check to only check on new client sign ups. Since the 25th I have gotten 36 new clients and at this moment I have 377 credits left.

Assuming a 'credit' is used each time an API call is made to FraudLabs API, 36 new client sign ups would result in a minimum of 36 credits subtracted. If the new users encountered an error, or some users never completed the sign up form with valid information, then that number would be higher, and 123 is not necessarily unrealistic.

 

25 minutes ago, camgullo said:

Assuming it is the POST issue with a bot, shouldn't it fraud check after the client has successfully posted?

The fraud check would occur before attempting to create a client on sign up since that is the action a rejected fraud score intends to prevent.

 

24 minutes ago, MineHarvest66 said:

For me it not draining when nothing happening. But I don't have enough activity yet to say for certain. BUT according to the recent reply it seems to be ongoing problem. As well as the other entity I mentioned. 

I took a look at the fraud verification checks and everything appears to be working as it should. The only improvement I can foresee making is possibly caching specific customer information and not performing the verification check again if that information hasn't been changed. This might reduce the number of fraud verifications performed to some extent, but it is still easy to spam sign ups and cause additional verification requests as previously mentioned.

[MineHarvest66]

27 minutes ago, Tyson said:

Assuming a 'credit' is used each time an API call is made to FraudLabs API, 36 new client sign ups would result in a minimum of 36 credits subtracted. If the new users encountered an error, or some users never completed the sign up form with valid information, then that number would be higher, and 123 is not necessarily unrealistic.

 

That is correct and that is the amount that should happen for 36 clients for "just sign ups".  

123 seems be rather high to me. That's a rate over 300% credits usage. I would think that at most 50% would be more "typical" .  

31 minutes ago, Tyson said:

I took a look at the fraud verification checks and everything appears to be working as it should. The only improvement I can foresee making is possibly caching specific customer information and not performing the verification check again if that information hasn't been changed. This might reduce the number of fraud verifications performed to some extent, but it is still easy to spam sign ups and cause additional verification requests as previously mentioned.

Why not... Just make it check upon successful actions? So when a client actually fills in the whole form? When an order is successfully paid for and similar actions?  

That way there is no "tripping" of incomplete forms and non payments?

[timnboys]

14 hours ago, MineHarvest66 said:

That is correct and that is the amount that should happen for 36 clients for "just sign ups".  

123 seems be rather high to me. That's a rate over 300% credits usage. I would think that at most 50% would be more "typical" .  

Why not... Just make it check upon successful actions? So when a client actually fills in the whole form? When an order is successfully paid for and similar actions?  

That way there is no "tripping" of incomplete forms and non payments?

well I like how the fraud check works currently since my anti fraud module I have it set to run each time a new order/client signs up and I want it to trip on any incomplete forms and non-payments to block and reject anyone it finds suspicious. though I would be open to providing @camgullo and you @MineHarvest66 with a free owned license of my anti fraud module since it checks both for fraudrecord reports & vpn/tor/etc checks as well since I have used fraudlabs pro before and can tell how fast the free plan credits disappears and it is not just on blesta that I have seen it happen also on whmcs which I used to use, as well which is why I set out and built my own anti fraud module to resolve this for myself.

[camgullo]

17 minutes ago, timnboys said:

well I like how the fraud check works currently since my anti fraud module I have it set to run each time a new order/client signs up and I want it to trip on any incomplete forms and non-payments to block and reject anyone it finds suspicious. though I would be open to providing @camgullo and you @MineHarvest66 with a free owned license of my anti fraud module since it checks both for fraudrecord reports & vpn/tor/etc checks as well since I have used fraudlabs pro before and can tell how fast the free plan credits disappears and it is not just on blesta that I have seen it happen also on whmcs which I used to use, as well which is why I set out and built my own anti fraud module to resolve this for myself.

I appreciate that @timnboys, I would love take you up on your offer.

[MineHarvest66]

1 hour ago, timnboys said:

well I like how the fraud check works currently since my anti fraud module I have it set to run each time a new order/client signs up and I want it to trip on any incomplete forms and non-payments to block and reject anyone it finds suspicious. though I would be open to providing @camgullo and you @MineHarvest66 with a free owned license of my anti fraud module since it checks both for fraudrecord reports & vpn/tor/etc checks as well since I have used fraudlabs pro before and can tell how fast the free plan credits disappears and it is not just on blesta that I have seen it happen also on whmcs which I used to use, as well which is why I set out and built my own anti fraud module to resolve this for myself.

I just sent a PM to you with my installation's domain so we can move forward.

[timnboys]

1 hour ago, camgullo said:

I appreciate that @timnboys, I would love take you up on your offer.

your license has already been issued to your account in my blesta.

@MineHarvest66 I sent you a pm asking if you was in my blesta or not as it is kinda hard to issue licenses to non existing accounts 

[MineHarvest66]

3 hours ago, timnboys said:

your license has already been issued to your account in my blesta.

@MineHarvest66 I sent you a pm asking if you was in my blesta or not as it is kinda hard to issue licenses to non existing accounts 

That been resolved now. 

Edited February 3, 2018 by MineHarvest66
Change in status of situation.

[Tyson]

On 2/2/2018 at 5:29 PM, MineHarvest66 said:

123 seems be rather high to me. That's a rate over 300% credits usage. I would think that at most 50% would be more "typical" .

Unless you are logging metrics, it's impossible to say for sure how many times the average user is submitting the form. The sample size is also pretty small. Most customers aren't as familiar with and as fluent as us in filling out information on a website, so they're prone to making more mistakes, which makes 123 additional checks not sound so far-fetched.

 

On 2/2/2018 at 5:29 PM, MineHarvest66 said:

Why not... Just make it check upon successful actions? So when a client actually fills in the whole form? When an order is successfully paid for and similar actions?  

That way there is no "tripping" of incomplete forms and non payments?

There are a couple things that prevent fraud checks from working that way:

1. Some people may want it to check against incomplete data (e.g. @timnboys)
2. Knowing whether the data is incomplete or not depends on the rule validation when creating a new client, so in that case you would need to create the client before running the fraud check to determine whether or not you can create the client (a circular pre-requisite)

[MineHarvest66]

17 minutes ago, Tyson said:

Unless you are logging metrics, it's impossible to say for sure how many times the average user is submitting the form. The sample size is also pretty small. Most customers aren't as familiar with and as fluent as us in filling out information on a website, so they're prone to making more mistakes, which makes 123 additional checks not sound so far-fetched.

 

There are a couple things that prevent fraud checks from working that way:

1. Some people may want it to check against incomplete data (e.g. @timnboys)
2. Knowing whether the data is incomplete or not depends on the rule validation when creating a new client, so in that case you would need to create the client before running the fraud check to determine whether or not you can create the client (a circular pre-requisite)

Thank you for the clarification regarding all of this.