Nonprofit Fundraising and Donor Management

The challenge

Nonprofit customers needed fundraising to feel like part of their community, not a disconnected payment page. They needed campaign-specific forms, one-time and recurring giving, designated funds, receipts, and reporting, and they needed to change those campaigns without waiting on developers.

This was the third generation of fundraising systems I had helped build. The first, a donation platform for a missions organization, supported more than 15,000 donors and ran on a recurring-schedule system I wrote on top of Drupal Commerce. The second, a donor portal and pledge-drive system with administrative dashboards and CRM and payment integrations, served more than 2,000 donors a year and processed over $1 million in donations.

Those earlier systems also showed where the experience was too rigid: routine changes to donation forms could require development work. For this generation, I wanted administrators to be able to shape each campaign themselves while still relying on the same donation, payment, recurring-giving, and donor-history capabilities underneath.

The solution

I built the newer fundraising experience around Drupal Webform. Staff configured each campaign’s form themselves, choosing fields, adding campaign-specific questions, and using conditional logic, while custom Webform components and handlers connected every form to the platform’s donation and payment system.

Behind the forms, the system handled one-time and recurring gifts, receipts, fund designations, and donor history. Information collected during a donation could be mapped back to the donor’s profile, and donors could manage recurring gifts and review their giving through a self-service portal.

Results and capabilities

The system was deployed in production for nonprofit customers. Nonprofits could create different campaign experiences without commissioning a new application each time, and staff could change forms and collect campaign-specific information on their own.

Donors received a consistent experience, receipts, recurring-gift management, and a complete giving history, while staff could manage gifts, fund designations, recurring commitments, and fundraising revenue alongside the platform’s other transactions.

My role

I designed and built the campaign configuration, custom Webform components and handlers, profile-field mapping, recurring commitment and scheduling, the donor portal, and staff-facing reporting, and connected the fundraising workflow to the shared payment service I had designed for the platform.

I wrote the backend services, browser-side form behavior, and staff-facing Views, and reviewed how other features used those interfaces.

Technical implementation

Campaign configuration controlled permitted funds, recurrence choices, presentation, and follow-up. Webform gave staff a mature way to compose each donor journey. A custom handler translated a valid submission into a standardized gift request; application services then reloaded the official configuration, verified how funds were assigned, and coordinated payment.

One-time gifts produced donation and financial records. Recurring gifts also created a commitment and schedule for future payments. Drupal events separated the completed gift from receipts, notifications, dashboards, and reporting, while entity and route access protected donor self-service. Fundraising used the same shared payment and transaction foundation as other revenue features while keeping its own campaign and donor experience.

How recurring giving worked

The server rechecked every amount, designation, and campaign rule submitted through the form. After the first verified payment, it created the gift, donor history, recurring commitment, and future schedule. When a scheduled payment became due, a worker claimed it with a duplicate-safe reference, revalidated the commitment, and requested payment. Success advanced the schedule and recorded another gift; failure followed an explicit retry or staff-attention policy.

Changes made through the donor portal affected future payments without rewriting historical gifts, preserving a clear financial history for both donors and staff.

Drupal under the hood

Webform

Gave staff flexible composition, validation, conditional fields, confirmation, and submission management.

Entity and Configuration APIs

Represented auditable gifts and commitments separately from deployable campaign rules.

Services and events

Kept financial changes controlled while allowing receipts, dashboards, and reporting to react.

Queue API, Views, and Twig

Supported recurring processing, staff reports, exports, donor history, and presentation.

Why I chose this approach

I chose to build the newer donation experience around Drupal Webform because of what we learned from earlier fundraising forms. They worked, but if a customer wanted to collect different information or change the donation experience, it often required development work.

Webform already gave administrators a mature way to compose forms, so I focused custom work where it mattered: components and handlers that turned a submission into a standardized gift request, and services that rechecked every amount, designation, and campaign rule on the server before any payment was requested. Mapping donation answers back to donor profiles kept useful information from being trapped inside form submissions.

That split gave administrators freedom over the fundraising experience while payments and donation records stayed consistent behind the scenes.