Do Embedded Payment Forms Affect PCI Compliance for Local Governments?

Last reviewed: August 2026 | Applies to: Local governments and public entities using online card-payment pages, payment links, or embedded payment forms.

Quick Read

Do embedded payment forms affect PCI compliance?

Yes. An embedded payment form or iframe can affect a local government’s PCI compliance responsibilities, even when the payment provider handles card entry and transaction processing. The agency-controlled webpage around the embedded payment element may still need protection from unauthorized scripts that could affect the payment experience. The validation approach depends on the agency’s full payment environment and the requirements of its acquirer or other compliance-enforcing entity.

A hosted payment page, a secure payment link, and an embedded payment form may all look like simple ways for residents to pay online. They are not the same from a payment-security standpoint.

The difference comes down to where card-entry fields appear and which organization controls the webpage around them. A redirect or payment link can send residents to a provider-hosted page. An embedded payment form places the provider’s payment element inside a webpage your agency controls. That distinction can affect the controls and documentation your agency needs to maintain.

Hosted Pages, Payment Links, and Embedded Forms

Start by identifying which payment model each department uses. Residents should have a simple payment experience, but your finance, IT, and web teams need to understand how payment data moves behind the scenes.

Payment Model	What the Resident Sees	What the Agency Should Confirm
Redirect to a Hosted Payment Page	The resident clicks Pay Now and leaves the agency website to complete payment on a provider-hosted page.	Confirm the link is correct, provider documentation is current, and agency systems do not collect card data.
Secure Payment Link	The resident receives a text or email link and enters card information on a provider-hosted page.	Confirm who can send payment links, what information appears in the message, and that the link points to an approved provider destination.
Embedded Payment Form or Iframe	Card-entry fields appear inside an agency-controlled webpage, even if the payment provider delivers and hosts the fields.	Confirm which scripts run on the agency page, who can change the page, and what evidence shows it is protected from script attacks.

Hosted payment pages and secure payment links can reduce the number of agency-controlled components around card entry. They do not eliminate the need to understand your payment flow or complete applicable PCI validation. They may, however, simplify the web-page controls your agency needs to manage.

What Is a Referring Payment Page?

A referring payment page is an agency-controlled webpage that contains an embedded third-party payment form. A utility department, for example, may have a Pay Your Bill page on the city website that loads a payment provider’s iframe within the page.

The payment provider may handle card entry and transaction processing inside that embedded element. The city webpage around it can still load analytics tags, tag-manager containers, chat widgets, accessibility tools, cookie-consent scripts, and custom JavaScript.

That surrounding page matters because a malicious or unauthorized script could alter the resident’s experience, interfere with the payment element, or attempt to capture information before it reaches the provider.

Example

A city utility website may display a resident’s balance with a Pay Now button. If the button sends the resident to a processor-hosted payment page, the city site does not host the card-entry fields. If payment fields appear inside an iframe on the city utility page, that page should be treated as a referring payment page and managed accordingly.

Why Scripts Matter on Payment Pages

Most website scripts are legitimate. They support analytics, accessibility, communications, forms, and other normal website functions. The risk comes from unnecessary or unmanaged scripts on pages connected to payment collection.

Payment-page script attacks are often called ecommerce skimming or web skimming. They are different from a physical skimmer attached to a countertop terminal. In a web-skimming attack, malicious code is added to a webpage or a third-party dependency and runs in the resident’s browser.

Review Scripts That Run on Payment-Related Pages

✓ Tag-manager containers and all tags deployed through them

✓ Analytics and visitor-behavior tools

✓ Chat widgets, virtual assistants, and feedback tools

✓ Accessibility overlays and browser-side enhancement tools

✓ Cookie-consent and privacy-management scripts

✓ Web forms, calendar tools, maps, surveys, and embedded media

✓ Custom code added by an internal team, web agency, or billing-system vendor

This does not mean removing every script from your website. It means payment-related pages should receive a higher level of discipline. Keep scripts with a clear purpose. Know who approved them. Review changes before publication.

When the SAQ A Update May Apply

SAQ A may apply to some local-government agencies that fully outsource electronic card-data functions to PCI DSS-compliant payment providers. It is not based on whether an organization is public or private. Eligibility depends on the agency’s actual payment channels, technical implementation, and the requirements of its acquirer or other compliance-enforcing entity.

SAQ A Eligibility: A Practical Starting Point

An agency should not assume it qualifies for SAQ A simply because it uses a hosted payment page or iframe. As a practical starting point, an agency considering SAQ A should be able to confirm all of the following:

