Free payment page configuration check

Give us the address of your checkout page. We load it once, from our own network, and tell you how it is being served.

The page a customer actually types their card into. https:// only.

Free. No sign-up. Nothing is published. Fifteen checks, plus the scripts written into your page.

What you get back

An invented example, not a real result, so you can see the shape of it before you run one.

Example rows for example.com. Nobody checked this page.
Check Result What we read
HTTPS enforced Good The plain HTTP address redirects to https.
HSTS Weak Present, but it lasts six months and does not cover subdomains.
Content Security Policy Not set No policy header came back, so the browser was told nothing about which scripts may run.

Twelve more rows like those, then the scripts written into the page, with the ones served from a domain other than yours marked as such.

This is not a pass or a fail, and it is not an ASV scan. Our ASV accreditation covers external vulnerability scanning, which is a separate service with its own report. What you get here is a free look at how one page is served.

What we check

Encryption

Whether HTTPS is enforced, whether HSTS is set and how it is scoped, and the protocol, issuer and expiry date of the certificate.

Script control

Whether a Content Security Policy is present, how it is delivered, and whether it reports violations.

Browser protections

Framing, referrer policy, content type sniffing and permissions policy.

Why it matters

A checkout is where card details are typed, so it is the page an attacker most wants to reach. These headers are how a browser is told to refuse what an attack needs: an unencrypted connection, a script from an address you never approved, or your page loaded inside somebody else's.

PCI DSS requirement 6.4.3 asks you to know every script on that page and write down why each one is there. The script list is a starting point for that inventory. What a script inventory involves.

What this check does and does not cover
  • We describe the single response we were sent. A server can be configured to accept an old version of TLS while still agreeing a modern one with us, and we would not see that. Nothing here is a statement about what else your server would accept.
  • We list the scripts in your HTML, and that is not all of them. A tag manager writes its own once the page runs, and so does anything injected into it, so what we can show you from one fetch is a floor and never a total.
  • It is a snapshot, so it cannot tell you what changed. The value of watching a payment page is knowing that something appeared on it last Tuesday. One check on one day cannot do that.

What a check like this cannot do

It describes one page at one moment. The thing that costs a merchant their card data is not how the page is configured today. It is the script that appears on it overnight, from an account nobody was watching, and stays there taking card numbers until somebody notices.

What monitoring adds

  • It looks every day, and dates what it finds, so the answer is "this one first appeared on 14 September" rather than "you have seven scripts".
  • It keeps the written reason for each script, which is the business justification per script that 6.4.3 asks for, and flags the ones still missing theirs.
  • It tells you that it looked, recording which days a scan reached it and which days it did not, so a quiet week is proof rather than silence.
  • It emails you when something new appears, and emails you every week when nothing has, which is the half that proves the first half still works.
  • It hands you the evidence: a dated inventory of every script and the justification you wrote, as a spreadsheet or as a report you can put in front of an assessor.
Get this page checked every dayWhat a script inventory involves

Monitoring is an option on the PCI scanning subscription rather than a separate product, so one price covers the quarterly scan and the daily check of every payment page on your domain.