Page Comparison

...

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:

Note

Actions

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

Tip

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 (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

...

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 utilized in a public space, they can be vulnerable to to be used for card testing purposes.

It is recommend to follow a few best practices when utilizing 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 may seem counterintuitive, since PayFields has the abilty to create transactions right there, but this can add a great layer of security. Below I will outline the steps that you can take to integrate in this manner.

Expand

title	Using PayFields to Create Tokens Only

Create a login that will be dedicated to payfield transactions
Create a public API key associated with this login
Set the permissions on the login to only be able to create tokens
Set up your PayFields to only create tokens
When the customer runs their payment request, you will receive the token ID
Run a sale transaction from your host server via the Payrix API using the token
Respond to the customer with the result of the transaction

This will allow 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 utilized every 6 hours. Below are the steps that you can use to completed this.