nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Addressing thousands of declines

JD Piland

Hello all,

We've had a couple days already this month with thousands of declines. Two records (both now deleted) are responsible for 17k+ declines--nearly all by IP. Thankfully, they are being caught and declined. That said, we get these types of attempts, but we're already at 60% of 2019's total declines. I'm just wondering what we can do to prevent these that doesn't also hamper the donor experience. CAPTCHA is available, but I'm not sure that's going to help our conversion (although maybe a worthwhile test).

Anyway, open to ideas beyond that. Thanks in advance!

bbcon-2019-presentation---bri-macbain-at-edge-web-apps.pdf

Find more posts tagged with

LuminateOnline

Comments

Bri MacBain

Hi JD,

There's a few options here, the BC SPCA had a similar issue a while back- https://spca.bc.ca/donations/make-a-donation/ uses an LO integration for WordPress to deal with this (additional security layers that are unobtrusive to users but block bots/card running).

Derek Martin

JD,

Have you contacted Support for help?

Brian Mucha

...additional security layers that are unobtrusive to users but block bots/card running...

I'm interested. Can you elaborate on what you added?

BPM

Bri MacBain

Brian Mucha:

...additional security layers that are unobtrusive to users but block bots/card running...

I'm interested. Can you elaborate on what you added?

BPM

Sure, no problem- I added a honeypot trap, timestamp detector, and a measurement of failures per ip address that can result in a bans at the plugin level,and I integrated google's invisible recaptcha v3 (no challenges, just monitors your site behaviour to see if you're a real user and blocks with an error message if you are below a certain human threshold). There's a couple changes/new security things I'll be adding shortly to it as well (the security for the integration changes over time as we swap out old methods via security updates when they are no longer effective). I also encourage clients to install a decent application level firewall/bot list like WordFence security. Overall that cuts down on card running!

Edit: I actually gave a presentation of this at BBCon this year, I've uploaded a pdf if anyone wants to review it.

bbcon-2019-presentation---bri-macbain-at-edge-web-apps.pdf

Sean Staggs

We also added a honeypot field (https://secure.nationalmssociety.org/site/Donation2?df_id=63293&63293.donation=form1&mfc_pref=T) and made the form two pages. If a bot populates the field, the "next" button doesn't go to the next page. This cut down on the card running as well as those bots creating bogus records in our system. We instituted the honeypot field on our event donation forms (example: https://secure.nationalmssociety.org/site/Donation2?62768.donation=form1&idb=1744579740&df_id=62768&FR_ID=30911&mfc_pref=T&PROXY_ID=9913980&PROXY_TYPE=20) as well but didn't make they two page forms. We've not a seen any decline / issues with completion rates since the switchover.

JD Piland

Hi all,

Thanks for the feedback and considerations. It wasn't quite a priority at the time, but we've started seeing even more declines, especially in the past week -- and even today. So, here I am again.

We don't use Wordpress, so the plugin doesn't appear to be an option.

Sean Staggs‍ - It seems your honeypot solution would be most relevant for our purposes. Would you mind sharing how you implemented that field?

Thanks again!

Daniel Hartanto

I am interested on this topic too and wanted to see if anything we could tap into due to we have also been seeing this carding attempts in bulk hitting our donation forms.

In my opinion, although the honeypot and these stated solutions will help stemmed issue associated with bots spamming through the front-facing form, it might not likely addressed those attackers that hits the end point without having to go through the front-facing form (i.e. cURL POST or REST API submission done directly through tools like POSTMAN)

The non API donation 2 forms have that CAPTCHA data element that I believe is a server-side which will likely address the above, however this is currently not compatible with LO API forms and not to mention the 'intrusive' aspect adding extra steps for end user to donate.

Has anyone else experiencing this type of carding attack where the hacker might not necessarily hit your actual front facing form? Pretty sure there's that honeypot schema on the non API (donation 2) forms yet we are still seeing attacks time to time despite.

Thanks in advance!

regards,

Daniel

Jessica Sotelo

Sean, is your honeypot solution still working successfully? Would be grateful to hear an update.

Thanks,

Jessica