In collaboration with Worldpay from FIS, Payrix 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 may be potential card testing, but additionally, we worked in partnership with the Card Brands to produce a list below of best practices to assist with any mitigation efforts:
Leverage authentication and CAPTCHA controls to prevent automated transaction initiation by bots or scripts (e.g., 5 authorizations from one IP address or Account)
Utilize fraud detection systems that support device fingerprinting and botnet detection
Use a layered validation approach that employs Card Validation Codes and Address Verification Services
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
Inject random pauses (i.e., throttling) when checking an account to slow brute force attacks that are dependent on time, especially for Bank Identification Numbers (BINs) that have been determined to have a high fraud incidence
Include IP address with multiple failed card payment data in a fraud detection blacklist database for review and analysis
In addition to velocity checks for small and large transactions, use velocity checks for low amounts or authorization-only transactions
Look for excessive usage and bandwidth consumption from a single user
Look for multiple tracking elements in a purchase linked to the same device (e.g., multiple transactions with different cards, using the same e-mail address and same device ID)
Look for logins on a single account coming from many IP addresses
Review logins with suspicious passwords that hackers commonly use
Lock out an account if a user guesses the username/password and any account authentication data incorrectly on “x” number of login attempts