Fundraising tech

This document should explain or link to everything needed for fundraising tech development.

About Fundraising Tech
Fundraising Tech is responsible for the security, stability, and development of the Wikimedia Foundation’s online donation systems. Millions of relatively small donations make up the majority of the Wikimedia Foundation’s operating budget every year. The donation systems created and maintained by Fundraising Tech were built specifically to make the small donor model a reality, across as many localities as possible to further ensure the continued independence of our mission.

We do not write banners or run tests, we support the people and software that run them.

International payment processing

 * The majority of donations run through integrations with 6 payment processors. We are also integrated with several other processors for accessibility, location and fundraising event uses. These integrations enable us to support online fundraising campaigns in approximately 30 countries each year.

CiviCRM - our donor database
We use Open Source CRM CiviCRM to manage our donor data. This data is crucial in measuring the impact of our fundraising campaigns, developing our global strategy, and maintaining relationships with past donors.

Tools to create, manage, and deliver online fundraising campaigns

 * We are the primary developers and maintainers of the CentralNotice system, which delivers banner notices to the wikipedias and the sister projects. Historically, banners on the wikis have been the primary method by which we entice users to donate.
 * We use SWAP to query banner data.
 * Note: We partner with the Advancement department, Major Gifts, Banner and Email teams, operations and Donor services. Fundraising tech provides stable platforms and tools to Advancement, and they create specific fundraising campaigns and other donor-facing messaging and content.

Documentation - Monitoring, Testing, Deploying

 * Monitoring with Grafana dashboards
 * Essential systems - what to watch
 * Software components - how they work


 * Installing locally, testing, and deploying - how to fix it

Who we are

 * Director: Erika Bjune
 * Engineering Manager: Dylan Kozlowski
 * Tech Lead: Elliott Eggleston
 * Product Manager: David Strine
 * Software Engineers: Andrew Green, Eileen McNaughton, Jack Gleeson, Christine Stone
 * Ops Engineers: Jeff Green, Dallas Wisehaupt

How we work

 * Roles/Responsibilities: Fundraising tech/Roles and Responsibilities
 * Team training matrix: Fundraising tech/Training
 * Regular meetings and their agendas Fundraising tech/FR-tech Meetings

How to find us

 * You can find our engineering team on the IRC channel.  Include "fr-tech" in your message to make sure we see it.
 * I found a bug!

Current Work
Phabricator task board: #fundraising-backlog

Roadmap
fr-tech's detailed Roadmap

Rhythm and code freeze
We have a special yearly window of not deploying major changes to some critical systems starting in the fall, in preparation for the Big English drive. Game on again in mid-January, assuming we haven't emitted a puff of smoke in early December.

This code freeze gives our development an annual cadence, with each season seeing similar types and intensities of work, year-over-year. Any long-running FR-tech project should take this into account.

Payment Processors

 * Adyen, their docs
 * Amazon Pay, their docs
 * Dlocal (formerly AstroPay), their docs
 * Ingenico Connect, their docs and see filesrv:
 * Old API (WebCollect) developer manual: WebCollect_technical_guide_2013_Q4.pdf
 * Workflows (needs updating): smb://filesrv1/fundraising/Tech/Ingenico/Old/Tech%20specs%20and%20guides%20from%20PaymentProcessing
 * Note: In the codebase, Ingenico can refer to the older GlobalCollect--Ingenico's former name--integration and the new integration with their updated API
 * PayPal
 * Legacy integration (disabled for new payments, but still receiving old recurring): their docs
 * Express Checkout, their docs
 * Integrating with a new payment processor: Fundraising tech/New integration manual

To Be Documented

 * User requirements:
 * Specifications:
 * Test plan:
 * Documentation plan:
 * User interface design docs:
 * Schedule:
 * Release management plan:
 * Release management plan:

Useful Links
Used Often

Deployment

Local Testing

Used Less Often

Audit Parser

Monthly convert

Yearly

End of year receipt

Exchange rates

Reference

Database Cheat Sheet