What is carding?
Carding occurs when “carders” attempt to validate stolen credit cards by submitting small or zero dollar transactions in an attempt to verify the validity of a credit card. Imagine a bad guy gets a list of stolen credit cards and wants to sell them to other fraudsters. The bad guy needs to validate that the card will work before he sells that card, but doesn’t want to trigger any fraud detection by attempting a large transaction. Enter “carding”. The carder will write a script, bot or program to submit a small transaction to a payment processor for each of the stolen credit cards. If the small transaction is authorized or approved, then he can sell the card.
If you operate any type of e-commerce site, you’ve probably seen at least a few attempts to use a fraudulent card on your site. On a small scale, those fraudulent attempts might go unnoticed, because you are only paying a nominal per transaction fee for those fraudulent transactions. On a large scale, however, those nominal fees add up pretty quickly. You could be racking up quite a large bill from your payment provider if those small charges go unnoticed for a few weeks, months, or more.
Is my site at risk?
In our experience, the most common e-commerce credit card payment providers to fall victim to carding are PayPal Payflow Pro or PayPal Payments Pro payment gateways. To understand why these payment providers are more vulnerable, it might help to understand how these transactions are executed from Magento.
Magento uses two transactions for each credit card processed through these payment providers. Typically, Magento submits a zero dollar credit card authorization to PayPal to verify the card, then a subsequent transaction for the actual order amount which completes the sale or authorizes the full amount for delayed capture. That first zero dollar authorization transaction is what is often exploited in a carding attack. So, while the merchant hasn’t received a payment from the credit card holder, they have been charged a nominal transaction fee from PayPal. A few of these a month would likely go unnoticed or ignored, but when hundreds or thousands of these transactions take place PayPal’s carding prevention module will start blocking all credit cards on your site. As long as your PayPal Manager account contact information is up-to-date, then you should get an email notifying you that the carding prevention module has been triggered and credit cards are now blocked on your site.
How to prevent or resolve carding?
The first thing we want to do is whitelist your Magento IP address(es). With this configuration, we’re telling PayPal to only accept transactions from your Magento instance(s) and ignore all other requests. If you have other applications that utilize PayPal for credit card processing, like an Enterprise Resource Planning (ERP) application, then you’ll need to configure those IP addresses here, too.
In PayPal Manager, navigate to Account Administration->Manage Security->Allowed IP Addresses (For API Transaction Processing). Here you need to enter the IP address(es) for each of your Magento servers. Many of you will only have one Magento IP address, but you may need to add several IP addresses if your Magento instance is load balanced across multiple servers.
If your site has already triggered the PayPal Carding Prevention module, then you should also navigate to Account Administration->Manage Users and update the password used by Magento. If you don’t know what user account is used in Magento, we suggest creating a new user with full API access.
If you have been a recent victim of a carding attack, you should consider enabling reCAPTCHA on your checkout pages for added security, even if only for a limited time. This will give you another layer of protection from bots and programs intent on exploiting your site with carding attempts. It is worth noting that consumers may get frustrated by CAPTCHA, so you may not want to leave CAPTCHA on indefinitely.
To enable CAPTCHA, you need to setup a Google account for reCAPTCHA, if you haven’t already done so. Go ahead and create credentials for both v2 and v3, so you can see for yourself which you prefer on your site. Once you have your credentials, add them to Magento admin here: Store>Configuration>Security>Google reCAPTCHA storefront. Next, you can turn on reCAPTCHA for checkout by selecting a reCAPTCHA option on Enable for PayPal Payflow Pro payment form. Fill out any remaining fields and save and clear cache. Now you should walk through your checkout and any other forms you’ve enabled with CAPTCHA and verify that it is working as expected.
Magento Session Validation
Magento 2 has several configurations that will make your store and checkout even more secure. Some of these features may impact site performance and access, so it is important to understand each option. Enabling all of these options will make your site more secure, but could also block access to users whose internet services utilize a proxy server or a firewall.
Let’s walk through the security options in Stores>Settings>Configuration>General>Web>Session Validation Settings.
- Validate REMOTE_ADDR — Set to Yes to verify that the IP address of a request matches what is stored in the $_SESSION variable.
- Validate HTTP_VIA — Set to Yes to verify that the proxy address of an incoming request matches what is stored in the $_SESSION variable.
- Validate HTTP_X_FORWARDED_FOR — Set to Yes to verify that the forwarded-for address of a request matches what is stored in the $_SESSION variable.
- Validate HTTP_USER_AGENT — Set to Yes to verify that the browser or device that is used to access the store during a session matches what is stored in the $_SESSION variable.
The first three settings ensure that requests are coming through the same proxy or IP address. This matters because many hackers use a proxy to mask their actual location. However, setting these to yes could have the unintended consequence of blocking users with a legitimate proxy. For instance, some companies use a proxy to secure their networks. Lastly, Validate HTTP_USER_AGENT just means that the user is accessing the store from the same browser throughout the session.
You may need to experiment with these configurations on your store and adjust them over time. Perhaps you enable them during an active carding attack, but relax them after other security measures are in-place.