The Three Reasons that Nonprofits Shouldn’t Host Their Own Donation Forms

September 11, 2019  |  Dave Berman

There are many reasons you should consider using EveryAction's donation forms, including our industry-leading capabilities and the backing of a highly-experienced engineering team. If you are considering hosting your own donation forms, take a minute to read this piece highlighting the additional capabilities that EveryAction provides to your forms. We have engineering and IT teams with decades of experience of not only running high-availability web applications, but specifically focusing on supporting non-profits. The services we provide break down into three categories: Uptime, Security, and Scaling:

  1. Uptime:

When you are taking in donations 24/7, any system downtime or even degradation results in a loss of revenue. In order to assure that our web applications are up and performing as expected at all hours, we engage in both active and passive monitoring. We look at numerous metrics, from CPU and disk usage, to end-user response time, to exception and error rates.

In order to respond to any alerts, we have staff on-call 24/7. During critical times for our clients, we focus on active monitoring, with extra staff watching all important metrics. We determine critical times based on the specific usage patterns of our clients - that includes Election Day(s), Giving Tuesday, and End Of Year. Furthermore, should a client have a planned event such as a telethon or fundraising drive, we can put active monitoring and extra staffing in place. We are even prepared to detect and support load that is driven organically or by the 24/7 news cycle.

Despite our monitoring, unexpected events can and do occur. There are components that our applications rely on that we cannot control, such as DNS Servers, or cloud service providers. We architect our solutions to avoid as many of these dependencies as possible, and in the case that we do have to depend on them, degrade gracefully in case of a failure. We also have a series of runbooks and failure policies that allow us to mitigate the effect of potential downstream faults.

Furthermore, we are constantly adding features and updating our software, which requires deployment. Typically, software deployment is one of the riskiest times for an application - you are running an application while you are modifying it! But we have honed our deployment processes to achieve zero downtime, and in the rare case where we are attempting risk deployment or maintenance, we have our changes staffed by developers, IT staff, and QA engineers in order to assure that the operations go smoothly and the software is functioning properly afterwards.

Regardless, failures can and do happen, which is why we have backup systems in place. Many of our systems are geo-redundant, so in case, say, a cloud service fails in a given region of the country, we can switch to use services in a different region. We also employ backup network routes, redundant physical hardware, and a whole host of other mechanisms to minimize downtime. We also perform regular data backups, and can restore data in case of a catastrophic hardware failure.>

  1. Security and Fraud protection

System downtime is not the only threat lurking out there, which is why having security and fraud protection in place is an absolute necessity if you are taking donations. (And it's pretty important even if you aren't taking donations - spammers and fraudsters like to wreak havoc wherever they can.) EveryAction takes these threats very seriously; we have staff in both our IT and Engineering departments whose sole job is to identify potential security threats and remediate any existing ones. 

We have numerous systems in place to ensure that donations are handled in a secure and private manner. We treat all Personally Identifiable Information (PII) securely as well, in order to make sure that data is not leaked or hacked.

We spend a lot of time thinking about injection attacks and other intrusions. We specifically look for these types of vulnerabilities in code review, but we also hire third-parties to conduct security audits to catch issues we might miss.

Another vulnerability for donation forms is fraud. We have sophisticated fraud-prevention techniques for our forms, including a third-party machine learning service that allows us fine-grained control over our level of tolerance of suspicious submissions. Our active monitoring allows us to detect anomalous behavior and proactive block or suppress malicious users and IP addresses.

And if those weren't enough threat vectors, there's always random denial-of-service attacks that are very prevalent, and a common tool used by right-wing opponents of our progressive clients. Fortunately we have a Web Application Firewall (WAF) to protect against DDoS attacks.

  1. Scaling:

Any web application needs to be able to handle spikes in load. But contributions forms for our high-profile, critical clients are subject to unique usage patterns - ones that we are intimately familiar with and therefore have designed our apps and systems to handle. If a certain bloviating President disparages your organization, we want to make sure that our systems can handle every last drop of contribution money resulting from the inevitable backlash.

Our experience with servicing "spiky" load has motivated us to build tools and systems to predict and handle such usage patterns.

If the load is anticipated in advance - for instance, around elections, Giving Tuesday, or the end of the calendar year - we can simply scale up our hardware infrastructure to handle it. We perform analysis well in advance and can reliably predict our email sends and form submission rate.

Whether or not increased load is anticipated, it presents a unique challenge - high-load times are critical for our clients, for obvious reasons. Downtime or even slow form loads can decrease conversion rates and impact revenue. We are constantly monitoring and improving performance in terms of both latency (how long do operations take?) and throughput (how many concurrent operations can be performed?). 

All of this is complicated by the fact that the software is not static - we are constantly releasing new features and improving existing ones, sometimes releasing updates multiple times per week. These releases are some of the riskiest times, which is why not only do we work to have ZDD (zero-downtime deployment), but also to maintain our performance during those deployments. Furthermore, new features can potentially cause degradation in performance of existing features, which is why we proactively perform performance tests on any new application release, in order to ensure that we don't regress.

The process of handling digital contributions to your nonprofit is complex - both from a software effectiveness and data security standpoint - which is why it is important to have an entire team of experienced professionals backing up your donation forms, making sure that they don’t fail at key moments, and are upholding the best standards of privacy and security.