A County Treasurer’s Guide to PCI Compliance in 2026

By Dale Erling, IntelliPay | Payment technology and government payment systems

It's a common assumption in government offices: "we're not a retailer, surely this doesn't apply to us the same way." It's an understandable instinct, but it's not how Visa or Mastercard sees it. If you process a card payment, the card networks apply the same rules to a courthouse that they apply to a grocery store. There's no government carve-out.

Why this is worth your attention

Private companies weigh PCI risk mostly in dollars — fines, remediation costs, higher processing rates after an incident. Counties carry an additional cost that's harder to put a number on: public trust. A breach involving tax or court payment data becomes a story about whether the county can be trusted with residents' information, and that story tends to stick around longer than the incident itself.

There's also a quieter risk in the systems many counties are still running. A lot of offices still lean heavily on paper checks, mail, and legacy terminals, partly because staff know them and partly because replacing them means budget requests and change management nobody wants to own. Those older processes aren't magically safe just because they're familiar — check fraud and mail theft are real, ongoing problems — and they make it harder to reason about your actual exposure, because the risk is spread across a mailroom, a counter terminal, and whatever spreadsheet someone is using to track it all.

The simplest strategy: don't let card data reach you at all

For most counties, the cleanest path is keeping raw card data out of county systems wherever possible. Use hosted payment pages, properly configured payment terminals, and processor-managed tools so card data is handled inside the provider's secured environment rather than on county servers, desktops, email, or paper forms.

Here's what that looks like in practice. A resident pays $2,847 in property taxes online. Their card number goes directly into the processor's hosted payment page. What comes back to your system is a token — something like "Token ABC123, $2,847, parcel 456-789-012" — plus whatever transaction detail you need for reconciliation. Not the card number itself.

Counties often assume a hosted payment page means PCI is "handled." It reduces your card-data exposure dramatically, which is exactly why it's usually the right direction. But it doesn't mean you get to stop asking questions. Someone in your office still needs to know which departments take payments, which vendors touch the process, who has access on your end, and what happens when any of that changes. And even when card entry is fully outsourced, counties should expect to maintain annual PCI validation responsibilities — typically the applicable Self-Assessment Questionnaire and Attestation of Compliance required by their acquirer or processor. That's a common point of confusion: outsourcing narrows the work, it doesn't make it disappear.

What actually drives the cost

A single dollar figure is the thing everyone wants for a budget request, but it's also the least honest number I could give you here. "PCI compliance cost" isn't one line item — it's several that get lumped together: assessment fees, processor implementation, terminal hardware, portal integrations, consultant time, and ongoing processing costs. Blending all of that into one number tends to be more misleading than useful. What actually moves the needle is this:

My advice: ask any processor you're evaluating to itemize their quote against these categories specifically, rather than accepting a single bundled annual figure. It's the only way to compare two proposals honestly, and it's the only way your commissioners can tell what they're actually approving.

What actually changed with PCI DSS 4.0

PCI DSS 4.0 was published back in 2022, but it came with a phase-in period — a batch of "future-dated" requirements that were treated as best practice until they became mandatory on March 31, 2025. That date has already passed, so if your county hasn't addressed those requirements yet, it's not a future planning item anymore, it's a current gap. The one most likely to touch county staff directly is the expanded multi-factor authentication expectation, including MFA for access into the cardholder data environment — though the exact implementation depends on your access method, system design, and which specific requirement applies to your setup. Your processor or QSA should be able to tell you exactly what that means for your environment.

The standard also introduced a "customized approach," letting organizations meet a requirement's intent through an alternative control instead of the prescribed method. It sounds like flexibility, and it is, but it comes with a catch: you have to document and defend why your alternative provides equivalent protection. For most counties, sticking with the standard, prescribed approach is simpler to implement and far easier to defend in an audit than building and justifying a custom one.

