Fundraising and Donor Management

Why we built it

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.

This was the third generation of fundraising work I had helped build. An earlier donor portal and pledge-drive system served more than 2,000 donors a year and processed over $1 million in donations, while an earlier donation platform supported more than 15,000 donors.

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

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.

What it unlocked

Nonprofits could create different campaign experiences without commissioning a new application every time. Staff could choose fields, add campaign-specific questions, use conditional fields, and map useful information back to donor profiles.

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

What we added to the platform

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 our first generation of fundraising forms.

The original forms worked, but they were fairly rigid. If a customer wanted to collect different information or change the donation experience, it often required development work.

Webform gave administrators much more control. They could choose which fields appeared, add questions specific to a campaign, use conditional fields, and change the form without needing us to rebuild it.

I then built custom Webform components and handlers that connected those forms to our donation and payment system. We could also map information collected during a donation back to the donor’s profile, so useful information did not remain trapped inside a form submission.

That combination gave administrators much more freedom to create the fundraising experience they wanted while we continued to handle the payment and donation records consistently behind the scenes.