Card Testing Attacks about bh-wc-checkout-rate-limiter HOT 3 OPEN

That is correct about how it works.

I do not have success stories because it's not recording much. With debug logging enabled, it can be seen how the plugin is counting and stopping orders. But it stops things before the order is created, so it's not obvious in most cases that it has even taken effect.

More importantly, I've never heard anyone say they had this plugin installed and they then had a card-attack.

That said, there is room to improve. I think I should add a rate limit on similar carts – I think the typical card attack is adding the same product(s) to the cart and placing the same order each time.

If you want success stories and you are a developer, I would change the point where the rate-limiting happens from currently the AJAX action where clicking the Place Order button happens to the process payment hooks and I would preserve the newly created order objects and set a new custom status of "rate-limited" and then add an admin notice and email to inform the site owner what has happened.

Additionally, if the plugin were to allow the orders to be created, the metadata could be gathered, sent to me, and used to determine more rules for preventing the problem.

How much did the card attack cost the company?

from bh-wc-checkout-rate-limiter.

from bh-wc-checkout-rate-limiter.

As I recall, when the card attack hit the company I was working for, there were per-transaction fees that went into the thousands of dollars but were forgiven by the processor. I can't remember who the processor was.

A bigger issue was that they cut off processing for the day! We quickly implemented "offline credit card" gateway which records the number, and someone manually punched in the card details in the gateway's website a couple of days later. I've been meaning to upload that code to GitHub too. AIUI, it is PCI compliant to record card details until the transaction is run.

The idea of "abandoned" plugins is never clear. Some are so simple that what worked 18 months ago should work in 18 years. For my own plugins, I like to follow code standards as best I can, write a reasonable amount of automated tests, and write a half-decent README. Then, if I don't touch this plugin for years, I think people can be relatively confident in it.

You can see test coverage at: https://brianhenryie.github.io/bh-wc-checkout-rate-limiter/

I do plan to update it sometime in the next few months. The long goal is to have the automated tests run on every new WordPress + WooCommerce release. Then automatically update the README to reflect that.

I've begun that: https://bhwp.ie/2023/11/add-playwright-e2e-tests-to-existing-wordpress-plugins/

There's also the new WooCommerce Blocks Checkout which this does not work with. It should be easy to add compatibility, and the new checkout actually creates the order long before the payment is processed, so it will be natural enough to mark orders as "fraud" rather than the lack of recording that's currently happening.

from bh-wc-checkout-rate-limiter.