PCI compliance for nonprofits is usually treated as a back-office formality, something the payment processor handles. In reality, it comes down to a very practical question: can anyone tamper with the page where your donors type their card numbers, and would you know if they did?
It is the last week of the year-end campaign, and the donations are pouring in.
The development director watches the dashboard with quiet satisfaction. Gifts are up. The email appeal worked. The new donation page, redesigned over the summer, is converting better than ever.
Three weeks later, the organization’s payment processor calls.
Several banks have flagged a pattern. A group of cards used fraudulently elsewhere all share one thing in common: each was used for a donation to this nonprofit within the same window. The processor asks, politely but firmly, whether the organization has experienced a security incident.
It has not, as far as anyone knows. The servers are fine. The donor database is fine. The payment processor’s own systems were never touched.
What nobody has checked is the page itself. A small piece of code, loaded from a third-party widget added during the redesign, had been modified. For three weeks, it quietly copied every card number donors typed and sent it to a server in another country.
No alarm went off. No donor noticed. The donations went through normally.
The Attack Happens in the Donor’s Browser
This technique is called e-skimming, and it works exactly like the card skimmers criminals attach to gas pumps and ATMs, except there is no hardware to find.
A criminal gets a malicious script onto a payment page. When a donor types their card number, the script copies it in the browser before the page sends it to the legitimate payment processor. The donation succeeds. The processor sees nothing unusual. The donor’s card data has already been stolen.
The script rarely arrives by breaking into the nonprofit’s main systems. More often it gets in through something the organization added for convenience: a third-party widget, a chat plugin, an analytics tool, an ad pixel, a tag manager, or an outdated website plugin with a known flaw. If any of those is compromised, the code they load into your page is compromised too, and your page now carries it to every donor.
The nonprofit did nothing wrong in the usual sense. It also gets the phone call.
Why Nonprofits Are Attractive Targets
Nonprofit donation pages have characteristics that make them appealing to criminals.
They are built to be easy. Donors are not asked to create accounts or pass extra checks, because friction costs gifts. That ease benefits criminals as much as donors.
They are public and often long lived. A page created for a gala, a disaster appeal, or a social media campaign may stay online for years after the event ends, forgotten and unmaintained.
They run on a patchwork of tools. A typical small nonprofit website combines a content management system, a handful of plugins, an embedded donation form, email marketing connections, social media pixels, and chat widgets, each maintained by different people or vendors.
And they often have limited technical staff. A webmaster may be a volunteer, a part-time contractor, or a staff member with other full-time duties.
There Is a Second Attack: Card Testing
E-skimming steals cards from your donors. A related attack uses your page to check whether stolen cards work.
In a card testing attack, criminals run large numbers of stolen card numbers through a donation form using small amounts, often one dollar. Cards that go through are confirmed as live and can be used elsewhere for larger purchases. Cards that decline are discarded.
Nonprofits are frequent targets because their forms let the person choose the amount, ask for little identifying information, and do not require an account.
The signs are distinctive: a sudden flood of small donations, a spike in declined transactions, many different cards with similar or nonsensical donor details, and repeated attempts in rapid succession.
The damage is real even though the money is tiny. Processors charge fees for every attempt. Refunds and chargebacks pile up. Banks and processors may suspend an account that shows this pattern, cutting off donations at the worst possible moment. In one documented case, a small nonprofit’s processor required the organization to install a bot-blocking tool and refund roughly two hundred successful fraudulent charges before the account was reactivated. The organization was not the target. It was simply the tool.
Notably, that attack arrived through an old donation page created for a one-time online event a year earlier. Nobody had thought to take it down.
PCI Compliance Applies to Nonprofits Too
The Payment Card Industry Data Security Standard applies to any organization that accepts card payments, including nonprofits. The standard is maintained by the PCI Security Standards Council and enforced through card brands and payment processors.
Many nonprofits believe PCI is not their concern because they use a hosted donation platform. It is true that using a reputable, compliant platform removes a great deal of burden, and it is the right approach for most organizations. But it does not remove all of it.
The current version of the standard, PCI DSS 4.0.1, tightened requirements around the security of payment pages. Newer requirements that became fully enforceable in 2025 expect organizations to know what scripts run on pages that handle payments, to authorize each one, and to detect unauthorized changes. This directly targets the e-skimming threat described above.
How this applies to a nonprofit depends on how its donation form is built. A form hosted entirely on a processor’s page may carry less responsibility than a form embedded in the nonprofit’s own site. Confirm the details with your processor and, where appropriate, a qualified assessor. The practical point is that the page your donors see is part of your payment environment, and you are expected to know what runs on it.
The Federal Trade Commission Expects Reasonable Security
PCI is a contractual standard. Separately, the FTC enforces the principle that organizations must not misrepresent their security and must maintain reasonable data protection. As discussed in an earlier article in this series, the FTC has taken action against a fundraising software vendor over its security failures, and has made clear that organizations are responsible for choosing and overseeing the service providers that handle sensitive data.
A donation page that tells donors “your information is secure” while running unreviewed scripts from a dozen outside sources is making a promise it may not be able to keep.
Start With a Simple Inventory of What Runs on Your Donation Page
The most useful single step is also one of the simplest. Find out what actually loads when a donor visits your donation page.
List every script and service: the donation form provider, analytics, advertising and social media pixels, chat tools, fonts, tag managers, and embedded media. For each, ask who added it, why it is needed, who maintains it, and whether it is still in use.
Most organizations discover items nobody remembers authorizing. A tracking pixel from an old campaign. A chat widget from a vendor they no longer use. A plugin that was installed for a one-time event.
Remove everything that is not essential, especially on pages where donors enter card data. Every script is a door. Closing the ones you do not need is the cheapest security improvement available.
Reduce What You Control
The safest card data is the card data you never touch.
Wherever possible, use a payment page hosted by a reputable processor, either through a redirect to the provider’s secure page or a form embedded in a way that keeps card entry inside the provider’s environment. This shrinks both your risk and your compliance burden.
Minimize additional scripts on any page near the payment step. Many organizations route donors to a clean, minimal donation page that carries only what is necessary, rather than running a full marketing site’s worth of tracking code around a card form.
Choose vendors who can describe, specifically, how they protect their payment pages: how they inventory scripts, detect changes, and respond to incidents. A vendor who cannot answer those questions is giving you important information.
Keep the Website Itself Maintained
Because most compromises start with something ordinary, basic maintenance matters.
Keep the website platform, themes, and plugins updated promptly, and remove ones you do not use. Outdated plugins are among the most common ways attackers modify pages.
Protect administrator accounts with unique passwords and multifactor authentication, and remove accounts belonging to former staff, volunteers, and contractors. An earlier article in this series described how lingering access creates risk, and a forgotten website login is one of the most common examples.
Enable monitoring that alerts you when files on the website change unexpectedly. A skimmer works by changing something. If the change is noticed in hours instead of weeks, the damage is far smaller.
Take backups and test that they restore, so a compromised site can be returned to a known good state quickly.
Decide Who Owns the Website
Almost every one of the weaknesses above traces back to the same gap: nobody is clearly responsible for the website’s security.
The developer who built it moved on. The volunteer who updates it works evenings. The marketing coordinator adds tools as campaigns require. The executive director assumes the processor handles anything related to payments. Each person is doing a reasonable job, and still no one is watching the page as a whole.
Naming an owner closes that gap. The owner keeps the inventory of scripts and plugins, approves anything new before it goes on a payment page, reviews administrator accounts quarterly, and receives the alerts when something changes. For many nonprofits, the practical answer is to give that role to a managed IT services partner, who can maintain the site alongside the rest of the organization’s systems rather than treating it as a separate, forgotten project.
Boards and executive teams can support the effort with one question at each campaign launch: what changed on the donation page since the last time we checked, and who approved it? A short written answer is the kind of evidence that insurers and funders increasingly expect, as discussed in an earlier article in this series on documented cybersecurity oversight.
Defend the Form Against Card Testing
A few practical controls make a large difference against card testing.
Set a reasonable minimum donation amount, so one-dollar tests are not accepted.
Use bot detection, such as a CAPTCHA, on the donation form.
Require the card security code and, where it works for your donors, address verification.
Rate limit attempts, so one source cannot run hundreds of tries in minutes.
Monitor for spikes in declined transactions and set an alert, so you find out in minutes rather than when the processor calls.
Retire old donation pages and event forms you no longer use, and redirect them to your current page.
None of these require a large budget. Most are settings in the donation platform or the website.
What to Do If You Suspect a Compromise
Speed matters. If you suspect skimming or a card testing attack, take the donation form offline or switch to a safe fallback, such as a clean page hosted by your processor.
Contact your payment processor immediately. They can advise on investigation requirements and help identify affected cards. Preserve logs and evidence rather than deleting anything.
Have the site examined by a qualified professional to find and remove the malicious code and close the entry point. Change all administrator and hosting credentials.
Work with counsel to determine your notification obligations to donors and regulators, and notify your cyber insurance carrier if your policy requires prompt notice. Communicate to your board and, as appropriate, to donors, plainly and promptly. An earlier article in this series on vendor breaches described why donors blame the organization they gave to, not the vendor behind the incident.
What This Means for Miami and South Florida Nonprofits
South Florida nonprofits operate in an environment that magnifies this risk in several ways.
Giving here is highly episodic. Hurricane relief drives, galas, auctions, and community campaigns create sudden surges in online donations, often through pages built quickly under pressure and rarely reviewed afterward. Those are exactly the pages attackers favor.
The donor base is international. Gifts arrive on cards issued across Latin America, the Caribbean, and Europe, which makes fraud harder to spot and makes foreign-issued stolen cards easier to blend in.
Many organizations here run small teams. A gala coordinator and a volunteer webmaster may be the only people responsible for the donation experience.
And Florida’s breach notification law applies to organizations that hold Floridians’ personal information, including card data in many circumstances, and can require notice to the state Attorney General for larger incidents. Confirm the specifics with counsel, but the practical point is that the notification clock can begin before the investigation is complete.
Ask Your IT Provider These Questions
Do we have a current list of every script and service that loads on our donation pages, and do we know why each one is there?
Is our donation form hosted by a compliant processor, and how does that provider protect its payment page?
Is our website platform, theme, and every plugin up to date, and are unused ones removed?
Is multifactor authentication enabled on every website and hosting administrator account, and have former users been removed?
Do we have monitoring that alerts us if website files change unexpectedly?
Do we have card testing protections on our forms, and have we retired old event pages?
If your IT provider cannot answer these clearly, the page your donors trust may be carrying code nobody has looked at in years.
Your Donors Trust the Page, Not the Plumbing
Donors do not think about scripts, tags, or processors. They think about your mission and, for a few seconds, they trust a web page with their card number.
Protecting that trust does not require a security team. It requires knowing what is on the page, keeping it maintained, and choosing vendors who take the responsibility seriously.
ITva Technologies provides managed IT and cybersecurity services for nonprofits across Miami-Dade and Broward, with specific experience reviewing the websites and third-party tools that sit between donors and the organizations they support.
Our managed IT services include website and plugin maintenance, administrator access reviews, and an inventory of the tools connected to your donation process.
Our cybersecurity services include change monitoring on your website, multifactor authentication, vendor security reviews, and incident response planning for the day a processor calls with bad news.
If your organization has never inspected what loads on its donation page, that is worth doing before your next campaign launches.
Schedule a free donation page security assessment with ITva.
We will inventory what runs on your page, review your maintenance and access controls, and show you where a skimmer or a card tester could get in.
Because the donation succeeded and the processor saw nothing unusual.
That was exactly the problem.
Frequently Asked Questions
What is e-skimming?
E-skimming is an attack in which a malicious script is placed on a payment page and copies card details as donors type them, before the data reaches the legitimate payment processor. The donation still succeeds, which is why it often goes unnoticed for weeks.
How does a third-party widget compromise a donation page?
Widgets, plugins, analytics tools, and tag managers load code from outside sources into your page. If one of those sources is compromised or an outdated plugin is exploited, the malicious code runs on your page and can capture card data.
What is a card testing attack?
Criminals use a donation form to run many stolen card numbers through small transactions, often one dollar, to find which cards are still active. Nonprofit forms are common targets because they let the user choose the amount and ask for little verification.
Does PCI compliance apply to nonprofits?
Yes. PCI DSS applies to any organization that accepts card payments. Using a hosted, compliant donation platform reduces the burden, but the current standard also expects organizations to know what scripts run on payment pages. Confirm the details with your processor.
What is the simplest first step to protect a donation page?
List every script and service that loads on the page, remove anything not essential, and use a payment form hosted by a reputable processor so card entry stays in the provider’s environment.
What should we do if we think our donation page was compromised?
Take the form offline or switch to a clean hosted page, contact your payment processor, preserve logs, have the site professionally examined and cleaned, change all credentials, and work with counsel on notification obligations and your insurer on required notice.