Someone has been using an automated script to test credit cards by trying to place orders through the checkout process of an ecomm website I help maintain. I'm talking about trying to place 40k orders in 5 hours. I am looking for ideas to prevent this. The normal checkout process is add to cart, select shipping address, input payment information, final confirmation page.

We've discussed using captcha during the checkout process, we have velocity check where after so many orders by the same account, in the same day, do not take any more orders from that account. New accounts are created and they start over again using the newly created account.

Any ideas on preventing this activity is greatly appreciated.

  • Won't stop it entirely, but minimising the information returned to users in the event of a failure can make your site less attractive to attackers - in particular, if you're distinguishing between an invalid card number, an invalid expiry date, and a data mismatch, that can be really helpful to an attacker trying to verify details, even without actually placing orders.
    – Matthew
    Commented Nov 2, 2016 at 15:29
  • Great suggestion. We have actually done what you suggest and return a message like saying something like invalid information but not saying what the invalid data was. Thanks for the quick response Matthew.
    – Joe
    Commented Nov 2, 2016 at 15:32
  • Perhaps a job for fail2ban?
    – Anders
    Commented Nov 2, 2016 at 16:48
  • Stopping multiple requests from the same account isn't a problem, so make account creation harder (captcha) the new shiny Google checkboxes are so easy, the majority of users will hardly be impacted.
    – Namaskar
    Commented Nov 2, 2016 at 17:49
  • Why did you discount using CAPTCHA? Commented Nov 3, 2016 at 18:49

1 Answer 1


There are many possible steps to take to make your site less interesting to attackers trying to verify credit card details. For example:

  • By restricting access to the payment information screen to customers who have completed previous steps (add item to basket, click checkout, enter shipping address), it increases the number of steps an attacker needs to emulate to get useful information.
  • By using CSRF protection methods, it becomes slightly harder to replay requests, just modifying key details. By linking the CSRF generation to rate protection means, it's possible to reject inordinate numbers of requests before making calls to bank systems - simply drop any request without a valid CSRF token, and don't provide one to any session which is trying requests too frequently.
  • Reducing the information returned from bank requests makes the system less useful to an attacker. If they can determine which specific piece of information is incorrect, they can reduce the number of attempts needed to get all data for a given card: consider an API which returns "invalid expiry month", "invalid expiry year" based on the information provided. It would require a maximum of 12 requests to confirm month, and 10 to confirm most card years (very few cards have more than 10 year expiry) - 22 requests at most. By contrast, the same API returning "invalid details" for both would require up to 120 (12*10) requests to be sure of finding the same information. This difference increases if there are further details grouped in this way, such as address details or CVV.
  • Limiting the number of attempts for a given IP address in a given time could be useful, but beware of losing legitimate customers if you have a lot of mobile traffic, which often appears from specific IP addresses for a given phone provider.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .