PCI compliance for nonprofits, charities and churches
Charities, churches, schools and PTAs, clubs and membership organizations often take cards in more ways than a shop does: an online donate page, a giving kiosk in the lobby, a reader at the gala, a monthly gift, a pledge card in the mail. PCI DSS, the card industry's security standard, applies to any organization that stores, processes or transmits card data, whatever its tax status.
The good news is that most small organizations can leave card numbers almost entirely in their donation platform's or payment provider's hands, which keeps each questionnaire short. The real risks are usually human: busy volunteers, paper pledge cards and old spreadsheets of donor card numbers.
How nonprofits and charities usually take cards, and the SAQ for each
Each way you take cards is its own payment method, and each one gets its own SAQ. Most businesses have two or three.
| Payment method | Usually | Why |
|---|---|---|
| Online donation page from your donation platform or payment provider A Donate button that opens a giving page run by your donation platform or payment provider, including monthly gifts, event tickets, membership dues and text-to-give services that reply with a link to a giving page. |
SAQ A SAQ A, when the page and card form come entirely from the provider |
Donors type their card into the provider's page and nothing your organization owns receives the card number. If your website links or redirects donors to that page, SAQ A also asks for external vulnerability scans of your web pages by an Approved Scanning Vendor at least every three months (PCI SSC FAQ 1604). Watch out: If staff or volunteers type donations into that page on donors' behalf, for example during a phone call, that is a different payment method: see phone and mail gifts below. |
| Donation form embedded on your own website A giving form that appears inside a page on your own website, such as your provider's donation widget or its card fields placed in your page, or a donation plugin on your site. |
SAQ A / SAQ A-EP SAQ A if the card boxes are your provider's embedded secure fields and you meet the script condition; SAQ A-EP if your website builds the card form |
Under the January 2025 SAQ A revision, what matters is who supplies the boxes the donor types their card into. Provider-supplied embedded fields (an iframe) are SAQ A, provided you can confirm your site is not susceptible to malicious scripts, which PCI SSC FAQ 1588 lets you do with your provider's written confirmation. A form your own site or plugin builds, which then sends card details to the provider, is SAQ A-EP. Watch out: A plugin that collects card numbers on your own web server, or saves them in your site's database, makes that method SAQ D. Ask whoever built the site which kind of form it is. |
| Card readers at events, services and in the office A tap-and-insert terminal at gala check-in, a giving kiosk in the church lobby, or a reader paired to a volunteer's phone at the auction or bake sale. |
SAQ B-IP / SAQ P2PE / SAQ SPoC SAQ B-IP for a standalone internet-connected terminal, SAQ P2PE if it is a PCI-listed P2PE solution, SAQ SPoC for a phone reader that is a PCI-listed SPoC solution |
In-person SAQs depend on the device and how it connects, so the answer comes from your provider. Ask whether the terminal, kiosk or app is a PCI-listed P2PE, SPoC or MPoC solution and which SAQ they support for it. Watch out: A kiosk or terminal that runs through a computer or shares your office network can move it to SAQ C. Tap-to-pay on a phone with no reader falls under PCI SSC's CPoC or MPoC standards, which have no SAQ named after them, so ask your provider. |
| Mailed pledge cards and gifts by phone A reply card in the annual appeal with spaces for a card number, or a donor who calls the office, and someone types the card into the provider's virtual terminal, a payment page in a web browser. |
SAQ C-VT SAQ C-VT, if you key one gift at a time into a provider-hosted virtual terminal and store no card numbers electronically |
The computer used to type the card number is part of the payment, so it must be protected. SAQ C-VT allows paper records as long as they are kept secure and are never scanned, photographed or received electronically. Watch out: Scanning or emailing pledge cards, keeping card numbers in your donor database, or keeping the security code after the gift is processed breaks these conditions. Printing a QR code or web address for your online giving page on the reply card moves those gifts to SAQ A. |
Find out which SAQ fits each way you take payments, free
Describe how you take payments in your own words. We'll tell you which SAQ fits each one, free, before you pay anything.
Yes, nonprofits need PCI compliance
PCI SSC, the council that writes the standard, says PCI DSS applies to entities that store, process or transmit cardholder data, including merchants. Visa says the same: PCI DSS compliance is required of all entities that store, process or transmit Visa cardholder data. Neither makes an exception for charities, churches or schools. When your organization accepts card donations, it is a merchant in the card networks' eyes.
Showing compliance is usually a yearly Self-Assessment Questionnaire (SAQ) with a signed Attestation of Compliance, sent to your acquirer or processor. Your acquirer, the bank behind your card account, decides which forms you file; Visa says acquirers must make sure their merchants validate at the appropriate level.
If your group takes cards under a parent organization's card account, such as a school district, diocese or national charity, ask the parent organization how it handles PCI for your group before setting anything up.
One SAQ per way you take donations
An SAQ is a checklist written for one kind of payment setup. We treat each way your organization takes cards as its own payment method and match it to the SAQ written for that setup. A church with online giving, a lobby kiosk and mailed pledge cards usually has three short questionnaires, not one long one.
SAQ D, the full questionnaire, is for card numbers that reach your own systems, such as a website that collects them on your server or a database or spreadsheet that stores them, or for a setup that fits no shorter SAQ. Taking donations several ways does not by itself put you there.
Recurring gifts and your donor database
Monthly giving is where card numbers most often creep into an organization's own records. Let your donation platform or payment provider save the card. Your donor database should hold a token (a stand-in reference) and the last four digits, not the full number. If your donor management software stores full card numbers itself, that is electronic storage, and only SAQ D covers it.
Check old exports, spreadsheets and email folders from past campaigns, and securely delete any card numbers you find. Never keep the security code to process a recurring gift: PCI DSS forbids storing it after the payment is approved, and PCI SSC says a donor's permission does not change that.
Pledge cards and other paper
Paper is allowed under the shorter SAQs as long as it stays on paper: never scanned, photographed or emailed. Treat every pledge card with a card number on it like cash.
- Have pledge cards mailed to the office or dropped in a locked box, not passed around.
- Process them promptly, one at a time, straight into your provider's virtual terminal.
- Once the gift is processed, black out or cut off the security code; it must not be kept.
- Keep any cards you must hold on to in a locked cabinet with limited access, then cross-cut shred, incinerate or pulp them when no longer needed, as PCI DSS Requirement 9.4.6 requires.
- Better still, print a QR code or web address for your online giving page so donors pay on the provider's page themselves.
Volunteers, events and shared devices
Volunteers change from one event to the next, so make card handling hard to get wrong. Use your provider's readers or terminals rather than taking card numbers by hand, give volunteers their own logins where the app allows it, and collect every device at the end of the night.
If someone emails or texts a card number anyway, PCI SSC FAQ 1157 says to act quickly: do not reply with the number in the message, delete it securely, complete the gift another way, and tell donors how to give safely.
- Never write card numbers on raffle stubs, auction bid sheets or sign-up forms to charge later.
- Do not let volunteers take card details by text, email or a photo of the card.
- Check readers for signs of tampering before and after events, and lock them up between uses.
- Keep payment terminals and kiosks off the Wi-Fi network the public uses.
- Give volunteers a one-page briefing: how to take a card, what to do if someone offers their number, and who to call with problems.
Your checklist
- List every way you take cards: online giving, a form on your website, event readers, kiosks, mailed pledges, phone gifts and recurring gifts.
- Ask your donation platform or payment provider which SAQ each product you use supports, and keep the answer in writing.
- For a donation form on your own website, find out whether the card boxes are the provider's embedded fields or built by your site, and get the provider's written confirmation for the SAQ A script condition.
- Make sure recurring gifts are stored by the provider, and that your donor database, spreadsheets and email hold no full card numbers or security codes.
- Process pledge cards promptly in the virtual terminal, remove the security code, and shred cards you no longer need.
- Brief volunteers before every event and collect all card devices afterwards.
- Keep card terminals and kiosks off public and guest Wi-Fi.
- Ask your processor which SAQs they expect, and complete one for each payment method every year.
Common questions
Do nonprofits have to be PCI compliant?
Yes, if they accept cards. PCI DSS applies to any entity that stores, processes or transmits cardholder data, and neither PCI SSC nor Visa makes an exception for charities, churches or schools. Your acquirer, the bank behind your card account, is responsible for making sure you validate, usually with a yearly SAQ.
Does using a donation platform make us PCI compliant automatically?
No, but it can make compliance much smaller. If donors give on the platform's own page, that payment method is usually SAQ A, the shortest questionnaire, which you still complete and sign each year. SAQ A also asks you to confirm that you have checked the platform's own PCI DSS compliance.
Is a donation form embedded on our website SAQ A or SAQ A-EP?
It depends on who supplies the card boxes. If they are your provider's secure embedded fields and you can confirm your site is protected against malicious scripts, usually with the provider's written confirmation, it is SAQ A. If your website or a plugin builds the form itself it is SAQ A-EP, and if card numbers reach your server it is SAQ D.
Which SAQ covers text-to-give?
It depends on how the service works. Many text-to-give services text the donor a link to a giving page run by the service; if the donor enters their card on that page, it is treated like any provider-hosted donation page, usually SAQ A. Ask the service how card details are collected.
Can we print a space for card numbers on our mailed pledge cards?
You can, but it creates paper you must protect. Key each card into your provider's virtual terminal (usually SAQ C-VT), never scan or email the cards, never keep the security code after processing, and cross-cut shred them when no longer needed. A QR code to your online giving page avoids most of this.
Can volunteers take card payments at our event?
Yes, using your provider's readers or terminals. Make sure they never write down, photograph or text card numbers, and that devices are collected and checked after the event. Which SAQ covers the readers depends on the device, so ask your provider which one it supports.
We take donations online, at events and by mail. Do we need SAQ D?
Not because of that. Each payment method gets its own SAQ, so that is usually SAQ A for online giving, an in-person SAQ for your readers and SAQ C-VT for mail gifts. SAQ D applies when card numbers reach your own systems or a method fits no shorter SAQ. Your acquirer has the final say.
Ready to see your SAQs?
Describe how you take payments in your own words. We'll tell you which SAQ fits each one, free, before you pay anything.
Other businesses
Sources
- PCI SSC: PCI DSS, who it applies to
- Visa: Account Information Security Program and PCI
- PCI SSC Document Library (PCI DSS v4.0.1 and the SAQs)
- PCI SSC: Important updates for merchants validating to SAQ A (January 2025)
- PCI SSC FAQ 1588: SAQ A eligibility criteria for scripts
- PCI SSC FAQ 1604: ASV scans for SAQ A merchant webpages
- PCI SSC FAQ 1229: What is SAQ C-VT?
- PCI SSC FAQ 1319: Requesting card verification codes
- PCI SSC: Can card verification codes be stored for card-on-file or recurring transactions?
- PCI SSC FAQ 1157: Cardholder data received via an unintended channel
- PCI SSC Bulletin: Sunset periods for the PCI SPoC and PCI CPoC Standards (1 May 2026)
- PCI SSC: List of validated P2PE solutions
- PCI SSC: List of validated SPoC solutions
- PCI SSC: Guide to Safe Payments for small merchants
General guidance, not legal advice. Your acquirer or payment processor decides which SAQ you must file. PCI DSS v4.0.1; content checked 2026-10-23.