SCA Strong Customer Authentication PSD2 su Stripe

SCA (Strong Customer Authentication) è il requisito introdotto dalla direttiva europea PSD2 che obbliga a verificare l'identità del cliente con due fattori per la maggior parte dei pagamenti online. Stripe gestisce automaticamente la conformità SCA per i suoi merchant europei.

Requisiti SCA e fattori autenticazione

SCA richiede l'utilizzo di almeno due dei seguenti fattori: knowledge (qualcosa che sai, es. PIN), possession (qualcosa che hai, es. smartphone), inherence (qualcosa che sei, es. impronta digitale). Per i pagamenti con carta il fattore di possession è solitamente la SIM del cellulare (SMS OTP) o l'app bancaria; quello inherence è biometria via app bancaria.

Esenzioni SCA e flow Stripe

Esistono esenzioni: pagamenti sotto 30 EUR (low value), pagamenti ricorrenti uguali (MIT-recurring), beneficiari fidati (TRA Whitelist), basso rischio (TRA - Transaction Risk Analysis del PSP). Stripe applica automaticamente le esenzioni quando possibile per massimizzare conversion. Con Payment Intent, il flow gestisce SCA tramite 3D Secure 2 in modo trasparente, mostrando challenge solo se necessario.

MOTO e Phone payments

MOTO (Mail Order/Telephone Order) sono pagamenti dove il cliente non è presente al checkout (es. call center prende ordine telefonico, manda fattura per pagamento via link). MOTO è esente da SCA perché' classificato come 'merchant initiated' in pratica. Per qualificare un PaymentIntent come MOTO, aggiungi payment_method_options.card.moto=true e il PaymentMethod deve avere flag moto=true. Stripe restringe MOTO ai merchant approvati (richiesta esplicita) per evitare abusi. Non usare MOTO solo per evitare SCA su transazioni standard: è un'illecito chargeable a downgrade dispute.

Misurare l'impact SCA su conversion

Dopo l'introduzione SCA (settembre 2019, applicazione effettiva 2021), il conversion rate medio dei pagamenti UE è calato 5-10% per via di drop-off su 3DS challenge. Misura il tuo impact: in Dashboard -> Reports filtra per 'requires_action' status e calcola il completion rate. Best practice per ridurre l'impatto: 1) Usa metodi di pagamento alternativi più' fluidi (Apple/Google Pay, SEPA con mandato salvato, Klarna); 2) Pre-popola dati cliente per ridurre fatica checkout; 3) Comunica chiaramente che la banca potrebbe richiedere OTP; 4) Pre-autorizza on_session per acquisti futuri off_session.

SCA in app mobile native

Per app iOS/Android native, SCA si gestisce via Stripe SDK mobile che integra 3DS2 SDK Visa/Mastercard direttamente. UX migliore di web: niente redirect, niente iframe, l'OTP/biometric appare in modale nativa. Setup: iOS - stripe.confirmPayment(paymentIntentClientSecret, viewController) gestisce challenge automaticamente. Android - PaymentLauncher.create(activity, callback).confirm(args) idem. La banca emittente decide quale challenge mostrare (OTP, biometric, decoupled via app banca). Test: usa carta 4000 0027 6000 3184 in test mode per forzare challenge.

Esenzioni SCA: low value e TRA

Esenzioni SCA che riducono friction checkout: 1) Low value (sotto 30 EUR, max 5 consecutive senza challenge); 2) Trusted Beneficiary (cliente ha whitelisted merchant nella sua banca); 3) TRA (Transaction Risk Analysis del PSP - se overall fraud rate del merchant Stripe è basso, Stripe può richiedere esenzione su transazioni low risk); 4) MIT (Merchant Initiated, subscription rinnovi); 5) Corporate cards B2B (alcune esenzioni). Stripe applica esenzioni automaticamente quando criteria match. Senza esenzioni, ogni transazione UE richiederebbe challenge - impatto enorme su conversion.

Test automation SCA scenarios

Test automation per SCA è critico: 1) Test carte ufficiali per ogni scenario - 4000 0027 6000 3184 (3DS2 challenge), 4000 0084 0000 1280 (3DS2 frictionless), 4000 0025 0000 3155 (3DS1 fallback); 2) Selenium/Playwright per simulare flow challenge complete; 3) Integration test contro Stripe Sandbox real con timeout estesi; 4) Stress test che misura impatto SCA su throughput (challenge aggiunge 5-15s al checkout); 5) Test off_session per subscription rinnovi - simula authentication_required scenario. CI/CD pipeline esegue test suite ad ogni deploy. Risultato: confidence che modifiche codebase non rompano SCA flow in produzione.

Procedura passo-passo

1. Verifica di usare Payment Intent (non Charges API legacy).
2. Aggiorna l'integrazione frontend a Payment Element o ad altri Element più recenti.
3. Lascia che Stripe determini automaticamente quando richiedere SCA.
4. Per ricorrenti, salva la carta come off_session con setup_future_usage='off_session'.
5. Configura Radar rules per richiedere SCA su transazioni ad alto rischio (manual).
6. Monitora conversion rate prima/dopo SCA tramite Dashboard Stripe.
7. Educa il cliente: comunica che potrebbe ricevere OTP dalla sua banca.

Errori comuni e come risolverli

• Uso Charges API legacy: non gestisce SCA correttamente; migra a Payment Intent.
• MIT non flaggato: il rinnovo subscription può richiedere SCA non necessario.
• Mancata comunicazione cliente: abbandono carrello per confusione OTP.
• Esenzioni applicate male: richiedere esenzione su transazione ad alto rischio fallisce.

Domande frequenti

D: SCA si applica fuori UE?
R: No, solo per emittenti carta UE/SEE; carte USA non richiedono SCA.

D: Stripe gestisce SCA automaticamente?
R: Sì, con Payment Intent applica le esenzioni o triggera 3DS2 quando serve.

D: Cosa succede se la carta non supporta 3DS2?
R: Stripe fallback a 3DS1 o transazione fallita.

D: L'abbonamento ricorrente richiede SCA ogni volta?
R: No, se setup correttamente come MIT (Merchant Initiated Transaction).

Hai bisogno di aiuto?

Se vuoi integrare Stripe con il team di G Tech Group, scrivici tramite il modulo di contatto.