I've got a manually-unmanageable number accounts created by bot activity I'd like to inactivate (not purge) while we test out improved captcha. Can anyone point me to the code invoked by the constituent menu or possibly already have code written for this. I'm thinking there's probably more to it than updating inactive and inactive_reason in T_CUSTOMER.
Thanks!
I thought it might be useful to pass along an issue we recently dealt with. It's not exactly the same as this, but our experience may prompt others to take a deeper look at that's happening in their environments. The connection with this thread is that what happened to us did include the creation of some bogus accounts, although we have no reason to believe that the accounts were created by a bot since there were only three (3).
What concerned us was when we discovered thousands of attempted credit card transactions associated with these accounts. We stumbled on this occurrence while reviewing transaction logs on our payment gateway processor which we don't routinely do. We typically use the logs to help troubleshoot problems. We don't routinely review them. We recently switched payment processors and were reviewing all transactions in the logs after the switch to be sure transactions were flowing correctly. During that review we discovered a one hour period where there were thousands of failed transactions. These transactions also showed up in Tessitura and we were ultimately able to trace them back to bot activity on our web site where the bot was cycling through card number / expiration date / CVV combinations.
The point of mentioning this, is that bogus accounts were used for these transactions and had those accounts been either inactive or purged the bot activity would not have been possible (without creating additional bogus accounts). We're TNEW clients and the captcha functionality available readily handles stopping bot activity that creates accounts. However, it doesn't address bot activity that attempts to process a transaction - most likely to only test the validity of a card number / expiration date combination.
At the end of the day we discovered weaknesses with our AVS and CVV settings that we've tightened which has stopped the bot activity. But, it was distressing to discover that our systems had been used inappropriately to test card number combinations for further exploitation. Standard reconciliation practices didn't catch this activity because most of the authorizations failed and were automatically reversed. Those that were successful (3 transactions out of thousands) passed standard reconciliation audits since they were successful and the small transaction amounts were never disputed.
To help determine the scope of this activity we developed a fairly simple frequency analysis query that flags situations where we have more transactions in a period of time on a single account than would by considered normal. We are now looking at using this as a regularly run audit tool to expose these situations before they grow legs and result in any kind of significant loss.
Lesson? Use the available tools to rid your systems of bogus accounts. But also consider looking for bogus transactions that pass reconciliation audit.
These are great tips, Dan, and I'm sorry that you had to deal with this, but also glad you have a good plan in place to catch if it happens again.
I'll say in general that while there is no "magic bullet" to stop all bot incidents on an eCommerce site, we have found in practice that the more roadblocks you can put in place (reCAPTCHA, AVS settings, and hosted payments are the primary ones), the more likely you are to stop an incident.
For those organizations using Hosting Services, we regularly monitor the environment for large numbers of transaction attempts as you are doing, and we have an internal group that meets regularly to analyze these kinds of incidents and ensure we have procedures in place to proactively avoid them. I'll just note for anyone else reading here that if you notice an incident like this, your best bet is to contact Tessitura Support and we can guide you through next steps.
I want to echo what Patrick said about contacting support. We did, and they were instrumental in helping us navigate the situation we encountered. The primary objective was to stop the activity from occuring. Quick and helpful response from support enabled us to do this and we observed an immediate cessation of the activity once we enabled reCaptcha and improved our AVS settings. We also moved quickly to implement hosted payments which was on our radar anyway.
Thanks Patrick!
Patrick Schley (Past Staff Member)
Thanks for the information about the Tessitura Team's work to help member organizations monitor T-New and inappropriate CC Transactions.
So, I'm wondering If I should be asking here for SQL queries (or outlines of SQL queries) from Dan & John and Gawain about how they discovered their problems? Or are all of these practices already being applied to our systems at this point and the network team. And I should trust that you will notify us if this kind of activity is going on.
--Tom