Card Testing, also known as card spinning, refers to the malicious practice of attempting many transactions within a short period, with many different cards, all done by one bad actor or group.

Stax’s Security and Risk Teams monitor merchant transaction data via alerts and daily reporting to identify card patterns and validity and associated transaction validity. This proactive monitoring process is a card brand requirement and is important because any unchecked card testing may result in significant monetary loss for both the merchant and Stax.

Identification

Stax’s Security and Risk teams usually identify card testing, but in some cases, it could be identified by the merchant. Many factors contribute to determining whether a merchant is experiencing card testing, and deeper analysis by the Risk team is often necessary to confirm this activity. Defining factors that may contribute to this conclusion are:

• High-risk error messages
• A high percentage of failed transactions
• The name field is falsified or randomly generated
• Same email over multiple transactions
• Similar or repeated bins

Card Testing confirmed by Stax

1. If card testing activity is excessive and ongoing, the Risk team will temporarily disable payment processing until it is under control. The Risk team will try not to disable payment processing if they see the activity has stopped.
2. The Risk team will create an internal risk ticket and notify the support team.
3. Once the support team is notified, they will email the merchant to alert them of the suspected fraudulent activity and whether payment processing has been disabled on the merchant's account.
4. The merchant must confirm that they are implementing stricter security measures so that end customers can access the merchant's payments page. Best practices include:
   1. Recaptcha
   2. The website payment link is placed behind a customer portal accessed through a login page.
5. If stricter security controls are not implemented, the Risk team may place the merchant's account on a risk hold and hold funds until confirmation is received that measures are being taken to prevent a future card testing event from occurring.
6. Once this is confirmed by support, the Risk team will re-enable payment processing (if applicable). If a merchant uses payment links and payment processing is re-enabled, a new payment link/hosted payment token is automatically created.
7. The merchant should then submit a Support Ticket for the following:
   1. If voids are possible, they will be executed by the Support team. If not, successful transactions will be refunded.
   2. The Support team will provide a list to the merchant of all successful transactions that have been refunded.
   3. Stax’s Support Engineering team will run established SQL queries to produce a list of payment methods used during the card testing.
   4. The payment methods are then marked to be purged in our tokenization database.
   5. The failed transactions are removed from the merchant's invoicing record.

Merchant suspected Card Testing

1. A Support Ticket should be created to alert the Support team.
2. The Support Team will create an internal risk ticket alerting the Risk and Security teams and ensure payment processing is disabled for the merchant's account.
3. The merchant must confirm that the merchant is implementing stricter security measures so that end customers can access the merchant's payments page. Best practices include:
   1. Recaptcha
   2. The website payment link is placed behind a customer portal accessed through a login page.
4. If stricter security controls are not implemented, the Risk team may place the account on a risk hold and hold funds until confirmation is received that measures are being taken to prevent a future card testing event from occurring.
5. Once this is confirmed, payment processing will be re-enabled. If a merchant uses payment links and payment processing is re-enabled on a merchant's account, a new payment link/hosted payment token is automatically created.
6. If voids are possible, they will be executed by the Support team. If not, successful transactions will be refunded.
7. The Support team will provide a list to the Partner of all successful transactions that have been refunded.
8. Stax’s Support Engineering team will run established SQL queries to produce a list of payment methods used during the card testing.
9. The payment methods are then marked to be purged in our tokenization database.
10. The failed transactions are removed from the merchant's invoicing record.