Who Owns PCI Compliance When a Vendor Takes Your Registration Payments?

Your finance director forwards one line from the city's auditor: "Confirm the department's PCI status for online registration." You forward it to your software vendor. The reply comes back in four words. "We are PCI compliant." Everyone relaxes. Nobody has answered the question.

The question was never whether the vendor is compliant. It is whether your department is still on the hook, and how much of the card data problem the vendor actually took off your desk. The short answer from the PCI Security Standards Council: PCI DSS applies to merchants who outsource all payment processing too, because it covers any entity that stores, processes, or transmits cardholder data "regardless of whether these activities are conducted directly or by a third-party service provider."

Two very different things sound identical in a proposal

A vendor can reduce your PCI scope. In that case, the Council says many requirements may then not apply directly to you, but you still verify the provider's compliance, keep a written agreement, and monitor the provider's compliance status at least annually. Separately, your department still validates its own compliance, typically with a Self-Assessment Questionnaire such as SAQ A.

A vendor can also leave most of the work with you. Same demo, same checkout screen, very different contract. The SAQ A is only for merchants with account data functions completely outsourced to PCI DSS validated and compliant third parties. If card data still passes through software you configured, or staff key numbers into a terminal at the front desk, that shorter form may not fit. Read the compliance clause in any agreement before you sign.

Both vendors will say they handle PCI. Only one may reduce the validation work that falls to you. Ask your acquirer or payment brand which form applies to your setup.

Four questions that separate them

• Does the vendor hold service-provider status, and will they prove it annually? The Minneapolis Park and Recreation Board wrote this into its recreation software RFP: the contractor "will be annually certified as a PCI compliant service provider" and provide its Attestation of Compliance (AOC) on request.
• Are card numbers stored anywhere? The Rock Island parks department's recreation management software RFP says the system "must comply with PCI Level -1 requirements and must not store credit card numbers." That is a clean version of the ask.
• Do you have audit rights? MPRB's RFP gives it audit rights over the systems that process its cards if the vendor's PCI certification "has lapsed or is otherwise not current." Without a clause like that, a certification claim is hard to verify for the life of the contract.
• Is breach notice in writing? The same RFP has the contractor agree "to provide written notice" of any breach of a system it maintains that contains cardholder data. A verbal promise from a sales engineer is not a notification process.

Put these questions into your evaluation early. Our guides to the recreation software RFP requirements matrix and the demo scorecard show where they fit, and the contract exit rights guide covers what to do if a vendor's certification lapses mid-contract.

The deadline that already passed

PCI DSS 4.0.1 included future-dated requirements that became mandatory on March 31, 2025. On the Council's podcast, the team explains that 51 of the 64 new requirements were future-dated, and that requirements 6.4.3 and 11.6.1 address payment page scripts to reduce the risk of e-skimming. The Council also updated SAQ A so that merchants must confirm their site is not susceptible to attacks from scripts. Ask any vendor how it addresses these current requirements.

One more thing your state may decide for you

How you charge for card acceptance is a separate question from who holds the compliance burden, and card brand rules apply. The Municipal Research and Services Center (MRSC), which advises Washington local governments, explains that surcharges may only be applied to credit cards, capped at the merchant discount rate and not to exceed 4 percent, and that the ban on debit card surcharges is universal. Check the rules that apply to you before you build a fee into your registration prices. For how payments connect to your books, see accounting software integration, and for the basics of the category see what recreation registration software is.

Frequently asked questions

Who is responsible for PCI compliance when a vendor processes registration payments?

Not just the vendor. The PCI Security Standards Council says PCI DSS applies to merchants who outsource payment processing, but many requirements may not apply directly to the merchant. You still need a written agreement, should verify the provider's compliance, and monitor it annually.

Does using a PCI-compliant vendor make my department PCI compliant?

Not automatically. A vendor's certification does not by itself replace your own responsibilities. Your department still validates its own compliance, typically with a Self-Assessment Questionnaire, and should confirm which form applies with its acquirer or payment brand.

What PCI requirements should a recreation software RFP include?

Examples from real park agency RFPs: annual PCI service-provider certification with an Attestation of Compliance on request (Minneapolis), PCI Level 1 with no stored card numbers (Rock Island), audit rights if certification lapses, and written notice of breaches involving cardholder data.

Can a parks department add a surcharge for credit cards?

Check the card brand rules and your local rules. MRSC's guidance for Washington local governments says surcharges apply only to credit cards, are capped at the merchant discount rate not to exceed 4 percent, and debit cards cannot be surcharged.

See what your current payment setup costs in fees and staff hours with a free cost-recovery audit →