✓ All electronic cardholder-data functions are fully outsourced to PCI DSS-compliant third-party service providers.

✓ The agency does not electronically store, process, or transmit cardholder data on agency systems or premises.

✓ The agency retains only paper reports or receipts with account data, if any, and those records are not received electronically.

✓ The payment provider and other relevant service providers can provide current PCI DSS compliance documentation for the services used.

✓ The agency meets the specific ecommerce eligibility criteria that apply to its payment model, including the script-attack criterion for applicable embedded third-party payment forms.

✓ The agency’s acquirer, payment facilitator, or other compliance-enforcing entity accepts SAQ A as the appropriate validation method.

Important

This is a practical summary, not a substitute for the official SAQ A eligibility criteria or advice from your acquirer or qualified assessor. If your agency accepts cards at a counter, enters card data through a virtual terminal, records calls that contain card data, stores electronic card data, or uses a website that does not meet every SAQ A eligibility criterion, a different validation approach may apply.

For agencies that qualify for SAQ A and use an embedded third-party payment form or iframe, the updated ecommerce eligibility criteria are especially important. Agencies that do not meet every SAQ A eligibility criterion may need a different validation approach, such as SAQ A-EP or SAQ D, as directed by their acquirer or compliance program.

PCI SSC updated SAQ A for ecommerce merchants in 2025. The updated questionnaire removed PCI DSS Requirements 6.4.3 and 11.6.1 from SAQ A, but it added an eligibility criterion for ecommerce merchants with embedded third-party payment forms or pages.

For an eligible SAQ A merchant, the criterion requires confirmation that its site is not susceptible to attacks from scripts that could affect the ecommerce system. PCI SSC FAQ 1588 clarifies that this criterion applies when a merchant webpage includes an embedded payment page or form, such as an iframe. It does not apply to a simple redirect to a provider site or a payment link that sends the payer to a provider-hosted page.

For an applicable embedded payment form, FAQ 1588 describes two general paths:

1. Use controls that protect the referring payment page from script attacks. This can include maintaining a script inventory, authorizing scripts, supporting script integrity, and detecting unauthorized changes.

2. Obtain confirmation from the PCI DSS-compliant payment provider or third-party service provider. The provider must confirm that, when its embedded payment solution is implemented according to its instructions, the solution includes techniques that protect the payment page from script attacks.

Important

A provider’s general PCI DSS Attestation of Compliance is not automatically the same as written confirmation that its embedded payment solution addresses the specific script-attack eligibility criterion for your agency’s implementation. Ask for documentation that applies to the exact payment product and integration model you use.

Requirements 6.4.3 and 11.6.1 remain relevant for entities and validation paths where they apply. In plain language, these controls focus on knowing which scripts run on payment or referring payment pages, confirming that scripts are legitimate, and detecting unauthorized changes that could affect payment security.

Payment-Page Checklist for Public Entities

Use this checklist when your agency has an embedded payment page or iframe, is redesigning a payment page, or is reviewing an existing online payment flow.

Identify Every Payment-Related Page

✓ Utility payment pages

✓ Tax and assessment payment pages

✓ Court and citation payment pages

✓ Permit, license, recreation, and registration payment pages

✓ School fee, tuition, transportation, and activity-payment pages

✓ Any department-specific page that embeds a payment element

Document the Payment Model

For each page, document whether the resident is redirected to a hosted payment page, sent through a payment link, or presented with an embedded payment form. Keep a screenshot and a simple data-flow diagram with the record.

Inventory Scripts on Embedded-Form Pages

For each script that loads or executes in a resident’s browser on a referring payment page, record:

✓ Script name and source domain

✓ Business or technical purpose

✓ Owner or approving department

✓ Whether it is first-party or third-party code

✓ Date last reviewed

✓ How the agency confirms it remains authorized and unchanged

Limit Page-Editing Access

Not every web editor needs permission to alter payment pages. Use role-based access in the content-management system, keep administrative accounts current, and require review before changes are published to pages with embedded payment elements.

Retain Provider Guidance

Keep the provider’s implementation instructions with the payment-page record. If the provider states that its embedded solution provides script-attack protections, retain that written confirmation and evidence that your agency followed the required implementation steps.

Review After Meaningful Changes

Revisit the page after changing your website theme, tag manager, analytics tools, cookie banner, accessibility vendor, web agency, payment provider, billing integration, or embedded payment configuration.

Questions for Payment and Web Vendors

Do not leave the technical details to assumption. Ask direct questions and retain the answers in your vendor-management file.

Questions for Your Payment Provider

✓ Is our payment flow hosted, redirected, or embedded?

