Our Move to Stripe and Salesforce for Donations

The Texas Tribune is a nonprofit, and as a nonprofit, memberships and donations are very important to us. The code powering the pages for becoming a Texas Tribune member, renewing a membership, and making one-time donations used to live inside of the main Texas Tribune codebase. As we mentioned in our deletions sprint blog post, in June 2015 we moved this code out of our main codebase.

Why did we move our membership and donations pages out of our codebase? We’ve been working to take apart our monolithic codebase that’s working hard to do everything, and split it up into smaller elements, with some work outsourced to third-party services. A smaller main codebase means that it’s less brittle, and that an issue in one area of the site doesn’t negatively affect another area of the site. In addition, making our code more modular makes it easier to manage, easier to modify, and easier to conceptualize about. Thoughtfully choosing focused tools made for each job also means we’re using each piece of code for what it’s best at and not forcing the code to do what it doesn’t want to.

We also didn’t want to be responsible for taking credit cards on our site anymore; it was a better choice for us and our small four-person team to outsource that work to a third-party payment processor that can spend more time focused on security and best practices than we can. In addition, we liked that our ability to accept memberships and donations wouldn’t be affected if other parts of our site experienced issues.

We looked into a few options for what to build with. We chatted with Voice of San Diego (VOSD), a fellow member-based nonprofit news organization, about what they used. VOSD and MinnPost adopted Givalike because it played nicely with Salesforce and ostensibly catered to nonprofit organizations like ours. We had similar goals that we wanted to fulfill with our payment processor, so it seemed like a great fit for us, and we knew if we used it, we’d be in good company.

We also needed to decide what we would use to build the membership and donation pages. We’d previously used Middleman, a static site generator, to build a site to celebrate the Tribune’s 5-year anniversary and had enjoyed working with it. It was fast to develop with, and it provided everything we’d need. Since we knew that most of the information on our membership and donations pages would be static, we didn’t want to overcomplicate it. And the parts of the site that would change, we could set up to update with Vox’s Middleman and Google Drive gem. This would allow our membership team, as well as other colleagues who might want to update text on the page but wouldn’t be committing code to GitHub and redeploying the app, to make changes without much help from our team.

At this point, it had begun to become clear to us that it wasn’t just us at the Tribune: nonprofits’ need for membership and donations pages like ours was real.

When we learned that a Knight-Mozilla OpenNews Code Convening would be taking place soon in Portland, Oregon, we felt that taking a pass at making the work we’d done to build our donations site open source and more friendly to other organizations’ customizations would be a great project. The wonderful folks at OpenNews agreed. Kathryn flew to Portland and spent a few days putting together DonationBuilder.

The sun was shining and birds were singing. We were feeling good and accepting donations through our new membership and donations site and Givalike. Everything seemed to be going along fine.

Unfortunately, however, the honeymoon with Givalike as our payment processor was short lived. We started encountering problems with Givalike within a month or two, such as transaction failures and subsequent lackluster responses to those failures, in addition to other concerns. Facilitated by our shared Salesforce consultants, Anna Crotty and Mark Olinger, our three organizations (The Texas Tribune, VOSD, and MinnPost) began meeting regularly to join together and prioritize our issues so we could present them to Givalike as a group. Despite combining forces and speaking with one voice, we did not get much traction with Givalike. We were feeling frustrated, and we also knew we couldn’t accept this and the effect it was having on our members’ and readers’ experiences as a part of our community. It was time to begin researching a better way.

We started looking into an alternative at the end of June 2015. At first, we poked at it a bit, but didn’t start quickly developing a switch. Then we were notified that on August 5, 2015, only a little over a month later, Givalike would be transferring operations to another service, Donatic. This revelation lit a fire under us about switching to Stripe–what we’d been considering a likely future event had become an imminent need.

Although we needed to move fast, we wanted to be sure to do thorough research on a switch, so we looked into other options beyond Stripe. We weren’t excited about the fees that came along with other services–usually they were in the 5 percent range, which wasn’t too appealing when compared to Stripe’s 2.9 percent. Using Stripe would require writing some custom integration code, but with its lower fees, it was in line with the rest of the bare-bones payment processors we knew about. Sweetening the deal even more was the fact that Stripe’s API is highly regarded among developers, and we’d heard that it was enjoyable to work with. As we began working with it, it was clear that it was all true: Stripe’s API was well documented and a breeze to set up and work with.

As we were building out our Stripe integration to switch over as soon as we could, we received another notification on February 2, 2016, informing us that Donatic would be ceasing operations on March 31, 2016. This news only confirmed that we’d made the correct decision.

We considered doing the integration work in Salesforce itself but decided against that approach because we didn’t have anyone in our newsroom who knows Salesforce’s proprietary programming language. We were much more comfortable using Salesforce’s REST API and calling it from Python, a language with which we’re fluent. Using Python also meant that we’d have a room full of people who could author and maintain the code, and we wouldn’t be relying on a likely-quite-expensive outside consultant to build or maintain it. So we fired up a Flask app and started building.

We chose Heroku as the deployment platform because it insulates us from many of the unpleasantries of running our own infrastructure. With just a few clicks we can deploy and run our application. And at around $25-50/month per organization, the price was right.

In Salesforce, we needed to map fields in Stripe to the appropriate Salesforce field, which required creating a few custom fields on the recurring donation object (part of Nonprofit Starter Pack 3) and the opportunity object.  NPSP has a configuration tab that allows an admin to map fields on the recurring donation to the related opportunities, so that the Stripe app only creates one record for a recurring donation.  The changes required in Salesforce were put into a package to allow each organization to install them all quickly.

The integration is up and running smoothly now, and was overall a successful example of collaboration and teamwork. We at The Texas Tribune (mostly Daniel Craigmile, Kathryn Beaty, and Anna Crotty) built out the foundation for all three organizations’ integrations.

There are a few things we’d do differently, of course; with every project there are always a few things. Each integration had to be customized independently for the needs of each organization. If we had more time, we would have pushed more of that customization from code into configuration to make it easier for each organization to adapt to their specific needs. Even though all three organizations are using Stripe and Salesforce, each organization has very different Salesforce customizations, which isn’t ideal.  

We hope that our story and what the three organizations have built between us can be of use to other organizations tackling similar challenges.

Salesforce-Stripe integration: https://bitbucket.org/texastribune/salesforce-stripe/
Donations app: https://github.com/texastribune/donations-app