# Payment pages

> Tell Script Monitoring which pages take payment with selectors in Setup step 4, test a real checkout URL, and choose whether only payment pages report.

Source: https://docs.scriptmonitoring.com/payment-pages/ · Plan: All plans · Updated 2026-10-13

Payment pages are the pages where card data is entered. You list them once, as URL selectors in **Developers > Setup**, step 4, **Scope**, and that one list decides both what counts as a payment page for the tag and what a PCI DSS report counts as one, so the two cannot drift apart. Script Monitoring needs them for PCI DSS 6.4.3 and 11.6.1 evidence. For security monitoring alone, every page reports and there is nothing to set.

## Which use case should I choose?

The use case in step 1 decides how much of your site reports. You can change it later without reinstalling.

| Use case | What reports | Payment pages |
| --- | --- | --- |
| Client-side security | Every page. You see every third-party script, everywhere. | Not needed. |
| PCI DSS 6.4.3 & 11.6.1 | Only payment pages, once you turn on **Only payment pages report**. The tag still ships on every page. | Required. |
| Both | Every page, and your payment pages are also tracked as a named PCI scope. | Required. |

![Setup step 1, Use case: choose Client-side security, PCI DSS 6.4.3 & 11.6.1, or Both.](https://docs.scriptmonitoring.com/screenshots/setup-step-1-light.webp)

**PCI DSS** alone is the narrow setting: nothing outside checkout is inventoried, so Vendors, Alerts and Blocks only show what runs on a payment page. Pick **Both** if you also want cover on the rest of the site.

## How do I add a payment page?

1. Open **Developers > Setup** and go to step 4, **Scope**.
2. Under **Payment page selectors**, type a selector and click **Add selector**. A path such as `/checkout` applies to every domain in the team.
3. Add one selector per checkout route. Each appears as a chip; click its **x** to remove it.

Some teams see their domains as tabs in this step, each with its own list of paths, and an **Import CSV** button that replaces each listed domain's payment pages with the ones in the file. The selectors work the same way.

![Payment page selectors for checkout.northwind.com: /checkout and /checkout/:step, where :name matches one path segment and * matches anything.](https://docs.scriptmonitoring.com/screenshots/setup-payment-pages-light.webp)

## How do I write a selector?

Selectors are URL patterns, matched with the same matcher the tag uses:

| Selector | Matches |
| --- | --- |
| `/checkout` | `/checkout` on every domain in the team. |
| `/checkout/:step` | `/checkout/payment`, `/checkout/review`: `:name` matches one path segment. |
| `/pay/*` | Anything under `/pay/`: `*` matches anything in a segment. |
| `shop.example.com/checkout` | `/checkout` on that host only. |
| `/#/checkout` | A single-page app route after the `#` (fragment routing). |

- Query strings are stripped before matching. A selector with `?` in it can never match.
- The protocol and port do not matter, and a trailing slash is optional.
- A selector can be up to 512 characters, and a team can have up to 500.

## How do I check a selector before relying on it?

Use **Test a real URL** under the selectors. Paste a real checkout URL, for example `https://checkout.example.com/checkout/payment`:

- **Matches**: "A visit to this URL is monitored and counts as a payment page in your PCI evidence." The note names the selectors that matched.
- **No match**: the page is not a payment page. It is still monitored, but does not count in your PCI evidence. If only payment pages report, it would be delivered but never monitored.

On a single-page app, a miss here is the most common setup mistake: make sure the selector describes the route your router actually produces.

## What warnings can Scope show?

| Warning | What to do |
| --- | --- |
| No payment page defined | Your use case is PCI DSS or Both and there is no selector. Without one, 6.4.3 has no inventory and 11.6.1 has no page to watch, and it looks the same as a quiet week. Add a selector. |
| No domain here is marked as taking payment | Selectors exist, but none matches a domain in this team. Add a selector for the host that takes payment. |
| Fragment routing, but a selector has no fragment | Your site routes with `#/`. Write `/#/checkout`, not `/checkout`. |
| Path routing, but a selector uses a fragment | Remove the `#`, or switch the site to fragment routing in step 2. |
| A selector contains a query string | Query strings are removed before matching. Scope on the path. |

## What does "Only payment pages report" do?

With the **PCI DSS 6.4.3 & 11.6.1** use case, the **Only payment pages report** switch narrows reporting to your selectors. On every page no selector matches, Script Monitoring stops:

- inventorying the scripts that run there,
- alerting on new or changed scripts there,
- collecting the evidence that blocking and the Vendors, Alerts and Blocks pages rely on there.

The tag keeps loading on every page. Turn the switch off at any time and every page reports again.

Its guards:

- It is available only after a selector has matched a real page in the last 7 days. Until then it says "Available once a selector matches a real page in the last 7 days."
- Turning it on asks you to confirm. Turning it off is one click.
- Setup never turns it on by itself. Switching the use case to **Client-side security** or **Both** turns it off.
- If an edit leaves no usable selector, it switches off and Scope says so: "Only payment pages report was turned off."

Super admins and Admins of the team can change it and edit selectors. Viewers cannot.

## Where else are payment pages shown?

The **Payment pages monitored** tab of the PCI DSS page lists every page in scope and the pages no selector covers: see [PCI DSS 6.4.3 & 11.6.1](https://docs.scriptmonitoring.com/pci-dss/#what-does-the-payment-pages-monitored-tab-show).

## Frequently asked questions

### Do I need payment pages if I only want security monitoring?

No. With **Client-side security** every page reports and there is nothing to configure in step 4. Payment pages are needed for PCI DSS 6.4.3 and 11.6.1 evidence, so pick **Both** if an assessor is going to ask.

### Why can't I turn on "Only payment pages report"?

It becomes available once one of your selectors has matched a real page in the last 7 days. It is only offered with the **PCI DSS 6.4.3 & 11.6.1** use case.

### Does "Only payment pages report" remove the tag from other pages?

No. The tag keeps loading on every page. Pages that no selector matches stop sending anything, so they are not inventoried, not alerted on, and not counted as evidence.

### My checkout is a single-page app with routes after a #. What do I type?

Write the fragment into the selector, such as `/#/checkout`. With fragment routing the path is `/` on every route, so `/checkout` never matches.

### Do query strings matter?

No. Query strings are stripped before matching, so anything after `?` in a selector can never match. Scope on the path instead.

## Related

- [PCI DSS 6.4.3 & 11.6.1](https://docs.scriptmonitoring.com/pci-dss/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)
- [Install the script tag](https://docs.scriptmonitoring.com/install/)