Feature Description

We have implemented three rules for detecting and preventing this card testing attacks:

I) Card <> IP Blocking for Merchant : If there are X number of unsuccessful payment attempts from a single IP Address for a specific merchant, then that combination of Card <> IP will be blocked for that merchant for a particular duration.

II) Card Blocking for Guest Users for Merchant: If there are X number of unsuccessful payment attempts for a single card, then guest user payments will be blocked for that card and that merchant for a particular duration. Logged in customers will still be able to use that card for payment.

III) Customer ID Blocking for Merchant: If there are X number of unsuccessful payment attempts from a single Customer ID, then that customer ID will be blocked from making any payments for a particular duration.

These unsuccessful payment thresholds and duration for blocking is configurable and stored in database.
Whether the merchants want these rules to be enabled/disabled, that is also configurable.

Possible Implementation

The attacker gets the client_secret from the payment intent create call which happens through our SDK, and uses the client_secret to hit the /confirm API repeatedly with different sets of card numbers and CVC.

A method validate_request_with_state has been created in the GetTracker trait which enforces the three above mentioned rules depending on the business_profile config. The validate_request_with_state method internally calls validate_card_ip_blocking_for_business_profile method, validate_guest_user_card_blocking_for_business_profile method and validate_customer_id_blocking_for_business_profile method for performing the below validations:

I) Card<>IP Blocking: A fingerprint is generated for the card which is unique to the business_profile (by using a hash key which is unique to the profile and stored as card_testing_secret_key in business_profile). This is done so that the cards are blocked at a profile level. The IP Address is fetched from the payment intent create request, and then for each unsuccessful payment attempt, the value of the redis key CardFingerprint<>IP is increased by 1, and after it reaches a certain threshold, it is blocked.

II) Guest User Card Blocking: A fingerprint is generated for the card which is unique to the business_profile (by using a hash key which is unique to the profile and stored as card_testing_secret_key in business_profile). This is done so that the cards are not blocked at a profile level. For each unsuccessful payment attempt, the value of the redis key CardFingerprint is increased by 1, and after it reaches a certain threshold, it is blocked, but only for guest users. Logged in customers can still make payments with that card.

III) Customer ID Blocking: The customer_id is fetched from the payment intent create call request, and then for each unsuccessful payment attempt, the value of redis key CardFingerprint<>Profile is increased by 1, and after it reaches a certain threshold, it is blocked.

Have you spent some time checking if this feature request has been raised before?

• I checked and didn't find a similar issue

Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to submit a PR?

Yes, I am willing to submit a PR!