One more practical point: any new way residents can pay you — a parking app, an online permit portal, a new phone-payment line — needs a risk assessment before it launches, not after. A short internal form that IT and the treasurer's office both sign off on before a new payment option goes live will save you from finding out about a gap after residents are already using it.

The newer threats worth knowing about

County systems are an attractive target partly because they can lag behind private-sector security investment, and criminals have gotten better at exploiting that gap. The threat most county offices are likely to run into isn't a dramatic, movie-style hack. It's a believable email asking accounts payable to update a vendor's banking information, a fake message about a state grant, or a caller claiming to be from a payment vendor who needs "urgent" access to a terminal or portal. AI has made these attempts more convincing — better spelling, better tone-matching, references to real county news — but the underlying scam is the same one that's targeted vendor payments for years.

None of this means you need to become a security expert yourself. It does mean two things are worth tightening up: closer oversight of any third-party vendor who can touch your payment systems, since attackers often go after the vendor rather than you directly, and a habit of verifying anything unusual — a payment instruction change, an urgent request — through a channel you already trust, not the one the message came in on. Automated monitoring tools can help surface unusual activity faster than someone manually watching logs, but they don't replace a person who actually knows the county's normal payment patterns, vendors, and approval process. The final call on anything that could affect resident services should still go through a human.

Who pays the processing cost: the county or the resident

Beyond security, the other decision that comes up in almost every conversation I have with a treasurer's office is who absorbs card processing costs. Say a resident pays a $500 property tax bill and the processing cost runs about $14. If the county absorbs it, the county nets $486 and the resident pays $500. If the county passes that cost through as a service fee, the county nets the full $500 and the resident pays $514 total.

At volume, even a modest per-transaction cost becomes a real budget line. Before deciding whether the county absorbs it or moves to a service-fee model, run the numbers with your own transaction count, average payment size, card mix, and payment channels — the answer looks different for a county doing a few thousand card payments a year than one doing tens of thousands.

A lot of treasurers land on service fees for a fairness reason as much as a budget one: when the county absorbs the cost, residents who pay by check or bank transfer are effectively subsidizing the convenience of residents who pay by card. A service fee shifts that cost to the people actually choosing the card option. One caution here — surcharging and service fee rules vary by card network, by payment type (debit works differently than credit in a lot of states), and by state law. Get your fee program reviewed by your processor and legal counsel before you roll it out, not after.

Getting started: a 90-day plan

Days 1–30, assessment. Map every way residents currently pay you — online, in person, phone, mail. Document who handles payments and how. Start looking at PCI-compliant processors with actual government experience, and begin drafting your budget request for next fiscal year.

Days 31–60, building support. Bring your findings to the commissioners, framed around risk and public trust rather than technical detail. Meet with every department head who accepts payments. Have counsel review your existing processing contracts, and start vendor selection under your normal procurement rules.

Days 61–90, implementation planning. Select a processor based on government experience and pricing you can actually explain to a commissioner, schedule staff training, write an incident response procedure specific to your office, and put a recurring compliance calendar on the books.

Talking to commissioners, residents, and staff

With commissioners, lead with risk and trust, not technical architecture: protecting taxpayer information, avoiding a breach that damages the county's reputation, meeting the security bar residents already expect from their bank, and reducing legal exposure.

With residents, keep it concrete: you're upgrading systems to better protect their financial information, the new setup meets the same security standards they're used to from major retailers, and the changes are aimed at preventing fraud, not adding friction.

With staff, keep the rules short and memorable: never write down a card number for any reason, log out of payment systems when you step away, and report anything that looks off to a supervisor immediately.

Frequently asked questions

Sources and further reading

• PCI Security Standards Council, PCI DSS v4.0.1 official documentation.
• PCI DSS 4.0 future-dated requirements, mandatory as of March 31, 2025, including multi-factor authentication for the cardholder data environment.
• Guidance on merchant PCI obligations when outsourcing card processing, including annual SAQ and Attestation of Compliance requirements for fully outsourced merchants.