Fundraising tech/SmashPig

Smashpig Overview

Since its inception, the Fundraising Tech team at the Wikimedia foundation has been successfully navigating and operating within some very unusual territory. As a result of spending those years solving our unique problems and increasing our fundraising reach under a free license, we have created a fully open-source donation handling system proven to be capable of safely and securely collecting donations across the globe, through about 15 distinct payment methods.

Unfortunately, while the code itself is fully open source, we have never had the resources to prioritize making this remarkable body of work realistically reusable by other donation-based entities, while also providing the necessary level of support to the WMF’s Advancement team to successfully raise our budget every year. At present, all our work that makes these consistently successful fundraisers possible on a technical level does exist in the open, but it would probably take an experienced member of our own Fundraising Tech team quite a lot of time to make any of it reusable in another organization.

It is our intention to make our entire body of work readily and freely available to other donation-based entities seeking a dependable, global fundraising solution. That solution is Smashpig.

Current thinking

Please note: This is only a collection of thoughts at this point. Nobody has vetted or even remotely approved of anything yet.

First, we will need to do quite a bit of cleaning up before we can invite people in, or they will run away and never come back. All of our payments integrations currently exist within the DonationInterface mediawiki extension, because our own payments systems were initially built on mediawiki installations. Going forward, even internally, Mediawiki should no longer be a requirement to set up our payment integration libraries.

Second, we will need to go over the structure of what we have now, and restructure to optimize for the following things, without compromising current functionality or security:

• Ease of adding new payment integrations that work within the system
• Simplicity of the manipulation of configuration settings, particularly those related to the accounts held with supported payment providers
• Ease of setting up and manipulating payment forms, and payment form A/B tests.

Third, we will need to provide clear directions for authoring new interfaces to other systems, such as CiviCRM. We will probably create these directions by writing a full Smashpig module for CiviCRM. While we do not move donors through our CiviCRM installation directly, a large number of small nonprofits do host their donation forms within that system. Additionally, a Smashpig module for CiviCRM would allow us to provide better support for things like automatically recurring donations, and push-button refunds.

Once we have completed these three things without removing any of our current capabilities (and improving several), we should be ready to reach out to relatively tech-savvy nonprofits who may be able to benefit from our work. Initially, we will need to work with nonprofits that have enough engineering know-how, to give us feedback about what could be improved upon. This work will help us open the doors to more organizations, decreasing the requirement for in-house technical prowess as we go.

The eventual goal would be an active community of nonprofit organizations using, modifying, and improving Smashpig, supporting each other in our global online fundraising activities.

Known difficulties

• i18n and interface translation. At the moment, Mediawiki’s translation bot very helpfully handles all this for us. Everyone should be able to take advantage of the automatic interface translations that we enjoy, and far too frequently take for granted.
• A proliferation of antifraud systems running with default settings. Creating a whole community of people who may not be inclined to change their default antifraud settings until they have a problem, would have an enabling effect on some fraudsters. Attackers who understand the default antifraud strategy would eventually learn how to identify organizations running with the defaults, and exploit them. For smaller organizations, even small amounts of donation fraud can be devastating. Addressing this should be a requirement from the start.
• Payment forms. We should leave the actual payment forms entirely up to local installations, with some mechanism for including some system-specific sample forms in the relevant modules and extensions (or generating them?). However, this gets very complicated very quickly, when you consider that all payment methods have their own requirements for data (both fields present and not, and on data validation rules for fields in use everywhere). One possibility: Surface information within the Smashpig API that would describe required data and constraints for each payment method, and use that information in various contexts (Display directly on forms that are not yet enabled, throw it in live error logs, anywhere else that might make the form creation process and maintenance less awful).
• Analytics. All of our methods of recording results of A/B tests, and donor dropoff, are very specific to the systems we happen to be using. The ability to test the efficacy of your choices everywhere in the donation pipeline is a crucial element for a successful online fundraising strategy. However, this may not be within the scope of these initial activities, and is almost certainly going to have to be redone if we try to figure this out too early, without strong input from other members of the future Smashpig community.
• PCI compliance. At some point, we will be attracting organizations that have never had to fill out a SAQ before, and may not have the resources to maintain an appropriate level of compliance, or realize that this is a necessary component of running your own donation rig. While it will clearly not be our responsibility to maintain other people’s compliance levels, we should at least come up with a way that the system is able to warn people when they are enabling features that require a more involved level of compliance.

Deploying

Instructions can be found on the Fundraising tech/Deployment page.

CiviCRM Extension

See https://wikitech.wikimedia.org/wiki/Fundraising_tech/SmashPig