Payment processor detected

What this check does

Scans the page for payment-processor fingerprints — script sources, iframe origins, JS globals — and reports which processor (if any) handles checkout. This is informational. But its presence raises the stakes on every security check elsewhere in the audit.

Why it matters

If we detect a payment processor, you are taking card details in the user’s session. That puts you in scope for PCI DSS, and on PSD2-jurisdiction sites in scope for Strong Customer Authentication. The following checks become non-negotiable rather than nice-to-have:

• HTTPS on your site — PCI DSS 4.2.1 requires TLS for any page involved in card-data transmission.
• Enable HSTS — prevents the downgrade attacks that strip TLS from checkout submissions.
• Secure cookie attributes — Secure; HttpOnly; SameSite=Lax on session cookies blocks token theft via XSS and CSRF.
• Clickjacking protection — X-Frame-Options / CSP frame-ancestors stop attackers from framing your checkout inside their domain to steal clicks.

On a marketing site, weak security headers are bad form. On a site that takes payments, they’re a breach waiting to happen and an audit liability.

How to fix it

This check is informational, so the action depends on what was detected.

Detection heuristics, for reference. MetricSpot fingerprints:

• Stripe — <script src="https://js.stripe.com/v3/">, window.Stripe, iframes from js.stripe.com.
• PayPal — <script src="https://www.paypal.com/sdk/js">, data-paypal-button, paypal.Buttons.
• Adyen — checkoutshopper-live.adyen.com script src, window.AdyenCheckout.
• Braintree — js.braintreegateway.com, window.braintree.
• Square — web.squarecdn.com, Square.payments.
• Mollie — js.mollie.com, Mollie(profileId).
• Razorpay — checkout.razorpay.com, window.Razorpay.
• Paddle — cdn.paddle.com, Paddle.Setup.
• Lemon Squeezy — app.lemonsqueezy.com, LemonSqueezy.Setup.

Pick an integration mode that reduces PCI scope. All major processors offer three checkout integrations, in order from highest PCI scope to lowest:

1. Direct API (raw card details posted to your server) — PCI DSS SAQ D, ~300 controls. Avoid unless you have a compliance team.
2. Embedded fields (Stripe Elements, Braintree Hosted Fields, Adyen Components) — card fields are iframed from the processor; your server never touches PAN. PCI DSS SAQ A-EP, ~140 controls.
3. Redirect / Hosted Checkout (Stripe Checkout, PayPal Smart Buttons, Paddle, Lemon Squeezy) — the user is redirected to a page hosted by the processor. PCI DSS SAQ A, ~20 controls.

For most SaaS and ecommerce sites, hosted checkout is the right default. Paddle and Lemon Squeezy go further by acting as Merchant of Record — they handle EU VAT, US sales tax, and chargebacks. You give up a few percentage points of margin and reclaim weeks of compliance work.

Strong Customer Authentication (3DS). If you sell to EU/UK customers and use direct API or embedded integrations, you must trigger 3D Secure on transactions that lack a recognized exemption. Stripe, Adyen, and Braintree all expose setup_future_usage / authentication_required flags. Test with the issuer-side 3DS challenge cards in each processor’s sandbox before launch.

Minimum security header set for any page that includes a payment processor:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'; ...
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax

See enable HSTS, clickjacking protection, referrer policy, and secure cookie attributes for each in detail.

Frequently asked questions

We use Stripe Checkout (hosted). Does PCI still apply?

Yes — but at the lowest scope (SAQ A). You self-attest annually that your site only includes Stripe-controlled redirect/iframe code, that your servers never see card data, and that your site is served over TLS with current ciphers. Stripe provides a pre-filled SAQ A template. Hosted checkout doesn’t remove PCI; it makes it small enough to fit on a single page.

Why does MetricSpot flag a payment processor on a page without an obvious checkout?

Two common cases: a pricing page that loads js.stripe.com for a “Buy now” button, or a footer “Donate via PayPal” widget. The script is loaded site-wide even though checkout only happens on one route. That’s still in scope — any page that loads payment SDK code is in PCI scope for that page. Lazy-load the SDK only on the checkout route to shrink scope.

Does Apple Pay or Google Pay change the requirements?

They reduce friction, not requirements. Apple Pay and Google Pay tokens flow through your existing processor (Stripe, Adyen, Braintree), and your PCI scope stays at whichever SAQ tier your integration mode dictates. SCA is automatically satisfied because the wallet itself is a strong authentication factor — Visa and Mastercard treat it as a delegated authentication exemption.