Payment Pages

PCI DSS 4.0 scopes its two script requirements to the payment page: 6.4.3 asks that every script on it is authorized and inventoried, and 11.6.1 that unauthorized changes to its scripts and security headers are detected. A payment page is the page hosting your payment form, or the page embedding your payment provider’s iframe.

HeaderHawk collects reports for a whole site. Marking your payment pages lets you look at, and be alerted about, just those pages.

Note

Payment pages are included in the Professional and Business plans. On another plan, pages you marked earlier are kept and shown read-only, and the filters and payment-page alerts stop using them until the plan includes them again.

Marking a page

Open Headers, and choose the site in the header. Each page has:

• a label, such as “Checkout payment step”;
• a kind: a payment page, or another page worth watching, such as a login page;
• a pattern matching the page’s URLs;
• a scan URL: one real URL the pattern matches. A payment page needs one. It is the URL the daily scan fetches (Header Monitoring).

A site can have up to 25 pages.

Pages this site reports from lists the page URLs the site has sent violations or script reports from in the last 30 days, busiest first. Mark as payment page fills in the label, an exact pattern and the scan URL. When several of those URLs differ in one part of the path, as /checkout/8f3a/payment and /checkout/91bc/payment do, the editor offers the pattern that matches them all.

As you type a pattern, the editor lists which of the site’s recent page URLs it matches, so a pattern that catches your blog, or nothing at all, shows before you save it.

The pattern

https://checkout.example.com/cart/*/payment

• The scheme is https or http, and must match exactly.
• The host must be one the site accepts reports from. A wildcard host such as *.example.com is allowed only when the site allows that wildcard.
• In the path, * matches anything within one part of the path, and ** as the last part matches everything below it: /account/** matches /account/ and /account/cards/edit, but not /account.
• A trailing slash counts only if you write one.
• Query strings and fragments are ignored, so /checkout?step=payment and /checkout?step=cart are the same page. A pattern containing ? or # is refused rather than accepted and silently ignored.

A site’s host cannot be removed while a page depends on it: the change is refused, naming the pages to change or delete first.

Filtering to payment pages

Once a site has a payment page, Payment pages only appears on the Issues list and the Explorer, and the Scripts page opens on its Payment pages tab. It is matched when you look, so a page you mark today also filters the reports that arrived before you marked it.

Alerts on payment pages

An alert rule with On payment pages only sends only what happened on the site’s payment pages: issues seen there, a policy change reported from one of them, and the scan results of pages marked as payment pages. A new violation on your checkout reaches on-call while one on your blog does not.

Alerts use a page from the moment it is saved

Views apply a new or edited page to history immediately. Alerts do not: whether a report was on a payment page is decided as the report is processed, so a page you mark or change applies to reports that arrive after you save it.

A rule scoped to payment pages is sent immediately. A daily or weekly digest covers every page of its sites, so a rule cannot be both.

What marking a page does not decide

Marking a page records which pages matter to you. Which PCI DSS requirements apply to your integration, and what counts as evidence for them, is for you and your assessor to decide.