Key takeaways
- PCI DSS applies to nonprofits that accept card payments, and using a PCI compliant processor does not make the nonprofit compliant on its own.
- A donation page that redirects donors to the processor's site, or embeds the processor's form, is usually eligible for SAQ A.
- Since April 1, 2025, SAQ A merchants with an embedded form must confirm their site is not susceptible to script attacks that could affect their e-commerce systems.
- A website that does not receive card data but controls how donors or their data reach the processor falls under SAQ A-EP.
- Card security codes from phone, paper or event pledges may never be stored after authorization.
- The acquiring bank or processor that receives your SAQ is the right party to confirm which questionnaire you use.
If your nonprofit takes gifts by card, your processor or bank expects you to validate PCI DSS compliance, usually with a yearly self-assessment that an officer of the organization signs. PCI compliance for nonprofits mostly comes down to how your donation form is built and how gifts by phone, mail and at events are handled. Getting it right protects donor card data, and the trust that comes with it.
Do nonprofits need to be PCI compliant?
Yes. PCI DSS applies to any organization that accepts payment cards, and tax-exempt status does not change that. The obligation reaches a nonprofit through its merchant agreement with the bank or processor that handles its card gifts, and it covers every channel where donors give by card: the website, the phone, the gala and the pledge card.
The most common misunderstanding is that a compliant processor covers the organization. It does not. The PCI Security Standards Council's v4.0 Summary of Changes states that using a PCI DSS compliant third-party service provider does not make an entity PCI DSS compliant. The processor reduces your scope. Your own self-assessment still has to be done.
How does the donation form decide your PCI scope?
Your scope depends on where the card fields come from and who controls the page around them. Each Self-Assessment Questionnaire (SAQ) lists eligibility criteria for a payment channel, and an online donation form usually lands in one of three patterns:
- Redirect. The Donate button sends the donor to a page hosted by the processor or donation platform, and the card is entered there. This is usually the smallest scope, under SAQ A.
- Embedded processor form. The card fields sit on your page but are delivered by the processor, typically in an iframe. This is also SAQ A, with an added condition covered below.
- Site-controlled form. Your website builds the form or controls how the card data is passed to the processor, for example through a direct post or a script on your page. SAQ A-EP covers merchants whose website does not itself receive account data but controls how customers, or their account data, are redirected to a compliant processor. A-EP carries far more requirements than SAQ A, because your web server becomes part of the payment path.
Website plugins and page builders make this easy to get wrong. Two donation forms can look identical to a donor while sitting in different SAQs. The way to know is to ask the processor or platform, in writing, which integration method your form uses.
What changed for embedded donation forms in 2025?
Since April 1, 2025, a nonprofit with an embedded processor form must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems, or it is not eligible for SAQ A. According to the PCI Security Standards Council, the condition applies only to merchants whose webpage includes the processor's embedded payment form. It does not apply to merchants that redirect donors to the processor's page.
PCI SSC FAQ 1588 gives two ways to meet it. The nonprofit can protect its own page using techniques such as those in Requirements 6.4.3 and 11.6.1 (an inventory and authorization of payment page scripts, plus tamper detection), or it can obtain confirmation from its PCI DSS compliant processor that the processor's solution, implemented according to its instructions, protects the payment page from script attacks. For most small nonprofits, the second route is the practical one, and the confirmation should be kept on file.
Script attacks, often called e-skimming, are covered in more depth in our article on PCI 6.4.3 and 11.6.1. They are a separate risk from card testing, where criminals use a donation form to check stolen card numbers with small gifts. Our article on card testing and donation page security covers that one.
How do phone gifts, events and paper pledge cards affect PCI scope?
Each one is a separate payment channel with its own SAQ eligibility, and paper pledge cards carry the most common mistake: keeping the card security code. Card verification codes may be requested when needed to authorize a card-not-present payment, but PCI DSS Requirement 3.3.1.2 strictly prohibits storing them after authorization, even if encrypted, according to the PCI Security Standards Council. A pledge card in a filing cabinet, a spreadsheet of phone gifts, or a photo of a gala form that still shows the security code is a problem the day after the gift is processed.
Phone gifts keyed into a processor's virtual terminal may fit SAQ C-VT, which has its own eligibility criteria about how the terminal is accessed. Card readers at events have their own SAQs as well. Mixing channels can change which questionnaire applies, so list them all before you choose.
Who decides which SAQ your nonprofit uses?
Your acquiring bank or processor decides, because it is the organization that receives your SAQ. The PCI Security Standards Council encourages merchants to contact that entity first and confirm they meet every eligibility criterion before starting a self-assessment. Our guide on choosing the right SAQ walks through each type.
What should a nonprofit do about PCI compliance this quarter?
Start with a short checklist an executive director, CFO or operations lead can assign this month:
- List every way the organization accepts a card gift: website, peer-to-peer campaign pages, phone, events, mail and pledge cards.
- For each online form, get written confirmation from the processor or platform of the integration method: redirect, embedded form or site-controlled.
- If the form is embedded, obtain the processor's confirmation of script attack protection under FAQ 1588, or put 6.4.3 and 11.6.1 controls on your page.
- Collect each provider's current Attestation of Compliance and note its expiration date.
- Find and destroy stored card security codes on paper, in spreadsheets and in email, and change the pledge process so codes are not kept after processing.
- Confirm the SAQ type with your acquirer before completing it.
- Keep the processor confirmations, provider AOCs and your completed SAQ together in the finance committee or board file, so the treasurer can answer when the processor asks.
This article describes what PCI SSC documents say. Your acquirer's contract and requirements govern what your organization must submit.
How does s90 help?
s90 supports nonprofits in Los Angeles and Orange County with managed IT, and offers PCI DSS as a standalone add-on. We map your donation channels, confirm the integration method with your platforms, gather the attestations and confirmations your SAQ depends on, and help clean up stored card data. If you are not sure which questionnaire fits your donation form, start with a conversation.
