PCI DSS for Service Businesses

PCI DSS is a set of security standards created by the Payment Card Industry Security Standards Council (PCI SSC) — representing Visa, Mastercard, American Express, Discover, and JCB. Any entity that stores, processes, or transmits cardholder data must comply.

This includes virtually every service business:

• HVAC, plumbing, electrical, and roofing companies with online payment forms
• Service businesses that take card numbers over the phone
• Municipalities with online utility payment portals
• Schools with online fee payment systems
• Any business using a payment gateway on their website

Compliance is validated through annual Self-Assessment Questionnaires (SAQs) for smaller merchants, or formal audits (QSA assessments) for larger ones. Non-compliance can result in fines from $5,000–$100,000/month from your payment processor, increased transaction fees, or loss of card processing ability.

PCI DSS v4.0 became the only active standard in March 2025. Key changes affecting websites:

• New Requirement 6.4.3 — Payment page script integrity. All scripts running on payment pages must be authorized and have their integrity validated. This directly targets formjacking attacks (malicious scripts injected into payment forms to steal card data). Every third-party script (analytics, chat widgets, tag managers) on a payment page must be inventoried and have a documented purpose.
• New Requirement 11.6.1 — Change and tamper detection. Organizations must have a mechanism to detect unauthorized changes to payment page content (HTTP headers and script contents). This is often implemented via automated monitoring tools.
• Stronger authentication requirements (MFA). Multi-factor authentication is now required for all access into the cardholder data environment — not just remote access.
• Customized approach. v4.0 allows organizations to use compensating controls or alternative approaches — but the security outcome must be demonstrably equivalent.

The simplest way to manage PCI compliance is to reduce your cardholder data environment (CDE) to its smallest possible footprint. For most small businesses, this means:

• Use an iFrame or redirect payment solution. When your payment form is hosted by your payment processor (Stripe, Square, PayPal, Authorize.net) and embedded via iFrame or redirect, your website never touches card data. This qualifies for SAQ A, the simplest self-assessment (22 requirements vs. 300+).
• Never store card data. Your systems should never hold raw card numbers, CVVs, or track data. This is the #1 rule. If you're logging card data anywhere — in forms, emails, or databases — stop immediately.
• Use tokenization. Modern payment processors (Stripe, Braintree) tokenize card data — they store the card securely and give you a token to reference for future charges. Stored tokens are not card data.

On a decoupled, statically-served site like Hydra OS, the attack surface is dramatically smaller than a WordPress site with a database — which directly reduces your PCI scope.

Trades businesses

Most trades businesses use iFrame/redirect payment solutions (Stripe, Square) which significantly simplifies compliance. The risk area is over-the-phone card processing — if your CSRs take card numbers verbally and type them into a computer, that computer is in scope. Using a hosted payment page or IVR for phone payments removes it.

Municipalities

Utility payment portals, online permit fees, and court payment systems all create PCI scope. Many municipalities use third-party payment platforms (GovPay, PayIt, Invoice Cloud) which, when properly configured, manage PCI scope. The risk is when municipalities build custom payment integrations or store transaction details in non-compliant systems.

Schools

School fee collection, lunch payments, and activity fees often use third-party platforms (MySchoolBucks, RevTrak). These platforms typically handle PCI compliance, but schools must verify vendor PCI compliance status and ensure data sharing agreements are in place.