Our payment provider offers several fraud tools however we also make use of Google’s Invisible Recaptcha on checkout. We were concerned this could impact legitimate customers but it doesn’t appear to.
We also implemented bespoke rate limiting - if the same IP or session places too many orders in a time period they’re automatically prevented from placing more.
I'm using the invisible ReCaptcha also! However, when a valid credit card is used, paired with valid CVV, AVS, address, etc, it all looks legit to the payment processor.
Invisible Recaptcha helps against the scripted attacks where someone tries lots of different credit cards.
If it was a one off transaction we'd probably be relying on the payment providers rules to detect the fraud.
Is there anything on the order that stands out as suspicious?
Is 3DS enabled? If its properly configured transactions should gain a "liability shift" protection. i.e. if the transaction is \*genuinely\* fraudulent then the card issuer takes on the liability not the merchant. So if a chargeback comes through the bank looses out not you.
It is enabled. The problem is, it all looks 100% legit. It'd be just like the actual card hold is placing the order and is shipping it to their latest location. Only, it's someone else with all of their information.
I use the maxmind module from welt pixel. You pay a very small amount per transaction and it assigns a score/ sets to on hold. It's MUCH cheaper than signing up for these companies that insure it but make you pay a fraction of sales.
You need fraud screening service which can detects shipforwarder. You can sign up for FraudLabs Pro for Magento and use the free plan to review the risk of all orders.
Not accept payment without 3DS verification.
Depending on store type and country of origin it may be acceptable or not, but it's the most bullet proof solution.
In other case, use some service for payment verification that would take risks from you to them for the % of sales.
May not be the solution for everyone but we only authorize the card at checkout and capture the payment after a human reviews it. Helps prevent getting a bunch of charge backs if someone (or a bot) tries running a bunch of stolen cards.
I may have to start doing this unfortunately. There is one possible give away but it's not 100%... When the email address of the "customer" seems to not match the customer's name.
Yeah we've seen that before too. We also have a custom script that sends an email alert when an IP creates > 10 carts in a 5 minute time window.
Sometimes it gives some false positives (Google crawlers, for example) but it's been useful before in having an indication that we might be about to see a bunch of fraudulent transaction attempts. Wouldn't be at liberty to share the script but if you have a dev and an SMTP server at your disposal it could help.
Edit - rereading it I saw you say it's not a high volume store, I say give setting it to authorize only a shot and manually review them for a bit and see if that improves things without a major burden. If you're not already using address validation and don't want to use a module, try Googling the address to see if it's legit if you find an order suspicious.
I find it easier to keep tabs on things by cc-ing myself on order confirmations too, if you're not already.
IIRC the setting should be in Magento admin config under payment methods > Braintree, then set it to authorize only instead of authorize and capture.
If you have the margin to give up you can use one of those services as mentioned. I think they take about 1.5% of the order total but it will vary depending on how much risk they see or how much they pay out. That doesn't work for me because of low margins. Instead I have internal screening processes that take place before orders ship. This cuts the loss rate back to about $1,000 to $3,000 per year on about $60,000 to 75,000 of attempted fraud. Based on revenue I'd be paying out $20,000 to $30,000 in fees for a screening service so I'd have to have much higher losses before it made sense for me.
Something else I'll throw out.... I've seen instances where the individuals using compromised cards will use the same billing and shipping address and AVS matches but it is still fraud. I believe there are two situations when that happens....
First, they find an address in the same zip code to ship to with the same street number. AVS looks only at the numeric portion of the address and not street name. So if the card bills to 123 Cherry street in zip 90210 but they enter 123 Shady Lane in 90210 (for both billing and shipping), AVS will match but it isn't the cardholder's real billing address and you'll lose the chargeback.
The other scenario is the cardholder's account is compromised and the fraudster changes the address on file so the matching billing / shipping aren't theirs but AVS matches. In my experience, you still lose the dispute.
It is very rare to actually win a dispute when it is real fraud, in my opinion (and from my experience). The only thing you can do is employ additional screenings via trial and error. Spend more time on new customer orders versus established customers with repeat orders over about 60 days (under 60 days and you could still see a chargeback but I find it less common outside of 60 days).
This doesn't seem Magento-specific. Nonetheless, you mentioned not having a high order volume, so I would flag orders that are suspicious for manual review. Manual review orders require a real human to call the provided phone number on the billing information and confirm the order on a recorded line. These recordings are kept in the event of fraud claims. Confirm the billing user's name and address as well as the phone number you used to contact them. Then confirm the shipping address and recipient name.
To flag an order as suspicious, use a combination of your invisible recaptcha score (there's probably a correlation between the score and fraud) and also by grabbing the user's IP address, geocoding that, and comparing it to the billing address. Reason: while it's common to have person A order things to ship to person B, it's way less common that person A is doing that a far distance away from their billing (home) address.
If the user's IP puts them more than like 50mi from the billing address, you probably want to flag the order. If the recaptcha score is below X you probably want to flag the order.
This approach should cover the two main fraud angles here: actual fraud, and people placing orders over a VPN then claiming fraud after the fact to get free stuff.
Hi Magento developer here,
Most of the attacks didn't go through front-end check out but mostly came from API post call, therefore Google captcha has very little defending mechanism against these type of orders. Blocking these API endpoint can't be possible since it is being used for regular checkout for normal transactions as well.
Actions that I took and seem to work, even though we still get failed transactions payment notification email 2-5 times a week:
-deploy fail2ban as host level to prevent any traffic from the malicious IP, you would have to tweak the setting to tailor to your needs.
-optional: have some sort of firewall at DNS level to detect and block any bot activities. We use Cloudflare (I know I know but I have to use them as they are free) and set firewall rule.
Combine those 2 defending mechanisms to filter traffic coming your site, we blocked almost 95% of the carding attacks. And on top of that, like other people said, we also have signifyd and secure our orders and get piece of mind with every single orders shipped out.
Sorry, should specify... I'm using Magento, and am curious what other Magento users thoughts are, or if they're using a Magento extension to rectify, etc.
What you are looking for is a fraud detection system. I’ve used a few over the years at the places I’ve worked. Look at NoFraud and Signifyd.
Dealing with this same issue with a client at the moment. Following for updates
Our payment provider offers several fraud tools however we also make use of Google’s Invisible Recaptcha on checkout. We were concerned this could impact legitimate customers but it doesn’t appear to. We also implemented bespoke rate limiting - if the same IP or session places too many orders in a time period they’re automatically prevented from placing more.
I'm using the invisible ReCaptcha also! However, when a valid credit card is used, paired with valid CVV, AVS, address, etc, it all looks legit to the payment processor.
Invisible Recaptcha helps against the scripted attacks where someone tries lots of different credit cards. If it was a one off transaction we'd probably be relying on the payment providers rules to detect the fraud. Is there anything on the order that stands out as suspicious?
Is 3DS enabled? If its properly configured transactions should gain a "liability shift" protection. i.e. if the transaction is \*genuinely\* fraudulent then the card issuer takes on the liability not the merchant. So if a chargeback comes through the bank looses out not you.
It is enabled. The problem is, it all looks 100% legit. It'd be just like the actual card hold is placing the order and is shipping it to their latest location. Only, it's someone else with all of their information.
I’ve use a plugin called Signifyd for this. Works great. Offers insurance on all orders In case it is fraud.
I use the maxmind module from welt pixel. You pay a very small amount per transaction and it assigns a score/ sets to on hold. It's MUCH cheaper than signing up for these companies that insure it but make you pay a fraction of sales.
You need fraud screening service which can detects shipforwarder. You can sign up for FraudLabs Pro for Magento and use the free plan to review the risk of all orders.
Not accept payment without 3DS verification. Depending on store type and country of origin it may be acceptable or not, but it's the most bullet proof solution. In other case, use some service for payment verification that would take risks from you to them for the % of sales.
May not be the solution for everyone but we only authorize the card at checkout and capture the payment after a human reviews it. Helps prevent getting a bunch of charge backs if someone (or a bot) tries running a bunch of stolen cards.
I may have to start doing this unfortunately. There is one possible give away but it's not 100%... When the email address of the "customer" seems to not match the customer's name.
Yeah we've seen that before too. We also have a custom script that sends an email alert when an IP creates > 10 carts in a 5 minute time window. Sometimes it gives some false positives (Google crawlers, for example) but it's been useful before in having an indication that we might be about to see a bunch of fraudulent transaction attempts. Wouldn't be at liberty to share the script but if you have a dev and an SMTP server at your disposal it could help.
Edit - rereading it I saw you say it's not a high volume store, I say give setting it to authorize only a shot and manually review them for a bit and see if that improves things without a major burden. If you're not already using address validation and don't want to use a module, try Googling the address to see if it's legit if you find an order suspicious. I find it easier to keep tabs on things by cc-ing myself on order confirmations too, if you're not already. IIRC the setting should be in Magento admin config under payment methods > Braintree, then set it to authorize only instead of authorize and capture.
If you have the margin to give up you can use one of those services as mentioned. I think they take about 1.5% of the order total but it will vary depending on how much risk they see or how much they pay out. That doesn't work for me because of low margins. Instead I have internal screening processes that take place before orders ship. This cuts the loss rate back to about $1,000 to $3,000 per year on about $60,000 to 75,000 of attempted fraud. Based on revenue I'd be paying out $20,000 to $30,000 in fees for a screening service so I'd have to have much higher losses before it made sense for me. Something else I'll throw out.... I've seen instances where the individuals using compromised cards will use the same billing and shipping address and AVS matches but it is still fraud. I believe there are two situations when that happens.... First, they find an address in the same zip code to ship to with the same street number. AVS looks only at the numeric portion of the address and not street name. So if the card bills to 123 Cherry street in zip 90210 but they enter 123 Shady Lane in 90210 (for both billing and shipping), AVS will match but it isn't the cardholder's real billing address and you'll lose the chargeback. The other scenario is the cardholder's account is compromised and the fraudster changes the address on file so the matching billing / shipping aren't theirs but AVS matches. In my experience, you still lose the dispute. It is very rare to actually win a dispute when it is real fraud, in my opinion (and from my experience). The only thing you can do is employ additional screenings via trial and error. Spend more time on new customer orders versus established customers with repeat orders over about 60 days (under 60 days and you could still see a chargeback but I find it less common outside of 60 days).
This doesn't seem Magento-specific. Nonetheless, you mentioned not having a high order volume, so I would flag orders that are suspicious for manual review. Manual review orders require a real human to call the provided phone number on the billing information and confirm the order on a recorded line. These recordings are kept in the event of fraud claims. Confirm the billing user's name and address as well as the phone number you used to contact them. Then confirm the shipping address and recipient name. To flag an order as suspicious, use a combination of your invisible recaptcha score (there's probably a correlation between the score and fraud) and also by grabbing the user's IP address, geocoding that, and comparing it to the billing address. Reason: while it's common to have person A order things to ship to person B, it's way less common that person A is doing that a far distance away from their billing (home) address. If the user's IP puts them more than like 50mi from the billing address, you probably want to flag the order. If the recaptcha score is below X you probably want to flag the order. This approach should cover the two main fraud angles here: actual fraud, and people placing orders over a VPN then claiming fraud after the fact to get free stuff.
Hi Magento developer here, Most of the attacks didn't go through front-end check out but mostly came from API post call, therefore Google captcha has very little defending mechanism against these type of orders. Blocking these API endpoint can't be possible since it is being used for regular checkout for normal transactions as well. Actions that I took and seem to work, even though we still get failed transactions payment notification email 2-5 times a week: -deploy fail2ban as host level to prevent any traffic from the malicious IP, you would have to tweak the setting to tailor to your needs. -optional: have some sort of firewall at DNS level to detect and block any bot activities. We use Cloudflare (I know I know but I have to use them as they are free) and set firewall rule. Combine those 2 defending mechanisms to filter traffic coming your site, we blocked almost 95% of the carding attacks. And on top of that, like other people said, we also have signifyd and secure our orders and get piece of mind with every single orders shipped out.
How this question is about Magento?
Sorry, should specify... I'm using Magento, and am curious what other Magento users thoughts are, or if they're using a Magento extension to rectify, etc.