Several of Joinery's clients recently started seeing a dramatic increase in fraudulent card-testing behavior on CiviCRM sites using the Stripe payment processor. We've resolved this problem for them with some great new features in the CiviCRM extension ecosystem, thanks to the contributions from open-source developers and CiviCRM partners.
If you're seeing a large number of failed or fraudulent transactions in your Stripe dashboard, you may want to look into the solutions mentioned below.
Is this affecting me?
If it is, your Stripe.com payments page probably looks a lot like this – like, pages and pages of entries like this:
What is card testing?
Card testing is a way for credit card thieves to test whether a stolen credit card is still active, by making a small donation on your site. If the transaction is successful, they know the card is still good for making larger purchases elsewhere. For more background, Stripe explains the general nature of card testing in its article, Protect yourself from card testing.
Is this a serious problem?
Although this activity is obviously fraudulent and criminal, it does not mean that someone is stealing anything (neither money nor information) from you or your contacts. But left un-checked it could have some negative consequences for you. We've heard from people who've had one or more of these things happen as a result:
- Stripe account suspension: Stripe determines that there's too much card-testing activity on the site, and they disable the organization's account and refuse to process payments until the problem is resolved.
- Complaints from card theft victims: A stolen card is used by a thief to make a donation, and the organization receives an angry phone call from the card owner demanding an explanation (and a refund, of course).
- Site downtime or slow performance: The organization's site becomes very slow to use, or becomes completely unresponsive, due to a high volume of automated card-testing activity.
How we've addressed this on client sites:
The solution for Joinery's clients has been fairly simple, thanks to the work of several open-source extension developers and CiviCRM partners.
If you're seeing this kind of behavior on your site, there's a good chance the following simple steps will take care of it:
- Update to the latest version of these extensions:
- Obtain an api key for Google's reCAPTCHA v3 (this reCAPTCHA requires no interaction from the user, so no need for those annoying "I'm not a robot" checkboxes).
- In CiviCRM, visit Administer->System Settings->Form Protection Settings and configure the Form Protection extension to use reCAPTCHA v3 on all forms – or at the very least, on all public-facing forms where payment via Stripe is an option.
- Test your payment forms yourself to ensure payments are being processed successfully; do this as an anonymous user (or with whatever non-administrative user role that your contacts would be using).
Can somebody help me with this?
If the above isn't working for you, then you may have a unique configuration that needs more specialized help. Or, you might just want someone to help. You can contact Joinery, or any CiviCRM expert, to help you out.
Who can we thank for this?
If you're glad, as I am, that open-source developers and CiviCRM partners are putting in the hard work to make these solutions available, you might want to support them with a kind word, a business referral, or in some other way. For the above solutions, some of the contributors I'm aware of are:
- Matt Wire, MJW Consulting
- John Kingsnorth
- Jamie McClelland, Progressive Technology Project
- Rich Lott, Artful Robot
- Mathieu Lutfy, Symbiotic
- Jon Goldberg, Megaphone Technology Consulting
- Eli Lisseck, AGH Strategies
- GitLab user "BobS"
Great idea to do a blog post about this. I was really impressed with how the community came together to share information, ideas and solutions during the peak of the attacks. A testament to the benefits of open source software, and the amazing CiviCRM community. Thanks everyone.
I'd also add that the latest version of the Firewall extension is a very important part of the mitigation strategies: https://civicrm.org/extensions/firewall
@JKingsnorth: Right, Firewall is required now by the Stripe extension. But I'll make an edit to mention it specifically.
We had the issue last December on the donation form (thousands of 10 euros payment, all of them ended up as "denied" by Stripe). I saw in Mattermost that it is advised to set a higher minimum amount (i.e. 15 euros).
I'd just like to say thank you to everyone listed above who supported this work and for the time you've spent to post this blog.
This will absolutely be something that will help so many organisations and you're effort is valued so much by the community.
Just to muddy the waters...!
Privacy respecting people don't ask friends to use Google reCaptcha v3, and law abiding organsiations probably don't let their European/UK (at least) friends use it without *first* obtaining consent. As I understand from what I've read, it sends an enormous amount of personal data - basically anything it can obtain including mouse movements and keystrokes (that password you just typed?..) and combines it with other data on you personally that google has tracked to Google.
Much like a vampire, Google builds these tools so that you (desperate site admins faced with a sudden army of card testing abuse bots and needing protection quick) invite it in. Much like a vampire it then sucks the lifeblood (well, personal data) out of your users.
I'm awkward and fussy and a bit prim at times and I just plain don't like this. We've seen time and again that these giant companies don't have our best interests at heart and can use our personal data against us and withdraw services, in an instant.
So I'm working on another approach; another firewall type thing. It's called Moat (a moat is a defensive river that they used to build around castles and cities).
Moat provides a highly configurable dynamic firewall-type system for extensions to use. It’s based on setting rate limits on certain activities, and then taking certain actions when a flood of that occurs.
- There should not be 2 or more card fraud errors from a given IP address within a week.
- A hash/token for something must only be used once.
- There should not be more than 2 contact form submissions from the same email in a day, and not more than 5 in a week.
Moat can be configured with different settings for different alert levels, and automatically bump itself up a level in response to a certain flood - that's the dynamic part. It can also provide security tokens of various types and even comes with a picture based CAPTCHA - or half of one (ask me).
It has been used in the wild and was successful at fending off a card testing attack. But it's still new, and I'm really posting here to raise interest in discussing and developing it. Note that Moat doesn't do anything by itself; installing it will do nothing to protect you; but rather it provides tools for other extensions to provide suitable protection for whatever they need.
So far the only implementation I've done for Moat is Inlay Pay (embeddable payment forms), which supports the CAPTCHA if enabled, and I've also done a fork of Stripe that uses Moat instead of Firewall (I don't mean to fragment the Stripe extension; I have no intention of this being a permanent fork).
If you're interested in discussing this, please @artfulrobot me directly or in the dev channel of the chat at https://chat.civicrm.org
I am very glad to have found this. Dec 31, 2022 / Jan 1, 2023 we experienced massive (140,400 attempts within 18 hours) card testing activity on our Stripe account. I hope that these extensions will prevent further activity like this. Thank you for your work on this.