I have a simple product ordering form.

A hacker is attempting to validate stolen credit card numbers by making two orders per minute with a bot.

99% of the orders are declined but some are completed. Which tells the hacker that credit card is a valid and active card.

Using a CAPTCHA or similar to prevent these attacks is unfortunately not an option.

Here is my strategy for limiting the attack:

  • Set a rate limit of one order per IP per five minutes. Do not allow multiple submissions to the same form from the same IP within five minutes.
  • Record every IP address that submits to the order form.
  • Fetch the recent order data from the shopping cart API.
  • Correlate the recent order IP's with every new order's IP.
  • If the rate limit is exceeded for a matched IP then discard the order submissions.
  • If the rate limit is exceeded for a matched IP then block the order submissions IP.

Is there a pattern that already exists for this kind of credit card transaction rate limiting?

Recommendations for existing libraries which use this pattern would also help me to research how others have solved this problem.


closed as off-topic by Jeff Ferland Mar 11 '15 at 22:43

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • I have edited my question. Please review. – dbasch Mar 12 '15 at 15:18

I would say: Ask your acquirer. If you roll your own library or use a 3rd party service, the rate limiting might not Count towards you in "fraud fighting score" at all, and you will still be liable if the order makes it through.

If you select such services by your acquirer, then the acquirer knows that you are actively fighting against fraud, and the acquirer might swallow any fraud that happens to originate from you, and you might also even get lower rates.

I would say, one great thing to do is block so the issuing country of the credit card must match the IP country of the visitor. Then you have closed the door for a large amount of fraud. If your service is only usable in a few countries, you can also lock down so only those countries (both when it comes to IP and card issuance country) is permitted.

Another thing you can do is to use Verified by visa/3DSecure. VBV/3DS will trigger even if the expiry date or CVV is invalid, so the customer will not get to know if the card is valid unless the customer does authenticate Verified By Visa/3DSecure correctly.

You can use VBV/3DS in 2 modes: Either you use it in the "normal" mode, where cards without VBV/3DS will go through without problems. But you can also ask your acquirer to set your service to REQUIRE VBV/3DS, eg if the card issuer does not support VBV/3DS, the transaction is rejected. Not all acquirers might have this service available.

  • Yes, you are correct. I should ask the acquirer if they have any fraud protection features that would be useful for this situation. Thanks! – dbasch Mar 11 '15 at 21:49

You didn't specify what your site is built with. If by chance you're using Ruby, there is an excellent rack-attack library by Kickstarter.

Not the answer you're looking for? Browse other questions tagged or ask your own question.