✓ If embedded, is our agency page considered a referring payment page for this implementation?

✓ Can you provide current PCI DSS compliance documentation for this payment product?

✓ Does our implementation qualify for SAQ A, or should we validate through another SAQ or process?

✓ If SAQ A applies, can you provide written confirmation addressing the script-attack eligibility criterion for the embedded solution?

✓ What implementation steps are required for that confirmation to apply?

✓ What website, billing-platform, or integration changes require a new review?

✓ Do you offer a hosted payment page or payment-link option that may better fit our operational and compliance goals?

Questions for Your Web Agency or Internal Web Team

✓ Which scripts run on payment-related pages today?

✓ Who can add or remove scripts through the CMS, tag manager, or site code?

✓ What review occurs before a script is added to a referring payment page?

✓ How are third-party plugins and JavaScript libraries updated and monitored?

✓ Can we produce a change history for the payment page and its scripts?

✓ Are we using any script or tag that is not necessary for the payment experience?

Keep Change Control Simple

This does not mean online payments need to become more complicated. It means your agency should understand how each payment channel is built, know which vendors are involved, and apply tighter change controls to the small number of webpages connected to payment collection.

A Workable Process for Many Public Entities

Step 1. Flag payment-related pages in the CMS. Maintain a simple list of URLs and page owners.

Step 2. Require approval for script changes. Finance, IT, or the designated payment owner should review additions to embedded payment pages.

Step 3. Document the reason for every script. If no one can explain why it is there, remove it or investigate before leaving it in place.

Step 4. Use a before-and-after check. Confirm that a page update did not change the approved payment element, scripts, headers, or destination links.

Step 5. Retain the evidence. Save change tickets, approval emails, screenshots, and provider guidance in the payment-security folder.

Good Governance Does Not Require Doing Everything Manually

A provider-hosted page or secure payment-link option can simplify the resident payment experience and reduce the number of agency-controlled components around card entry. The right model depends on resident experience, billing-system integration, department needs, and your agency’s validation requirements.

Frequently Asked Questions

Does SAQ A apply to local government agencies?

It can. SAQ A is not limited to private businesses, but a public entity must meet all SAQ A eligibility criteria. In general, that means electronic card-data functions are fully outsourced to PCI DSS-compliant third parties. The correct validation approach depends on the agency’s payment channels, technical implementation, and the direction of its acquirer or other compliance-enforcing entity.

Does a payment iframe make our agency responsible for all PCI DSS controls?

Not necessarily. Scope and validation requirements depend on the complete payment flow and the criteria that apply to your agency. An embedded form can reduce direct handling of card data, but it can also create responsibilities for the agency-controlled referring payment page. Confirm the appropriate validation approach with your acquirer, payment provider, or qualified assessor.

Does this apply if we redirect residents to a provider-hosted payment page?

PCI SSC states that the SAQ A eligibility criterion described in FAQ 1588 applies to ecommerce merchant webpages that include an embedded third-party payment page or form. It does not apply to a simple redirect to a provider website or a payment link that sends a payer to a provider-hosted site. Other PCI DSS requirements may still apply based on your environment.

What counts as a script on a referring payment page?

Scripts can include custom JavaScript, tag-manager tags, analytics tools, chat widgets, accessibility tools, cookie-consent tools, third-party libraries, and other browser-side code. The practical question is whether the code loads or executes in the resident’s browser on the payment-related page.

Can our payment provider handle script-attack protection for us?

PCI SSC FAQ 1588 describes a path where a PCI DSS-compliant payment provider or third-party service provider confirms that its embedded payment solution includes techniques that protect the merchant payment page from script attacks when implemented according to the provider’s instructions. Request written confirmation that applies to your specific product and implementation, then retain evidence that you followed the instructions.

Who should be involved in this review?

At minimum, involve the payment owner in finance or treasury, the IT or security lead, and the web team or web vendor. Include the department that owns the payment experience, such as utilities, courts, tax, permits, or education, when its billing system or resident workflow is involved.

What should we do if we cannot explain how a payment page is built?

Pause before making unrelated website changes. Ask the payment provider and web team to document the current flow, identify whether the page is hosted, redirected, or embedded, and list the scripts running on any agency-controlled referring payment page. That baseline will support the right next step.

Review Your Online Payment Flow

Make online payments easier to manage.

IntelliPay helps public entities offer payment options across hosted pages, payment links, online portals, in-person channels, and billing-system workflows. Talk with our team about an approach that supports a clear resident experience and a manageable payment environment for your agency.

Talk to a Payment Consultant