A nonprofit development agency should make it easier for supporters to act and for staff to handle what happens next. A clear website, a working donation connection and an accurate donor record are usually more useful than a large custom platform with features nobody has time to maintain.
Start with one operational journey: a donation reaching the right record, a volunteer taking a confirmed shift, or a supporter receiving the requested information. These journeys need different permissions. A person who coordinates volunteers should not automatically gain access to the donor database.
Related service: Website and e-commerce development- 01Show the approved campaign and donation form.
- 02Use the payment provider's checkout.
- 03Verify the provider's payment event.
- 04Create or update the correct donor record once.
- 05Send an approved acknowledgment and flag exceptions.
SECTION 01
Use the fundraising tools you already have where they fit
Review the donation forms, recurring payment settings, email templates, exports and permission controls in your existing platform. If staff can operate the workflow there, configuration may be a better use of funding than a custom rebuild. Include volunteer software in that review rather than assuming every team needs the same database.
Custom work is more useful when supporters struggle with the website, staff repeatedly reconcile donations by hand, or a specific program needs a portal the current tools cannot provide. Ask the agency to describe that gap in one sentence and identify who will maintain the result after launch.
SECTION 02
Illustrative example: a successful payment needs a donor record
Imagine a supporter makes a donation and closes the browser before reaching the thank-you page. This is a planning example, not a reported result. The payment can still be successful, so the CRM update should not depend solely on the supporter visiting that page. Staff need a record that can be reconciled against the payment provider.
Stripe's webhook guidance describes signature verification, retries and duplicate events. In a proposed integration, the server verifies the event, checks the relevant payment state and records the provider's reference. A duplicate delivery must not create a second gift or acknowledgment. A failed CRM update enters a staff-visible retry queue.
An approved acknowledgment can state the recorded donation and campaign. Your organization supplies any tax or legal wording; the software should not invent eligibility or receipt claims. Separate the payment record from marketing preferences, so a donation does not silently enroll someone in unrelated messages.
SECTION 03
Treat identity and access as implementation requirements
A shared household email, two similar names or an anonymous public donation can complicate donor matching. Define when a record can be matched automatically and when staff must review it. Preserve the payment reference and original form submission so a reviewer can correct the connection without losing the financial event.
Write separate access rules for fundraising staff, finance reviewers, volunteer coordinators and external users. Sensitive program records should not appear in general supporter searches. Limit exports, review staff departures and make access changes auditable. OWASP's authorization guidance recommends denying access by default and checking permissions for every request.
The nonprofit should own the domain, payment account, CRM administration and production access decisions. The development agency receives only the access needed for delivery. Handoff should include an account inventory, recovery contacts and instructions for removing the agency's temporary access when the engagement ends.
SECTION 04
Keep volunteer coordination separate from fundraising access
A volunteer portal might show available shifts, confirmed assignments and cancellation instructions. Coordinators need a way to fill a vacancy and notify affected people without exporting the donor list. If an existing scheduling product already supports this, integrate or configure it before commissioning a dedicated mobile app.
AI can help staff draft answers from approved program information or categorize incoming support messages for review. It should not decide who receives assistance, infer a donor's wealth or produce personalized appeals from sensitive records. A public information chatbot also needs a clear way to hand a question to a person.
SECTION 05
Prove one campaign before adding more programs
A first release can cover one campaign, one payment connection, one CRM handoff and approved acknowledgment wording. Include a reconciliation view for finance and an exception queue for staff. Keep complex grant reporting, beneficiary case management and a new accounting system outside that release unless they are separately assessed.
SECTION 06
Ask for a proposal your staff can operate
Share your current tools, a redacted donation export, approved messages and the staff roles involved. Ask who monitors failed payments and failed syncs, who can correct a donor match, and what happens if the integration vendor changes its API. These questions reveal ongoing obligations that a page count misses.
Catapult can scope nonprofit websites, CRM connections, custom portals and controlled automation within its existing development services. For U.S. or international organizations, confirm currencies, languages, access arrangements and review hours. Contact us for pricing, with subscriptions and ongoing support separated from the initial implementation.
SECTION 07
Frequently asked questions
Does a nonprofit need a custom donor CRM?
Often an existing fundraising platform is the stronger starting point. Assess its configuration, exports and connectors first. Build custom software only around a meaningful gap with funded ongoing ownership.
Can our donation form update the CRM automatically?
Where supported, a verified payment event can update the CRM through an integration. Include duplicate detection, staff review for uncertain donor matches and a recoverable queue for failed updates.
Can one portal serve donors and volunteers?
It can provide separate experiences, but it must not give every user the same data access. Define role and record permissions for each workflow and test that volunteer access does not expose donation records.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- WebhooksStripe
- Authorization Cheat SheetOWASP Foundation
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy