Donation forms are meant to be easy to use. Easy enough to use implies that it may convert the casual website visitor into a donor. We are currently using the fields:

Card Type Card Number Card Expiry Name on Card CCV Number $ Amount

...and it appears to be working. The issue now is that our payment gateway is being used for fraudelent activities. (A discussion for another forum - our payment gateway is being used for a whole lot of $1 payments against a pattern of "Name on Card" and "Card Number" attempts. Of course the baddy behind the operation will see a "Thank You for your payment" page and then record that against a working credit card).

We are dealing with issues re: charge backs and raising the minimum donation amount to $2. But I don't think that's going to solve the issue.

Other thoughts are to:

  • introduce a Captcha field
  • introduce a mandatory: street address and/or phone number field

...but I am not sure whether they'll eradicate the problem. Furthermore, it may deter the authentic donors.

What are your thoughts?

  • 1
    Approaching from another angle -- sounds like you're running your own credit card transactions. You might want to consider a vendor that will handle CC payments. There's quite a few out there, some have reasonable rates for non-profits. This can move the burden of preventing fraud to another party that will have more resources to block the baddies.
    – Voodoo
    Dec 15, 2011 at 18:24

3 Answers 3


You could introduce captcha when you have a suspicions transaction. Criteria for suspicious transaction could include:

  • Repeated use of the same IP
  • Repeated use of the same Credit Card
  • Quick form completion time
  • Transactions under $2

UXexchange will use a captcha if you edit an answer within a short time of posting.

With selected criteria most people would not have to see the captcha.

  • 2
    Unfortunately many captchas are inaccessible, and if the donation page is on a non-profit, especially one that is disability related, can cause additional harm in blocking possible donors. This also is true for people who have cognitive or visual issues, though not disabled. If you're going to use a captcha, it can't be image based unless there's an available sound file. I've seen successful use with the "what is 7 +13" where the addition rotates through a series of calculations. Like the tracking of repeated use combined with transaction amount and time on form.
    – Susan R
    Jul 14, 2010 at 14:16
  • Agreed, strategic use of CAPTCHAs is best to prevent losing donations, especially when competing organization's donation page doesn't put anything intrusive there. Donation experience should be as frictionless as possible. Every $ counts in not-for-profit. Make it easy to give.
    – John K
    Dec 13, 2011 at 0:06
  • As someone who used to work in a NFP that dealt with this exact problem, this is the approach we followed. We also went with a non-image based CAPTCHA, instead asking simple questions like "How many legs does a cow have?" The other key thing was to place a notice that explained why the CAPTCHA system was there. It worked pretty well for us.
    – John N
    Dec 14, 2011 at 13:22

I'm assuming you already googled your question, but just in case you haven't...


That article suggests a lot of what you see here: don't use a blank donation amount, require CVVS, require address & address verification on credit card, use reCaptcha, use more technical measures to block IPs, etc.

Just a note, use reCaptcha instead of Captcha. Listen to the inventor tell you why: http://bit.ly/rZUBiv

You could also: - Allow paypal donations (though there is some risk of dealing with PayPal there) - Allow text message donations--provide instructions on page on how to text a donation - Google Checkout (same risk as paypal I assume)

In general the strongest deterrent seems to be requiring the CVV2/CVVS, which you are already doing.


I'd avoid Captcha until you've exhausted other options. In order to be successful in matching a CC #/name pattern the baddies much be doing thousands of attempts against your server. As mentioned before the first line of defense should be to identify suspicious behavior patterns and block those.

In particular, if you get more than, say, 5 attempts at form completion within 30 seconds from the same IP, you could remove the form and put a message like "It seems like you're having problems making a donation. Our apologies. We're happy to accept your donation over the phone at __". Friendly message in case there's actually a legit person that falls in this bucket, but presents a dead-end to the baddies.

Another idea related to form completion time -- split the form into multiple pages (contact info on one, CC info on another perhaps). Block anyone that fills the initial page in within milliseconds when they go to the next page.

And as I mentioned in a comment on the original question -- the best solution may be to outsource the credit card gateway to one of the many companies out there. I've worked for small non-profits before and even the most responsible developers likely don't have the bandwidth to keep up on every possible security concern. The transaction costs of using a vendor are a concern, but shifting the burden of protecting against fraud can free the organization to focus on bigger issues.

  • I tend to side with your view that the experience should first and foremost be least obtrusive for the donor. It doesn't make sense to me, that when we have the technological means although it might take more work to implement, that we should impose a burden on the user if we don't have to, especially when they're giving their money.
    – John K
    Dec 16, 2011 at 23:22
  • 1
    Thanks John - as you said it's particularly essential in this case, when we're asking them to give money. Beyond making it a better experience for donors, with every extra hoop we make them jump through, the # of donations is likely to decrease. It's worth spending the time/money to do these well.
    – Voodoo
    Dec 19, 2011 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.