PCI DSS script monitoring for university payment pages

More than people expect. PCI compliance higher education scope usually covers tuition and fee payment, housing and meal plans, parking permits, alumni and development giving, conference and event registration, and campus store checkouts. Each is a payment page under 6.4.3 whether or not it sits on the main domain.

Yes, in most cases, and this is the most common misreading. The January 2025 carve-out is narrower than it looks and does not remove the requirement for every merchant using a hosted page. See SAQ A and the script requirements.

Yes, in two stages. Monitoring gives you the record of what was added and when, which is what turns an unenforceable policy into a conversation with evidence. Blocking gives you enforcement when you are ready for it.

No. Domains, subdomains, scripts and users are unlimited on every plan. Page views are the only metered unit.

Yes, through teams under one organisation, each with its own scope, alerting and evidence, while the central team keeps the whole view.

Yes, by CSV import or through the REST API rather than adding pages one at a time. If someone has already compiled the list for a previous assessment, that spreadsheet is the input, and pattern rules cover the subdomains behind it.

This needs unpicking per page. If the page is on your domain, it is your scope even when a vendor built it. If the payment page is entirely on the vendor’s domain, it is theirs, and the page you redirect from may still matter.

Understood, and the free plan is permanent: 1,000 page views a month with both requirements included and no credit card. For most institutions the paid tier that follows is a small line item next to the assessment itself.

A generated pack covering scope, the script inventory with a justification per script, every security-header change with timestamps, and the alerts raised and acknowledged.