Compliance Assessment Tool
Home › PCI compliance by business › Nonprofits and charities

PCI compliance for nonprofits, charities and churches

Short answer. Being a nonprofit does not exempt you from PCI DSS: if your organization accepts card donations, dues or ticket payments, the card security standard applies. Each way you take cards is a separate payment method with its own Self-Assessment Questionnaire (SAQ): a donation page hosted by your donation platform is usually SAQ A, a card reader at events has its own SAQ, and mailed pledge cards typed into a virtual terminal are usually SAQ C-VT. Taking donations several ways does not mean you need SAQ D.

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 methodUsuallyWhy
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.

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.

Your checklist

  1. List every way you take cards: online giving, a form on your website, event readers, kiosks, mailed pledges, phone gifts and recurring gifts.
  2. Ask your donation platform or payment provider which SAQ each product you use supports, and keep the answer in writing.
  3. 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.
  4. 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.
  5. Process pledge cards promptly in the virtual terminal, remove the security code, and shred cards you no longer need.
  6. Brief volunteers before every event and collect all card devices afterwards.
  7. Keep card terminals and kiosks off public and guest Wi-Fi.
  8. 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

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.