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 and PayFrame products are typically used as a hosted checkout component on public payment pages, such as shopping cart checkout, company payment pages, or donation pages. These payment options are initialized and viewable in client-side browsers, and are vulnerable to card testing attacks. You must apply a layered security approach to ensure the security of payment data and effectively mitigate card testing attacks.
To apply layered security to PayFields or PayFrame integrations:
Always use pre-defined form input components provided by PayFields or PayFrame.
Generate transaction session keys server-side and provide to the client at runtime to authenticate all payment requests with the lowest practical duration and usage limits for your integration.
Generate unique checkout, cart, or transaction identifiers server-side to link checkout flows with related transaction session key generation requests, payment attempts, customers, and potential fraud events.
Tokenize payment data before reuse.
Configure transaction risk decisions for consumer and merchant monitoring to handle failed authorizations.
Apply server-side rate limiting to the following request types:
Payment attempts
Tokenization requests
Transaction session key creation requests
Important!
Transaction session keys help reduce risk with built-in duration and usage controls. However, you must apply server-side rate limits for generating new transaction session keys to prevent attackers from bypassing key usage and transaction request limits by refreshing the page.
Apply Additional Controls for Shared Tokens and Guest Checkouts
Transaction session keys are scoped to one merchant and cannot authenticate partner-level requests to create reusable payment tokens across merchants. Shared checkout flows, such as platforms or marketplaces, require public API keys to authenticate tokenization and transaction requests. Treat public keys as exposed and untrusted, and do not rely on them as a standalone security control.
Guest checkout pages can authenticate requests using transaction session keys, but carry higher risk because they lack user identity, enabling repeated unauthenticated access to payment functionality.
To mitigate card testing in platforms, marketplaces, and guest checkouts, apply the following additional security controls:
Apply bot mitigation, such as CAPTCHA or behavioral validation.
Monitor and rotate all public API keys routinely and whenever you suspect exposure or misuse.
Monitor repeated failures, excessive session generation, and unusual usage patterns.
Apply additional server-side controls to throttle or block suspicious repeated attempts using browser or device fingerprinting.
Require customer login or user authentication when possible.
When customer association is not available, generate unique checkout, cart, or transaction identifiers server-side and associate them with requests authenticated using your public API key.
For hosted payments security best practices, see the following articles on the Worldpay Developer Hub for Payrix Pro: