Stripe Checkout vs Elements vs Payment Element
Stripe offre tre approcci principali per integrare i pagamenti: Checkout, Elements e Payment Element. La scelta giusta dipende dal grado di personalizzazione, dalla complessità del flusso e dalle risorse di sviluppo disponibili.
Stripe Checkout: la soluzione hosted
Checkout è una pagina di pagamento ospitata da Stripe e completamente gestita: bastano poche righe di codice per creare una sessione tramite l'API e reindirizzare l'utente. È la soluzione più rapida, già PSD2-compliant, con supporto automatico per Apple Pay, Google Pay, Link e oltre 30 metodi locali. Ideale per chi vuole partire in giornata senza preoccuparsi di compliance PCI-DSS.
Stripe Elements: massima personalizzazione
Elements è una libreria di componenti UI (CardElement, IbanElement, ecc.) che permette di costruire form di pagamento totalmente integrati nel proprio sito. Richiede più codice ma offre controllo totale su stile, validazione e UX. Il PCI scope rimane minimo perché i dati sensibili non transitano dal tuo server.
Payment Element: il meglio dei due mondi
Payment Element è l'evoluzione di Elements: un singolo componente che mostra automaticamente i metodi di pagamento più rilevanti per ogni cliente in base a paese, valuta e cronologia. Riduce drasticamente il codice rispetto a Elements classico ma mantiene la possibilità di personalizzare layout e stile.
Quando scegliere Checkout
Stripe Checkout brilla nei contesti dove rapidita' e affidabilità' sono prioritarie. E' la scelta giusta per MVP, landing page di prodotto singolo, donazioni one-off, eventi a biglietto fisso. Non richiede competenze frontend particolari e include automaticamente best-practice come responsive design, autofill mobile, supporto wallet (Apple/Google Pay/Link). Il branding è personalizzabile a livello base (logo, primary color). Il limite è che non puoi inserire il flusso checkout dentro la tua applicazione: il cliente esce dal tuo dominio e torna dopo il pagamento.
Migration path tra le tre opzioni
Spesso si inizia con Checkout per validare il modello di business e si migra a Payment Element quando il volume cresce e serve esperienza on-domain. La migrazione richiede: backend nuovo endpoint PaymentIntent, frontend reimplementazione form, gestione SCA esplicita lato client. Il vantaggio dopo migrazione è un controllo totale su UX, A/B testing checkout, e analytics granulari. Elements puro (legacy CardElement) non è più' raccomandato per nuove integrazioni: usa direttamente Payment Element che è superset funzionale.
Compatibilità' framework e librerie
Stripe.js (frontend) è framework-agnostic ma esistono wrapper ufficiali: @stripe/react-stripe-js per React (hook useStripe, useElements), @stripe/stripe-js per vanilla JS, plugin Vue.js community, integration Angular. Per server-side gli SDK ufficiali coprono PHP, Node, Python, Ruby, Go, Java, .NET. Tutti gli SDK seguono la stessa sintassi base con piccoli adattamenti idiomatici (es. snake_case Python, camelCase Node). La documentazione interattiva (docs.stripe.com) mostra esempi per ogni linguaggio simultaneamente con tab selector.
Performance e bundle size frontend
Stripe.js v3 (libreria principale) è circa 30KB gzipped, caricata da js.stripe.com (CDN globale). Per ottimizzare LCP/INP: 1) Carica Stripe.js solo nella pagina checkout, non globalmente; 2) Usa loadStripe (await import) con dynamic import; 3) Defer init di Elements fino al click 'Procedi al pagamento'. Payment Element aggiunge altri 20-30KB. Su mobile 3G il caricamento aggiunge 1-2s al checkout: pre-fetch su pagina precedente con mitiga drasticamente.
Migration da Charges API legacy
Per chi ha integrazioni Stripe pre-2019 basate su Charges API, la migrazione a Payment Intent è obbligatoria per supportare SCA e nuovi metodi di pagamento. Step della migrazione: 1) Audit del codice esistente per identificare tutte le chiamate Stripe::Charge::create; 2) Refactor verso PaymentIntent (server-side); 3) Update frontend da Stripe.createToken a Stripe.confirmCardPayment; 4) Test esteso in Sandbox con scenari 3DS challenge; 5) Deploy progressivo con feature flag per rollback rapido. Stripe espone tool 'API Logs' che mostra quante chiamate legacy fai ancora, utile per pianificazione. Dopo migration, sblocchi anche Apple Pay/Google Pay che con Charges non funzionavano.
Procedura passo-passo
- Valuta il livello di personalizzazione richiesto: marchio forte e UX cucita = Elements; rapidità = Checkout; equilibrio = Payment Element.
- Crea una chiave API restricted nella Dashboard per l'integrazione lato server.
- Installa l'SDK Stripe per il linguaggio scelto (stripe-php, stripe-node, ecc.).
- Implementa l'endpoint di creazione PaymentIntent o Checkout Session lato server.
- Aggiungi Stripe.js (Checkout/Elements) o il componente Payment Element nel frontend.
- Configura il webhook payment_intent.succeeded per gestire l'evento di pagamento confermato.
- Testa in modalità Sandbox con le carte di prova (4242 4242 4242 4242) prima del passaggio in Live.
Errori comuni e come risolverli
- Mescolare integrazione legacy Charges API con Payment Intent: porta a SCA non funzionante; usa solo Payment Intent.
- Dimenticare l'evento webhook: il backend non riceve la conferma e l'ordine resta in stato pending.
- Hardcoded amount lato client: il client può manomettere il prezzo; calcola sempre l'importo lato server.
- Chiavi pubbliche e segrete invertite: errore comune che produce 401 Unauthorized; pk_ va nel frontend, sk_ nel backend.
Domande frequenti
D: Posso passare da Checkout a Elements in futuro?
R: Sì, ma richiede riscrivere l'integrazione frontend; valuta bene all'inizio.
D: Payment Element supporta SCA?
R: Sì, gestisce automaticamente 3D Secure 2 e tutti i flussi di autenticazione richiesti.
D: Quale ha le commissioni più basse?
R: Le commissioni Stripe sono identiche per tutte e tre le integrazioni.
D: Posso usare entrambi nello stesso sito?
R: Sì, Checkout per ordini singoli e Payment Element per ricorrenti, ad esempio.
Hai bisogno di aiuto?
Se vuoi integrare Stripe con il team di G Tech Group, scrivici tramite il modulo di contatto.