“Our Payment-Page Scripts Need an Inventory”—What Should Sales Verify?

A buyer opens a chat with “Our payment-page scripts need an inventory.” Before you respond, verify five facts: the page architecture, each script owner, the change authorization, the integrity evidence, and who owns the validation decision. Those five answers tell you whether the request belongs in discovery, specialist review, or a watch list, and keep you from doing the buyer’s compliance interpretation for them.

A payment-page script is code, usually JavaScript, that runs on a checkout page and is often supplied by a third party such as an analytics vendor, an anti-fraud tool, or the processor’s own payment form. PCI DSS, the Payment Card Industry Data Security Standard, is the set of baseline technical and operational requirements that payment brands and acquirers apply to payment account data. According to the PCI Security Standards Council’s PCI DSS standard page (accessed 1 August 2026), the brands, acquirers, and program operators decide who must comply or validate; the merchant does not decide alone.

Two requirements explain the phrase “script inventory.” Requirement 6.4.3 manages payment-page scripts: an inventory with written justification, authorization for each script, and a way to assure its integrity. Requirement 11.6.1 detects unauthorized changes to payment pages and the relevant HTTP headers, the request and response metadata a browser exchanges with a server. The PCI SSC published dedicated guidance for both on 5 February 2026.

Key facts

• PCI SSC, Guidance for PCI DSS Requirements 6.4.3 and 11.6.1 (published 5 February 2026): 6.4.3 covers authorization, integrity assurance, and an inventory with written justification; 11.6.1 covers detecting unauthorized changes to payment pages and relevant HTTP headers.
• PCI SSC FAQ, How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts? (updated 1 April 2026): the cited script criterion applies to merchants whose page embeds a third-party service provider or processor payment form, not to redirect or fully outsourced setups.
• PCI Security Standards Council, PCI DSS standard page (accessed 1 August 2026): payment brands, acquirers, and other program operators determine whether an entity must comply with or validate against a PCI SSC standard.
• Telegram Privacy Policy (accessed 1 August 2026): bots added to groups may have message access or not, the interface shows which, third-party bots should ask permission, and users can revoke Business chatbot permissions.

These dates show how recent the guidance is; they are not evidence that a buyer is behind, in trouble, or ready to buy. A script-inventory request can come from an acquirer nudge, an internal audit, or plain housekeeping.

The qualification card: five fields

Fill one card per request. A blank field is a routing outcome, not a failure.

1. Page architecture. Is the checkout an embedded form (processor code runs inside the buyer’s page), a redirect (the buyer leaves the page for a hosted payment page), or fully outsourced? The FAQ’s script criterion applies specifically to the embedded case.

2. Script owner. Who maintains each script, internal engineering, an analytics vendor, an anti-fraud vendor, the processor? If the buyer cannot name an owner, the inventory is aspirational, not operational.

3. Change authorization. Who approves a script change, and where is the approval recorded? Requirement 6.4.3 expects authorization to be documented, so “we approve changes” is weaker than “approvals live in our change ticket log.”

4. Integrity evidence. Where does the evidence that scripts are unchanged live, such as subresource integrity hashes (values that pin exact file content), change-detection logs, or 11.6.1-style monitoring? Ask where the evidence lives, not just whether it exists.

5. Validation decision. Who decides which questionnaire applies? Normally the compliance-accepting entity, often the acquirer. SAQ A, the Self-Assessment Questionnaire A, is a short self-attestation form used by eligible merchants; route the questionnaire decision to the buyer’s compliance contact rather than making it in sales.

A composite example

The following message is illustrative and composite, a typical shape rather than a real customer message:

“Hi, our acquirer flagged that we need to manage scripts on the checkout page. Can your team help us put an inventory together? We are not sure which page type we count as.”

Worked example. The buyer names no architecture, owner, evidence, or decision-maker, so the card starts with five blanks. On the call, the lead asks one architecture question; the buyer answers that they embed the processor’s form. That matches the embedded case in the FAQ, so the card routes to specialist review for a script-inventory discussion, while the questionnaire decision stays with their compliance-accepting entity. If the buyer had said “we redirect to a hosted page,” the card would route to a lighter discussion; if the buyer goes quiet, the card sits on a watch list until they return. Requests like this often surface in provider-focused group conversations first; a look at 3,000 messages about payment providers shows how common the pattern is.

Why this matters, and what stays unknown

Why it matters: when a buyer asks a compliance-shaped question, the tempting move is to answer it. But a sales lead who interprets PCI DSS on the buyer’s behalf carries risk the buyer never asked them to take and slows the deal while guessing at scope. The card keeps the conversation on facts the buyer can actually answer, which is also how compliance pressure becomes visible as a real opportunity; the compliance-driven vendor switching signal is a separate pattern you can recognize once the card is filled.

What stays unknown: whether the buyer must comply at all, which questionnaire applies, and whether any vendor change is planned. Their program operator decides scope, and only the buyer’s engineers can confirm architecture and owners. Silence or missing answers is not evidence of intent; record the blanks and keep the request moving on the buyer’s timeline.

FAQ

Does a request for a script inventory mean the buyer is already failing an assessment? Not necessarily. It can be preparation for an upcoming assessment, an acquirer nudge, or internal housekeeping. The card records facts; severity is for the buyer’s compliance-accepting entity to judge.

Who decides which questionnaire, like SAQ A, applies to the buyer? The compliance-accepting entity, typically the acquirer or a payment brand, per the PCI Security Standards Council’s standard page. Sales should route that question to the buyer’s compliance contact and internal specialists rather than answer it.

Can I treat an inventory request as a buying signal? Yes, as an early intent signal worth tracking, but only alongside a completed card. Missing answers are not evidence of intent; keep the request on a watch list until the buyer supplies details.

Once the card is filled and routed, you can decide whether this request pattern is worth tracking. Tools like TOP Prospect can surface similar conversations in the Telegram groups you already follow; the pillar on Telegram group conversations as business signals explains the method. TOP Prospect processes only Telegram groups you intentionally connect and are authorized to access, produces candidate signals for a person to review rather than fact certification, leaves the final decision to a person, and does not contact group members automatically.

A light next step: keep a five-field card template in your notes. The next time “we need an inventory” lands, you will know exactly which blanks to fill before you route.

Frequently asked questions

Does a request for a script inventory mean the buyer is already failing an assessment?

Not necessarily. It can be preparation for an upcoming assessment, an acquirer nudge, or internal housekeeping. The card records facts; severity is for the buyer's compliance-accepting entity to judge.

Who decides which questionnaire, like SAQ A, applies to the buyer?

The compliance-accepting entity, typically the acquirer or a payment brand, per the PCI Security Standards Council's standard page. Sales should route that question to the buyer's compliance contact and internal specialists rather than answer it.

Can I treat an inventory request as a buying signal?

Yes, as an early intent signal worth tracking, but only alongside a completed card. Missing answers are not evidence of intent; keep the request on a watch list until the buyer supplies details.

Sources and further reading

1. PCI SSC, Guidance for PCI DSS Requirements 6.4.3 and 11.6.1 (5 February 2026)
2. PCI SSC FAQ, How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts? (updated 1 April 2026)
3. PCI Security Standards Council, PCI DSS standard page (accessed 1 August 2026)
4. Telegram Privacy Policy (accessed 1 August 2026)