Mitigate Card Testing Attacks - Best Practices

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: 

Actions

• Leverage authentication and CAPTCHA controls to prevent automated transaction initiation by bots or scripts (for example, 5 authorizations from one IP address or account).

• Use 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 (in other words, 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.

Awareness

• Look for excessive usage and bandwidth consumption from a single user.

• 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 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.

PayFields Best Practices

The Payrix PayFields and PayFrame products are typically used as a hosted checkout field on public payment pages, such as shopping card 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 purposes.

We recommend following a few best practices when using PayFields in a public form to ensure the security of the information and to deter anyone from using PayFields for card testing:

Ensure that the API key that is used with the PayFields is a public API key:

We have two types of API keys: a public and a private key. The public key is limited to certain POST calls, while a private key can be used for GET calls and can be used to gain more access to an account. If a payment page is public, a private API key should never be used in that page.

Created a dedicated user to host the API key:

The API key will inherit the level of access from the user that it is associated with. Creating a specific user that is designated as the user for the API key will allow you to limit the access that the API key is granted.

Only utilize PayFields to create tokens:

This might seem counterintuitive, because PayFields has the ability to create transactions right there, but this can add a great layer of security. The following outlines the steps that you can take to integrate in this manner:

This allows you to create velocity controls within your own environment. If you notice traffic coming from a specific source that is higher than expected, you can block it before it even comes through to Payrix

Add additional Transaction decisions

We recommend adding a failed authorization rule on all merchants. In the event that someone does start to use the page for card testing, this will mitigate the exposure, as they will continue to get blocked when the number of declines exceeds the rule in place, which will ultimately guide them to go elsewhere.

Create a rolling API key, so that there isn’t one API key in use for more than a specific timeframe

In the event that an API key is compromised, the shorter the amount of time it remains active will help to mitigate any potential undesired outcomes. What you can do to avoid this is to create a rolling API key so that a new API key is used every 6 hours. Below are the steps that you can use to complete this.