--- title: "Mitigate Card Testing Attacks Best Practices" slug: "mitigate-card-testing-attacks-best-practices" updated: 2026-04-03T20:14:07Z published: 2026-04-03T20:14:07Z --- > ## Documentation Index > Fetch the complete documentation index at: https://resource.payrix.com/llms.txt > Use this file to discover all available pages before exploring further. # Mitigate Card Testing Attacks Best Practices **Card** **testing**, also called *carding*, is a fraudulent practice where criminals use randomly generated or stolen credit card information to test whether the cards are valid and to determine their available balance. Compromised cards are then resold to other fraudsters. In collaboration with Worldpay, Worldpay for Platforms has seen an increase in the number of card testing attacks globally and we advise you and any of your service providers to be diligent, increase your awareness, and review your current detection controls to help prevent these types of fraudulent attacks. We will continue to notify you of any suspicious authorization activity that might be potential card testing, but additionally, we’ve worked in partnership with the major credit card brands to compile a list of best practices to support card testing mitigation efforts: ## Take Action Implement these measures to enhance security and prevent card testing: - Analyze time zone differences and browser language consistency from the cardholder’s IP address and device. Classify these transactions as potentially high risk and perform more stringent reviews. Implement multifactor authentication (MFA) to add an extra layer of security for transaction initiation and account access. - In addition to velocity checks for small and large transactions, use velocity checks for low amounts or authorization-only transactions. - Include IP addresses with multiple failed card payment data in a fraud detection blacklist database for review and analysis. - Inject random pauses, or *throttling*, when checking an account to slow brute force attacks that are dependent on time, especially for each bank identification number (BIN) that has been determined to have a high fraud incidence. - Leverage authentication and CAPTCHA controls to prevent automated transaction initiation by bots or scripts. For example, five authorizations from one IP address or account. - Refunding successful card testing payments does not prevent or guarantee that a chargeback settle in the merchant's favor. Instead, allow the chargeback process to play out and respond appropriately to each dispute. - Use a layered validation approach that employs Card Validation Codes and address verification service (AVS). - Use fraud detection systems that support device fingerprinting and botnet detection. ## Maintain Awareness Regularly monitor these indicators to identify and mitigate potential risks: - Lock an account if a user guesses the username or password and any account authentication data incorrectly after a set number of login attempts. - Look for excessive usage and bandwidth consumption from a single user. - Look for logins on a single account coming from many IP addresses. - Look for multiple tracking elements in a purchase linked to the same device (for example, multiple transactions with different cards using the same email address and the same device ID). - Review logins with suspicious passwords that hackers commonly use. ## Protect Hosted Payments [PayFields](https://docs.worldpay.com/apis/payrix/dev-int-guide/hosted-payment-fields/payfields) and [PayFrame](https://docs.worldpay.com/apis/payrix/dev-int-guide/hosted-payment-form/payframe) products are typically used as a hosted checkout field on public payment pages, such as shopping cart checkout, company payment pages, donation pages, and other publicly viewable payment pages. As these payment pages can be viewed and used in a public space, they can be vulnerable to being used for card testing attacks. Included are some best practices for using PayFields in a public form to ensure the security of the information and to deter anyone from using PayFields or PayFrame for card testing: - Add a Failed Authorization Decision rule. - Create payment tokens. - Implement a rolling API key system. - Protect your API keys. - Use transaction session keys. For a comprehensive guide on implementing these cybersecurity measures for PayFields or PayFrame, see [Hosted Payments Best Practices](https://docs.worldpay.com/apis/payrix/dev-int-guide/hosted-payment-fields/hosted-payments-best-practices) on the Worldpay Developer Hub for Payrix Pro. A required security setting that uses SMS/text or an authenticator app to receive an authentication code from the Payrix Pro platform. This provides an additional security layer for users logging in to the portal or authenticating certain API calls. The first six digits of a card number (including credit cards, debit cards, and some gift cards) that identify the card type, issuing bank, and card product. The verification of a cardholder’s billing address in a transaction against the issuing bank’s address information for the cardholder. AVS is primarily used as a fraud prevention tool for eCommerce transactions. A Payrix Pro platform-hosted payment solution for merchants to securely accept payments on their website or checkout page without directly handling sensitive cardholder data. PayFields embeds iframes on the payment page to support a custom look and feel and to provide PCI compliance through a Payrix Pro PCI Level 1 Certification. A Payrix Pro platform-hosted payment solution that includes basic customization options and requires minimal development effort to implement. PayFrame embeds a Payrix Pro platform-hosted payment form on a merchant’s checkout page.