Redirects and IFrames Are Being Hacked. How does this impact SAQ A?

Have you ever entered your payment information into a website shopping cart only for it to say that it “couldn’t process” or that your card details were “incorrect?” Did you know this was a good indication that your credit card information had been stolen?

Most don’t understand the risk that new Iframe and redirect hacks pose to their personal credit card information and their small business.

In fact, most SMB owners who outsource their payments to a provider like Stripe, PayPal, or Shopify don’t realize that they still risk being hacked by malicious eskimmers who hijack iFrames and redirects in a way that agent-based solutions simply cannot identify.

Read this blog to discover how this affects SAQ A merchants, what these attacks look like, and how an agentless solution like SecurityMetrics Shopping Cart Monitor can help your business stay safe.

What is SAQ A?

SAQ A merchants typically rely on one of two methods to keep card data off their own servers:

iFrames: The customer stays on your website, but the payment form itself is loaded directly from your payment processor's servers into a defined space on your checkout page. When the customer types their card number, that data goes straight to the processor — it never touches your site or your servers. The processor then sends back a token confirming the payment went through, not the actual card number.
Full Redirects: Your website sends the customer to the processor's own payment page to complete the purchase. The customer’s browser URL changes to the processor's domain, where they enter their card details, and once payment is complete, they're sent back to your "Thank You" page. In the background, the processor sends your server a notification (a webhook) confirming the sale went through.

Both methods are legitimate, PCI-approved ways to avoid the stricter SAQ D requirements. Both also create a false sense of security, because the vulnerability isn't in the processor's system. It's on the front end, your website, running in your customer's browser.

What are Eskimming Attacks?

E-skimming (also known as digital/web skimming) is when threat actors inject malicious JavaScript directly into your website (often through a vulnerable plugin or outdated script) and capture cardholder data in real time, inside the customer's browser, before it ever reaches your supposedly “secure” outsourced processor.

This is why SAQ A merchants are so attractive targets to threat actors. They've done the PCI compliance work, checked the box, and assumed their third-party processor absorbed all risk.

Attackers know SAQ A merchants with agent-based solutions assume they are safe and that they won’t anticipate this type of attack.

How Attackers Go After an iFrame

Because an iframe is a window embedded in your page, attackers try to either cover the window or intercept what's typed into it:

The pixel-perfect overlay: Malicious JavaScript detects the checkout page and draws an invisible layer directly on top of the real iframe. The customer thinks they're typing into your processor's secure form. They're actually typing into the attacker's layer sitting one pixel above it.
The proxy attack: A more advanced move where the attacker rewrites your site's code so the iframe loads from a look-alike domain (say, "Stripe-Global-Security.com") instead of the real processor. The fake page captures the data, then quietly hands the customer back to the real checkout so nothing looks wrong.
The double-entry trick: A fake "Error: please re-enter your card details" message appears. The first entry goes to the thief. The second goes to the real form and customers assume it was a glitch.

How Attackers Go After a Full Redirect

A full redirect sends the customer to an entirely different domain, so overlaying anything is harder. Instead, attackers try to change the destination or intercept the process around it:

The link swap: A malicious script hijacks the "Pay Now" click and sends the customer to a spoofed version of the processor's site instead of the real one.
The man-in-the-middle redirect: Attackers alter server-side settings to intercept the "success" signal from the processor, sometimes letting the actual payment go through while stealing the customer's name, address, and email before the redirect even starts.
Phishing the return: After a legitimate payment, the attacker displays a fake "Additional Verification Required" pop-up on the "Thank You" page to capture a CVV or password the bank never actually requested.

None of these attacks touch your processor's systems because all of them happen on your website or in your customer's browser. This makes these attacks invisible to agent-based security tools.

Know the Stats: How Redirect and IFrame Attacks affect Small Businesses:

It’s important to understand just how prevalent these attacks are, so here are some of the latest stats you should know:

Among breached small businesses, 62.5% reported total financial impact exceeding $250,000, and 36.7% topped $500,000 (Identity Theft Resource Center, 2025 Business Impact Report).
The fallout has been significant enough that economists now talk about a "cyber tax" — 38.3% of small business leaders say they've raised prices specifically to cover breach remediation costs (ITRC, 2025 Business Impact Report).
Magecart-style skimmers infected roughly 11,000 unique e-commerce domains in 2024 — a nearly 300% jump from the year before (Recorded Future / Insikt Group, 2024 Fraud Intelligence Report).

Why the FAQ 1588 Update Matters

Recognizing the burden this put on smaller merchants, the PCI Security Standards Council released FAQ 1588 on February 28, 2025, clarifying eligibility criteria for SAQ A. SAQ A merchants used to be on the hook for requirements 6.4.3 and 11.6.1, controls aimed at exactly this kind of client-side, script-based attack.

This update gives SAQ A merchants two paths to eligibility instead:

Use a tool that fulfills those requirements directly, or
Get written confirmation from your PCI DSS-compliant payment processor or third-party service provider (TPSP) that their solution, when implemented correctly, includes techniques to protect your payment page from these attacks.

The intent was to reduce the compliance burden. But it doesn't change the underlying reality: something still needs to be actively watching your checkout page for this exact category of attack. The requirement moved. The threat didn't.

What Agent-Based Solutions Get Wrong

Many client-side security tools rely on browser agents or code embedded in the page itself to detect tampering.

The problem is that a full-redirect checkout, by design, sends the customer away from your site entirely.

An agent sitting on your webpage has nothing to monitor once the customer has left your domain for the processor's domain. This is exactly the blind spot that attackers exploit with link swaps and “man-in-the-middle” redirects.

SecurityMetrics Shopping Cart Monitor takes a different approach. It's an agentless solution so it doesn't require installing code on your site to function.

Instead, it monitors your checkout flow from the outside, which means it can catch redirect-based tampering (such as a hijacked "Pay Now" link that sends customers to a spoofed domain) that agent-based tools are structurally unable to detect, as well as iframe-based threats like overlays and proxy attacks.

You Didn’t Outsource Your Risk, Only Your Payment Processing

Outsourcing your payment processing was the right compliance move. It doesn't make you invisible to attackers; rather, it just moves what they attack. SAQ A merchants need to treat their checkout page itself as an asset worth actively defending, not just a pass-through to someone else's secure system. The businesses getting hit hardest are the ones that assumed the outsourcing was the security.

Do you know if your checkout page has visibility gaps? A quick conversation or demo with our team can help you understand where redirect and iframe monitoring fits into your existing SAQ A compliance.

‍