# Tutelarsi dal testing delle carte Informazioni su questa attività fraudolenta e su come tutelarsi Il testing delle carte è un tipo di attività fraudolenta in cui qualcuno cerca di verificare se i dati di carte di pagamento rubate sono validi, per poi utilizzarli per effettuare acquisti. Un malintenzionato può farlo acquistando dati di carte di credito rubate e tentando quindi di convalidare le carte o di effettuare acquisti con esse, per capire quali sono ancora valide. Il testing delle carte è noto anche con i termini “carding”, “testing degli account”, “enumerazione” e “controllo delle carte”. Un’attività fraudolenta come il testing delle carte è una componente inevitabile del commercio online. Tale attività, tuttavia, ha ripercussioni sull’intero ecosistema dei pagamenti, per cui gli esercenti, i circuiti delle carte di credito e Stripe sono tutti tenuti a fare il possibile per contrastare questo fenomeno. In Stripe, miglioriamo costantemente gli strumenti e i sistemi per rilevare e ridurre le frodi, ma è necessario essere sempre vigili. ## Come funziona il testing delle carte Chi esegue il testing delle carte utilizza sia la configurazione delle carte sia i pagamenti per determinare se i dati delle carte rubate o ottenute tramite enumerazione in loro possesso siano validi o meno. Per convalidare rapidamente un numero elevato di carte, i malintenzionati utilizzano script per testare grandi quantità di dati delle carte contemporaneamente e raccolgono le risposte 3DS o delle società emittenti per identificare quali dati delle carte siano validi. Dopo aver individuato le carte valide, possono utilizzarle per effettuare acquisti presso gli esercenti oppure rivendere le carte confermate sul dark web. - **Configurazione della carta**: questo metodo è preferito dai truffatori perché le verifiche e le autorizzazioni effettuate durante la configurazione della carta generalmente non compaiono sugli estratti conto dei titolari. Ciò riduce la probabilità che i titolari delle carte si accorgano dell’attività fraudolenta e la segnalino. - **Pagamenti**: chi esegue il testing delle carte effettua pagamenti di importo modesto, che i titolari delle carte sono meno propensi a notare e segnalare come fraudolenti. ## Conseguenze del testing delle carte Il testing delle carte ha molti risvolti negativi, alcuni dei quali peggiorano con il tempo se tale attività continua. - **Contestazioni**: molti tipi di testing delle carte comportano pagamenti, alcuni dei quali vanno a buon fine. I clienti notano i pagamenti andati a buon fine e li segnalano come frode, il che genera [Avvisi precoci di frode](https://docs.stripe.com/disputes/measuring.md#early-fraud-warnings) o perfino [contestazioni per frode](https://docs.stripe.com/disputes.md) che ti costano tempo e denaro. - **Tassi di rifiuto di pagamento più elevati:** il testing delle carte associa alla tua attività un numero elevato di pagamenti rifiutati. Un tasso di rifiuto elevato può compromettere la reputazione della tua attività presso gli società emittenti delle carte e i circuiti di pagamento, facendo apparire tutte le tue transazioni come più rischiose. Di conseguenza, anche i pagamenti legittimi potrebbero essere rifiutati più spesso, persino dopo la fine degli attacchi di testing delle carte. - **Commissioni supplementari:** l’attività di testing delle carte può comportare commissioni supplementari, ad esempio per le autorizzazioni di piani tariffari personalizzati e per le contestazioni. - **Sovraccarico dell’infrastruttura**: l’attività di testing delle carte genera solitamente numerose richieste e operazioni sulla rete. Questo traffico supplementare può sovraccaricare la tua infrastruttura a danno dell’attività legittima. - **Danni all’integrità dell’ecosistema**: l’attività di testing delle carte ha un impatto negativo sul sistema finanziario nel complesso, pertanto Stripe e i nostri partner finanziari ti aiuteranno ad arrestarla. Un’elevata attività di testing delle carte che genera preavvisi di frode o contestazioni potrebbe, ad esempio, farti inserire nei [programmi di monitoraggio delle carte](https://docs.stripe.com/disputes/monitoring-programs.md). - **Riduzione della qualità dei dati per il funzionamento della tua attività**: i ricavi derivanti dal testing delle carte potrebbero apparire come nuovi clienti positivi nei tuoi dati, quindi diventa difficile per te avere una visione chiara della tua reale crescita aziendale. ## Lista di controllo per l’attività di testing delle carte Se la tua integrazione è obiettivo dei tester di carte, ti consigliamo di adottare immediatamente le seguenti misure: - [Identifica](https://docs.stripe.com/disputes/prevention/card-testing.md#identify-card-testing) l’attività di testing delle carte. - [Rimborsa](https://docs.stripe.com/refunds.md) i pagamenti fraudolenti per evitare contestazioni. - [Utilizza un’integrazione consigliata da Stripe](https://docs.stripe.com/disputes/prevention/card-testing.md#optimize-integration) o aggiungi [misure di mitigazione](https://docs.stripe.com/disputes/prevention/card-testing.md#control-implementation) per eliminare l’attività di testing delle carte. - Monitora la tua integrazione per assicurarti che le misure di mitigazione siano efficaci. ## Identificare l’attività di testing delle carte Puoi identificare la maggior parte dell’attività di testing delle carte da un aumento significativo delle autorizzazioni e dei pagamenti non riusciti. La maggior parte degli attacchi è visibile nella Dashboard Stripe. I sintomi più comuni a cui prestare attenzione sono: - **Un picco di pagamenti non riusciti o bloccati**. Puoi vedere le tendenze nella [pagina iniziale della Dashboard](https://dashboard.stripe.com/dashboard), nella vista elenco [transazioni](https://dashboard.stripe.com/payments) ed esaminare i motivi del blocco nella pagina dei dettagli di pagamento. - **Un picco di richieste con errori 402**. Puoi vedere il picco di volume nella pagina [Sviluppatori](https://dashboard.stripe.com/developers), esaminare gli errori 402 nella pagina [Log non riusciti](https://dashboard.stripe.com/logs?error_type=card_error) o ascoltare i webhook e le risposte API, in particolare con un [esito di “generic_decline”](https://docs.stripe.com/declines/codes.md). - **Picco di pagamenti sospetti** con transazioni di importo ridotto, spesso con nomi di clienti e email privi di senso. Per evitare contestazioni, ti consigliamo di rimborsare le transazioni sospette se riescono a superare le difese esistenti. ## Prevenire il testing delle carte Per ostacolare i sistemi di blocco, i truffatori che operano con le carte di credito ricorrono a diverse strategie. Di conseguenza, regole o filtri firewall semplici basati su un’unica euristica come gli indirizzi IP non sono in genere sufficienti da soli per prevenire l’attività di testing delle carte. I tester di carte possono utilizzare la tua chiave pubblicabile e utilizzarla per ritentare un numero elevato di pagamenti sul tuo sito web. Esistono due principali strategie di mitigazione per questi attacchi: - **Utilizza un’integrazione Stripe consigliata**: scegli un’integrazione consigliata da Stripe per usufruire di una protezione dal testing delle carte di comprovata efficacia. - **Implementazione dei controlli**: investi in una suite di controlli per impedire a chi esegue il testing delle carte di attaccare gli endpoint vulnerabili. Oltre a implementare strategie di mitigazione, è necessario assicurarsi di tenere le chiavi al sicuro e di non pubblicarle. Quando le tue credenziali vengono divulgate o rubate, i tester di carte possono creare pagamenti e configurare carte utilizzando la tua chiave privata. > Se non sei uno sviluppatore oppure utilizzi un plugin o una piattaforma, la prevenzione e la mitigazione del testing delle carte richiedono generalmente modifiche a livello di codice. Mostra questa documentazione allo sviluppatore o al fornitore che ha scritto il codice e collabora con queste figure per prevenire il testing delle carte. ### Usare un’integrazione consigliata da Stripe Se utilizzi la versione più recente di Stripe Payment Element o Checkout, disponiamo di numerosi controlli automatici e manuali per mitigare il testing delle carte, tra cui limitatori di frequenza, modelli di IA, attivazione di CAPTCHA, revisioni continue e altro ancora. Quando rileviamo un attacco di testing delle carte ai danni del tuo account, selezioniamo dinamicamente le contromisure più appropriate per limitarne l’impatto il più possibile, consentendo al tempo stesso agli utenti legittimi di continuare a effettuare transazioni con il minimo impatto. Questi pagamenti sono contrassegnati come `Blocked by Stripe`. *Tuttavia, l’efficacia dei controlli di Stripe dipende dalla tua integrazione e dai fattori di rischio che ci trasmetti. Utilizziamo numerosi fattori di rischio per distinguere il testing delle carte dai pagamenti legittimi. Sebbene alcuni di questi fattori vengano calcolati automaticamente, molti dipendono dalle informazioni fornite dalla tua integrazione. In generale, più dati la tua integrazione ci fornisce, maggiore sarà l’efficacia della prevenzione contro il testing delle carte.* Ti consigliamo di utilizzare una delle [integrazioni consigliate](https://docs.stripe.com/payments/online-payments.md#compare-features-and-availability) da Stripe per sfruttare la protezione automatica basata su [CAPTCHA](https://www.hcaptcha.com/). Le moderne soluzioni CAPTCHA utilizzano molteplici fattori di rischio per aumentare il livello di verifica in presenza di comportamenti ad alto rischio, pur rimanendo per lo più invisibili agli utenti legittimi del tuo servizio. Se desideri disattivare l’integrazione CAPTCHA di Stripe, contatta l’[assistenza Stripe](https://support.stripe.com/contact/login). L’utilizzo di una delle integrazioni di pagamento consigliate da Stripe ti consente di sfruttare al meglio le funzionalità di prevenzione contro il testing delle carte offerte da Stripe. Se non puoi utilizzare un’integrazione consigliata, includi il maggior numero possibile di dati oppure implementa controlli personalizzati. Sebbene i controlli per il testing delle carte siano separati dalla protezione di Radar contro le contestazioni fraudolente, si basano [sugli stessi fattori di rischio utilizzati da Radar](https://docs.stripe.com/radar/optimize-risk-factors.md). L’inclusione delle informazioni riportate di seguito nei tuoi pagamenti può migliorare significativamente le prestazioni dei modelli di Stripe per il rilevamento del testing delle carte. Le integrazioni consigliate da Stripe raccolgono automaticamente queste informazioni, mentre con le integrazioni dirette potrebbe essere necessario includerle esplicitamente. - [Rilevamento avanzato delle frodi](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection.md) (Impatto massimo) - Indirizzo IP - Indirizzo email del cliente - Nome del cliente - Indirizzo di fatturazione ### Implementazione dei controlli Aggiungendo restrizioni agli endpoint mirati, puoi eliminare e prevenire l’attività di testing delle carte. Le restrizioni implementate possono rendere impraticabile l’attività di testing delle carte, producendo al tempo stesso poco o nessun impatto sul tuo traffico legittimo. Gli endpoint obiettivo dei tester di carte di norma consentono loro di eseguire una delle seguenti operazioni: - Salvare la carta. - Effettuare un pagamento. Le misure di sicurezza specifiche che aggiungi alla tua integrazione variano a seconda della tua situazione e delle esigenze della tua attività. Di seguito descriviamo diversi approcci comuni. ### Implementare CAPTCHA I tester di carte utilizzano spesso script automatici che i CAPTCHA possono bloccare. Gli script sono particolarmente efficaci se non utilizzi una delle integrazioni consigliate che supportano CAPTCHA. Le moderne soluzioni CAPTCHA offrono opzioni per CAPTCHA visibili e invisibili, a seconda delle tue esigenze. Se hai aggiunto un CAPTCHA alla tua integrazione, ma il testing delle carte non cessa, verifica i seguenti punti: - Accertati che il CAPTCHA imponga una convalida per tutte le richieste che permettono la convalida delle carte o i pagamenti con Stripe. - Consulta la documentazione sul CAPTCHA per verificare di averlo implementato sul lato server. - Se utilizzi un captcha che fornisce un punteggio, regola la soglia al di sotto della quale le richieste vengono bloccate. - Prova un’altra soluzione CAPTCHA. Ad esempio, passa da un CAPTCHA invisibile a uno visibile oppure utilizza una soluzione CAPTCHA completamente diversa. ### Limitare l’accesso al modulo di pagamento Più è facile per i malintenzionati accedere al tuo modulo di pagamento (ad esempio, utilizzando il checkout come ospite), più è facile per loro eseguire attacchi di testing delle carte. Puoi ridurre la tua esposizione ai tester di carte richiedendo il login o la convalida della sessione prima che possano effettuare un pagamento. Alcune delle [misure di sicurezza che proteggono dagli attacchi CSRF (Cross-Site Request Forgery)](https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) sono efficaci anche contro alcuni tipi di testing delle carte, come i token CSRF. ### Aggiungere limiti di velocità In alcuni casi, puoi ridurre il testing delle carte aggiungendo limiti di frequenza di networking (ad esempio, nel front-end del tuo negozio online). Adatta questi limiti di frequenza per bloccare l’attività specifica di verifica delle carte che stai subendo. Ad esempio, per evitare un utilizzo eccessivo della tua integrazione da parte dei tester di carte durante la convalida (associando nuove carte a nuovi clienti), potresti implementare un blocco. Questo limiterebbe il numero di nuovi clienti che possono essere creati dallo stesso indirizzo IP nell’arco di una giornata. Oltre ai limiti di frequenza del circuito, puoi aggiungere limiti di frequenza ai tuoi pagamenti e al flusso di pagamento del carrello per [rilevare e prevenire comportamenti insoliti](https://docs.stripe.com/disputes/prevention/card-testing.md#prevent-unusual-behavior) anche dopo l’accesso o la registrazione. ### Rilevare e prevenire comportamenti insoliti Usa la Dashboard, i [webhook](https://docs.stripe.com/webhooks.md) o il monitoraggio continuo con [Stripe Sigma o le pipeline di dati](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) per monitorare le anomalie nel tuo traffico. Puoi confrontare l’attività di testing delle carte con il tipico traffico legittimo, quindi creare filtri che limitino o impediscano solo l’attività di testing delle carte. Ad esempio, puoi configurare il tuo sistema in modo da: - Limitare il numero di carte che possono essere aggiunte a un account - Limitare il numero di clienti che possono essere creati con un singolo indirizzo IP - Limitare il numero di acquisti che possono essere effettuati con lo stesso prodotto - Limitare il numero di clienti dello stesso tipo che possono essere creati - Filtrare le richieste con determinati agenti utente o altri parametri A tale scopo, puoi utilizzare le [regole personalizzate](https://docs.stripe.com/radar/rules/reference.md#velocity-rules) di Radar, se il [tuo piano](https://docs.stripe.com/radar/how-radar-works.md#compare-plans) supporta questa funzione. ### Utilizzare più misure di mitigazione del testing delle carte A volte è consigliabile combinare più approcci per ridurre il testing delle carte e massimizzare l’impatto sull’attività fraudolenta senza produrre effetti negativi sul traffico legittimo. Ad esempio, puoi combinare CAPTCHA e limiti di velocità in modo che il primo tentativo di pagamento da un indirizzo IP riesca senza restrizioni, ma che le richieste effettuate dallo stesso indirizzo IP nelle ore successive richiedano una verifica captcha per andare a buon fine. ### Effettuare nuovi tentativi con prudenza Un numero eccessivo di nuovi tentativi di pagamento (sollecito) può sembrare testing delle carte se si verifica in picchi improvvisi con un basso tasso di successo. Il sollecito e i veri attacchi di testing delle carte possono avere effetti simili sulla tua attività, ad esempio inducendo le società emittenti ad adottare un approccio più restrittivo nella valutazione del rischio. Assicurati di non continuare a effettuare nuovi tentativi sulle carte associate a clienti fraudolenti dopo un attacco di testing delle carte, poiché ciò finirebbe per ripetere l’attacco originale. La funzionalità [Smart Retries](https://docs.stripe.com/billing/revenue-recovery/smart-retries.md#non-retryable-decline-codes) di Stripe tiene già conto di questo aspetto. ### Personalizzare la protezione in base alla tua propensione al rischio Oltre alle misure di mitigazione dell’implementazione, potrebbe essere utile ottimizzare ulteriormente la protezione utilizzando Radar, che offre regole di blocco integrate basate sulle [verifiche bancarie](https://docs.stripe.com/radar/rules.md#traditional-bank-checks), come la verifica del *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number). Se comprendi il comportamento del tuo cliente e desideri personalizzare in dettaglio la velocità dei pagamenti, puoi creare [regole personalizzate](https://docs.stripe.com/radar/rules/reference.md#velocity-rules) in Radar, se il [tuo piano](https://docs.stripe.com/radar/how-radar-works.md#compare-plans) supporta questa funzione. Puoi trovare alcuni esempi nella [Guida sui concetti di base di Radar](https://stripe.com/guides/radar-rules-101#rules-that-help-prevent-card-testing-or-card-cashing). ## See also - [Rilevamento avanzato delle frodi](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection.md) - [Ottimizza la tua integrazione Radar](https://docs.stripe.com/radar/optimize-risk-factors.md) - [Proteggere le chiavi](https://docs.stripe.com/keys-best-practices.md) - [Guida sui concetti di base di Radar](https://stripe.com/guides/radar-rules-101)