Processore di pagamenti rilevato

Cosa verifica questo controllo

Scansiona la pagina per fingerprint di processori di pagamento — sorgenti script, origini iframe, globali JS — e riporta quale processore (se ce n’è uno) gestisce il checkout. È informativo. Ma la sua presenza alza la posta su ogni altro controllo di sicurezza nell’audit.

Perché è importante

Se rileviamo un processore di pagamenti, stai prendendo dati di carta nella sessione dell’utente. Questo ti mette in scope per PCI DSS, e sui siti in giurisdizione PSD2 in scope per Strong Customer Authentication. I controlli seguenti diventano non negoziabili invece che nice-to-have:

• HTTPS sul tuo sito — PCI DSS 4.2.1 richiede TLS per qualunque pagina coinvolta nella trasmissione di dati di carta.
• Abilitare HSTS — previene gli attacchi di downgrade che spogliano TLS dalle submission di checkout.
• Attributi sicuri dei cookie — Secure; HttpOnly; SameSite=Lax sui cookie di sessione blocca il furto di token via XSS e CSRF.
• Protezione clickjacking — X-Frame-Options / CSP frame-ancestors fermano gli attaccanti dal mettere in frame il tuo checkout dentro il loro dominio per rubare click.

Su un sito marketing, header di sicurezza deboli sono cattiva forma. Su un sito che prende pagamenti, sono un breach in attesa e una passività di audit.

Come sistemarlo

Questo controllo è informativo, quindi l’azione dipende da cosa è stato rilevato.

Euristiche di rilevamento, per riferimento. MetricSpot fa fingerprinting di:

• Stripe — <script src="https://js.stripe.com/v3/">, window.Stripe, iframe da js.stripe.com.
• PayPal — <script src="https://www.paypal.com/sdk/js">, data-paypal-button, paypal.Buttons.
• Adyen — checkoutshopper-live.adyen.com come src script, 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.
• Lemonsqueezy — app.lemonsqueezy.com, LemonSqueezy.Setup.

Scegli una modalità di integrazione che riduce lo scope PCI. Tutti i grandi processori offrono tre integrazioni di checkout, in ordine dallo scope PCI più alto al più basso:

1. API diretta (dati di carta grezzi postati al tuo server) — PCI DSS SAQ D, ~300 controlli. Evita a meno che tu non abbia un team compliance.
2. Campi embedded (Stripe Elements, Braintree Hosted Fields, Adyen Components) — i campi carta sono iframati dal processore; il tuo server non tocca mai il PAN. PCI DSS SAQ A-EP, ~140 controlli.
3. Redirect / Hosted Checkout (Stripe Checkout, PayPal Smart Buttons, Paddle, Lemonsqueezy) — l’utente viene reindirizzato a una pagina ospitata dal processore. PCI DSS SAQ A, ~20 controlli.

Per quasi tutti i siti SaaS ed ecommerce, il checkout hosted è il default giusto. Paddle e Lemonsqueezy vanno oltre agendo da Merchant of Record — gestiscono IVA UE, sales tax USA e chargeback. Cedi qualche punto percentuale di margine e recuperi settimane di lavoro di compliance.

Strong Customer Authentication (3DS). Se vendi a clienti UE/UK e usi API diretta o integrazioni embedded, devi innescare 3D Secure sulle transazioni prive di un’esenzione riconosciuta. Stripe, Adyen e Braintree espongono tutti flag setup_future_usage / authentication_required. Testa con le carte di challenge 3DS lato issuer nella sandbox di ogni processore prima del lancio.

Set minimo di header di sicurezza per qualunque pagina che includa un processore di pagamenti:

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

Vedi abilitare HSTS, protezione clickjacking, referrer policy e attributi sicuri dei cookie per ognuno in dettaglio.

Domande frequenti

Usiamo Stripe Checkout (hosted). Si applica ancora PCI?

Sì — ma allo scope più basso (SAQ A). Auto-attesti annualmente che il tuo sito include solo codice di redirect/iframe controllato da Stripe, che i tuoi server non vedono mai dati di carta e che il tuo sito è servito su TLS con cifrari attuali. Stripe fornisce un template SAQ A pre-compilato. Il checkout hosted non rimuove PCI; lo rende piccolo abbastanza da stare in una sola pagina.

Perché MetricSpot segnala un processore di pagamenti su una pagina senza checkout evidente?

Due casi comuni: una pagina di prezzi che carica js.stripe.com per un pulsante “Compra ora”, o un widget “Dona via PayPal” nel footer. Lo script è caricato sito-wide anche se il checkout avviene solo su una rotta. Quello è comunque in scope — ogni pagina che carica codice SDK di pagamento è in scope PCI per quella pagina. Carica l’SDK in lazy-load solo sulla rotta di checkout per ridurre lo scope.

Apple Pay o Google Pay cambiano i requisiti?

Riducono l’attrito, non i requisiti. I token di Apple Pay e Google Pay scorrono attraverso il tuo processore esistente (Stripe, Adyen, Braintree), e il tuo scope PCI resta al livello SAQ che la tua modalità di integrazione detta. SCA è automaticamente soddisfatta perché il wallet stesso è un fattore di autenticazione forte — Visa e Mastercard lo trattano come esenzione di autenticazione delegata.