Nonprofit Donation Website Security: A Practical Checklist Before Your Next Campaign

An online donation passes through more than a fundraising page. Your website, domain account, giving platform, payment processor, donor database, and finance team may all play a part.

Before a year-end appeal or community fundraiser, make sure someone can explain how those pieces connect. A donation form that looks correct can still have unclear ownership, outdated integrations, or an alert nobody monitors.

For nonprofits in Frederick, MD and surrounding communities, a focused review can uncover these gaps without turning a campaign launch into a full technology replacement.

Key Takeaways

• Document who owns the website, domain, giving platform, and payment account.
• Confirm the actual payment integration before deciding which security and compliance checks apply.
• Protect the accounts that can change donation links or payout details.
• Test the donor journey and assign responsibility for unusual payment activity.

1. Map the Complete Donation Journey

Start with the places supporters encounter your appeal: the homepage, campaign email, social post, event QR code, and printed materials. Follow each route to its payment destination.

Create a simple inventory containing:

• The public donation link and campaign it supports
• The website or fundraising platform hosting the form
• The processor receiving the payment
• The account receiving settlement funds
• The system receiving donor records
• The staff member responsible for each connection

Include recurring gifts and older campaign pages that remain active. An abandoned page can be overlooked when staff review only the main Donate button.

Ask your web vendor whether donors leave your website for a hosted payment page, use an embedded payment form, or interact with a custom integration. Keep that explanation with your vendor records rather than relying on appearance alone.

2. Confirm Payment Responsibilities Before Choosing Controls

A processor’s security claims do not answer every question about your nonprofit’s implementation.

PCI SSC FAQ 1588 explains that the SAQ A script-attack eligibility condition applies to webpages containing a processor’s embedded payment page or form. That particular condition does not apply to pages that redirect donors to the processor or fully outsource payment functions. Other eligibility criteria still matter.

For embedded forms, the FAQ describes appropriate protective techniques or confirmation from the compliant payment provider that its solution includes protections when implemented according to its instructions. It directs merchants to their compliance-accepting entity, typically the acquiring bank or payment brands, to determine the appropriate questionnaire.

Ask your provider:

• Which integration are we using, and is it currently supported?
• What configuration instructions must our web developer follow?
• What evidence can you provide about your responsibilities?
• Who determines our validation requirements?
• What changes would require another review?

Keep the answers specific to your deployment. Using a payment vendor does not settle every question about your own configuration and responsibilities.

3. Keep Control of the Domain and Critical Accounts

Your nonprofit should know how to recover access if an employee, volunteer, or web agency becomes unavailable.

Review the registrar, DNS service, website platform, giving platform, and payment account. Record the organizational owner, authorized administrators, recovery method, renewal arrangements, and support contact.

ICANN’s domain-registration security guidance addresses account protection, dependable contact information, change monitoring, and domain-lock controls. Discuss these areas with your registrar and IT provider.

Use individual administrator accounts where supported. Enable MFA, prioritizing phishing-resistant options for privileged access when available. NIST’s small-business MFA guidance describes stronger authentication methods alongside limiting privileges and removing access when needs change.

Separately identify who can change payout bank details. Consider requiring an independent staff check for those changes using established contact information, rather than instructions in an unexpected email.

4. Review What Can Change the Donation Page

Ask your web developer for a list of components affecting the donation experience: plugins, embedded forms, analytics tags, chat widgets, scripts, redirects, and integrations.

For each component, establish its purpose, who can change it, who maintains it, how updates are tested, how unwanted changes would be noticed, and how the last working version would be restored.

A practical approval rule is to have another authorized person check changes to donation destinations, embedded payment code, and payout settings.

Before adding a campaign tracking tool, ask whether it receives donor details or can interact with the payment journey. Do not place payment information into ordinary website contact forms or ask supporters to email card details as a workaround.

5. Give Payment Alerts a Named Owner

A donation page can attract card testing: attempts to determine whether stolen card details work.

Stripe’s card-testing guidance identifies warning patterns including a surge in failed or blocked payments and suspicious low-value payments. It recommends layered protections rather than depending on one IP-based filter. Platform users may need their vendor or developer to make integration changes.

Agree on who reviews alerts during a campaign and who covers absences. Finance and development staff should know how to reach the platform vendor without locating a contract during an incident.

Ask about available anti-bot controls, rate limits, payment review tools, and false-positive monitoring. Establish who can pause an affected form and how staff verify it is safe to resume.

A small gift alone is not proof of fraud. Review patterns and follow the processor’s documented procedures rather than blocking legitimate supporters indiscriminately.

6. Test the Donor Journey Before Launch

Use the platform’s supported test environment and procedures. Do not conduct unauthorized security testing or simulate fraud against a live payment system.

Have someone who did not build the campaign check:

• Published links and QR codes reach the intended destination.
• The organization name, campaign purpose, and donation options are correct.
• Mobile and keyboard navigation work.
• Recurring-gift wording accurately describes what donors authorize.
• Confirmation messages and receipts arrive as intended.
• Donor records reach the appropriate system without unnecessary data exposure.
• Staff can identify and reconcile the test using the provider’s supported workflow.

Document the date, reviewer, result, and unresolved issues. Recheck important steps after changes to the platform, form, or integration.

7. Put Vendor Handoffs in Writing

Close the review with a one-page responsibility sheet:

• Development or fundraising: campaign links, donor communications, and launch approval
• Finance: reconciliation, settlement review, and authorized refund decisions
• Web vendor: page maintenance, supported integrations, and change recovery
• IT provider: agreed account-security, device-security, and access-management responsibilities
• Giving platform or processor: payment-platform controls and transaction support defined by the service

These are suggested assignments, not assumptions about your contracts. Confirm who performs each task, what support hours apply, and which work costs extra.

Hold a short walkthrough with the relevant staff and vendors. Choose one active donation page and resolve ownership gaps before expanding the review.

Frequently Asked Questions

Does a hosted donation platform remove all our responsibilities?

No. Understand your accounts, configuration, vendor responsibilities, and applicable validation requirements. Confirm the arrangement with the provider and the entity accepting your compliance documentation.

Does suspicious donation activity prove our website was hacked?

Not by itself. Card testing and website compromise are different questions. Have the payment provider and web vendor investigate the evidence before deciding what happened.

Should we replace our giving platform immediately?

Start with the gaps. Missing ownership records or an unmonitored alert may be fixable within the current platform. Consider support, security capabilities, integrations, and disruption to recurring donors before replacing it.

This is educational operational guidance, not a PCI DSS assessment or legal advice.