Ecco il momento in cui molti negozi PrestaShop perdono una vendita in silenzio: un nuovo cliente arriva alla pagina di registrazione, vede un modulo vuoto che chiede email, password e conferma della password, e decide che l'acquisto non era poi così urgente. L'accesso social elimina quella barriera. Invece di inventare l'ennesima password, il cliente tocca "Accedi con Google" (o Facebook, o Apple), autorizza la condivisione e torna nel tuo negozio già autenticato, con nome ed email compilati automaticamente. Questa guida spiega come farlo nel modo corretto su PrestaShop: come funziona lo scambio OAuth, come configurare tutti e tre i provider, che cosa deve davvero gestire il modulo per conto tuo e quali dettagli GDPR non puoi ignorare.
L'attrito che risolve è lo stesso che pesa sulla procedura di pagamento: ogni campo in più è un punto in cui rinunciare. Se la creazione dell'account è il muro all'ingresso del tuo negozio, il modulo di registrazione in più passaggi è un problema collegato che vale la pena leggere insieme a questo tema: da dove arrivano davvero i tuoi clienti ti mostra su quali provider è già presente il tuo pubblico, e quindi quali pulsanti di accesso ha senso mostrare.
Ultimo aggiornamento: giugno 2026.
Perché ridurre l'attrito per gli ospiti è il vero vantaggio

È facile presentare l'accesso social come una "funzione di registrazione". In realtà non lo è: è una funzione anti-attrito. Il valore emerge in due momenti precisi, e nominarli aiuta a mantenere concreta tutta questa guida:
- Primo contatto. Un visitatore nuovo è il cliente più fragile che hai. La creazione obbligatoria dell'account è una delle cause di abbandono più documentate nell'e-commerce, e ogni campo che chiedi prima che abbia comprato qualcosa è un motivo per andarsene. Un pulsante al posto di un modulo trasforma un'operazione da 60-90 secondi in un tocco da due secondi.
- Il ritorno. Le persone dimenticano le password: l'acquirente medio gestisce decine di account e riutilizza credenziali tra servizi diversi. Un cliente di ritorno che non ricorda la password e non ha voglia di passare dall'email di reimpostazione è un cliente che avevi già conquistato e che stai per perdere di nuovo. L'accesso social salta del tutto la deviazione "password dimenticata": il cliente viene riconosciuto dal provider, non da una stringa che deve ricordare.
Nel vantaggio si nasconde anche un beneficio di sicurezza. Quando un cliente accede con Google, la password non passa mai dal tuo negozio: non hai alcuna password da salvare e quindi nulla di quel tipo da perdere in caso di violazione. Tradotto in parole semplici per chi gestisce il negozio: meno credenziali nel database significa meno responsabilità sulle tue spalle.
Come funziona l'accesso social: lo scambio OAuth2 spiegato chiaramente
La maggior parte degli accessi social usa OAuth 2.0 più un token di identità in stile OpenID Connect, a seconda del provider: l'accesso con Google e Apple aggiunge la validazione dell'identità sopra OAuth 2.0. La meccanica conta perché spiega perché alcuni passaggi di configurazione sono inevitabili. Quando un cliente clicca su "Accedi con Google", la sequenza è questa:
- Il tuo negozio reindirizza il cliente alla pagina di accesso di Google: si autentica su Google, mai sul tuo sito.
- Google chiede al cliente di approvare la condivisione con il tuo negozio di un insieme specifico e dichiarato di dati (di solito nome, email, immagine del profilo).
- Google rimanda il cliente a una callback URL del tuo negozio, portando con sé un codice di autorizzazione monouso.
- Il tuo negozio scambia quel codice con un access token tramite una chiamata server-to-server che il cliente non vede mai.
- Con il token, il tuo negozio recupera i dati del profilo approvati e crea un cliente PrestaShop oppure lo collega a uno già esistente.
La conseguenza pratica per chi gestisce il negozio: la password del cliente non viene mai condivisa con te, e tutto lo scambio dipende dalla perfetta corrispondenza tra callback URL e credenziali del provider. Se questi due elementi sono corretti, il resto è compito del modulo. Se sono sbagliati, il pulsante non fa nulla: ecco perché la maggior parte dei ticket "l'accesso social non funziona" risale a un URI di reindirizzamento digitato male.
Configurare l'accesso con Google
Google è il provider più usato e il più semplice da configurare, quindi è il punto giusto da cui iniziare.
Crea un progetto Google Cloud e la schermata di consenso
Nella Google Cloud Console, crea un nuovo progetto e poi configura la schermata di consenso OAuth prima di tutto il resto. Scegli "Esterno" come tipo di utente, inserisci il nome del tuo negozio, un'email di assistenza e il dominio autorizzato. Negli ambiti, richiedi solo email e profile: nulla di più. Chiedere meno non è solo più ordinato; è un atteggiamento corretto rispetto al GDPR e accelera la revisione di Google.
Crea il client OAuth 2.0
In APIs & Services → Credentials, crea un Client ID OAuth 2.0 di tipo "Web application". Aggiungi il dominio del tuo negozio alle origini JavaScript autorizzate e aggiungi la callback URL del modulo agli URI di reindirizzamento autorizzati. La callback segue lo schema del tuo modulo: spesso qualcosa come https://yourstore.com/module/[yoursocialloginmodule]/callback?provider=google. Copia il Client ID e il Client Secret risultanti.
Inserisci le credenziali in PrestaShop
Incolla Client ID e Client Secret nella configurazione del modulo di accesso social, salva e prova il pulsante nella pagina di accesso del tuo negozio. Se il reindirizzamento torna indietro con un errore di mancata corrispondenza, l'URI di reindirizzamento nella console Google non coincide byte per byte con quello emesso dal modulo, incluso http rispetto a https e il percorso finale. È l'errore di configurazione più comune in tutti e tre i provider.
Configurare l'accesso con Facebook
L'accesso con Facebook si crea tramite il portale Meta for Developers e richiede qualche passaggio in più rispetto a Google.
Crea l'app e configura l'accesso
Crea un'app Meta per Facebook Login / autenticazione utente, poi aggiungi il prodotto o caso d'uso Facebook Login (il flusso di creazione app di Meta cambia nel tempo e può mostrare casi d'uso invece di un tipo di app fisso). Nelle impostazioni, aggiungi la callback URL del tuo negozio a "Valid OAuth Redirect URIs" e lascia attivo "Enforce HTTPS". Per impostazione predefinita puoi richiedere le autorizzazioni email e public_profile: bastano per creare l'account. Resisti alla tentazione di chiedere altro (lista amici, post): autorizzazioni eccessive spaventano gli utenti e possono far respingere l'app in revisione.
Revisione dell'app e modalità Live
Finché l'app resta in modalità "Development", il pulsante di accesso funziona solo per le persone elencate come sviluppatori o tester. Per aprirlo ai clienti reali devi passare l'app a "Live" e avere configurato le impostazioni richieste per policy e cancellazione dei dati. Con i soli dati standard di accesso email e public_profile, in genere non serve l'App Review: è riservata ad autorizzazioni avanzate o funzionalità oltre l'accesso standard. Se chiedi qualcosa in più rispetto ai dati standard di accesso, metti in conto i tempi di revisione, così non ti ritrovi con un pulsante che funziona per te e per nessun altro.
La particolarità di Facebook da conoscere prima
Meta ha reso l'accesso ai dati sempre più restrittivo. Il caso che colpisce l'e-commerce è questo: l'autorizzazione email a volte restituisce nessuna email, di solito quando il cliente si è iscritto a Facebook solo con un numero di telefono. Un flusso di accesso che dà per scontato l'arrivo dell'email fallirà in silenzio. Il comportamento corretto, ed è ciò che fa un modulo ben costruito, è rilevare l'email mancante e chiedere al cliente di inserirne una prima di completare l'account. Se usi già Facebook come canale di vendita, vale la pena capire più in generale come la piattaforma tratta i tuoi dati: ne parliamo in vendere su Facebook con PrestaShop e, per la parte di misurazione, in perché il Pixel di Facebook conta ancora.
Configurare l'accesso con Apple
L'accesso con Apple è il più recente dei tre e quello progettato con più attenzione alla privacy, quindi chiede di più al tuo modulo. Si configura tramite il portale Apple Developer e richiede un account Apple Developer a pagamento (99 USD/anno).
Passaggi di configurazione
- Registra un nuovo App ID e abilita "Sign in with Apple" per quell'ID.
- Crea un Services ID: funziona come il tuo OAuth client ID.
- Imposta l'URL di ritorno sulla callback del tuo negozio.
- Genera una private key per l'autenticazione del client. Apple non usa una semplice stringa Client Secret; si aspetta un client secret basato su JWT e firmato con quella chiave, che il modulo prepara per te.
Due comportamenti di Apple che il modulo deve gestire
- Nascondi la mia email. Apple permette al cliente di mascherare il proprio indirizzo reale dietro un indirizzo casuale @privaterelay.apple.com. La posta inviata lì viene inoltrata alla casella reale, ma il tuo negozio vede solo l'indirizzo relay: il modulo deve trattarlo come un'email perfettamente valida, non respingerlo come sospetto.
- Nome condiviso una volta, una sola volta. Apple invia il nome del cliente alla prima autenticazione e poi mai più. Se il modulo non lo acquisisce e salva in quella prima callback, lo perdi definitivamente a meno che il cliente non autorizzi di nuovo. È una fonte classica di dubbi del tipo "perché metà dei miei clienti Apple non ha un nome": la soluzione è prendere subito il nome, al primo scambio.
Che cosa ricevi davvero da ciascun provider
Conoscere in anticipo la forma esatta dei dati ti evita di progettare un flusso di registrazione basato su campi che potrebbero non arrivare mai:
| Provider | Nome | Extra | Il punto critico | |
|---|---|---|---|---|
| Sì | Sì | Immagine del profilo, lingua | Il più affidabile dei tre; richiede meno gestione. | |
| Sì | A volte | Immagine del profilo | L'email può essere vuota: chiedine una come soluzione di riserva. | |
| Apple | Solo al primo accesso | Sì (reale o relay) | — | Acquisisci il nome alla prima autenticazione o lo perdi; accetta le email relay. |
Capire quali di questi valgono lo sforzo di configurazione dipende interamente da dove si trovano già i tuoi clienti. Google e Facebook dominano nella maggior parte dei mercati anglofoni; in Germania, l'adozione dell'accesso con Facebook è più bassa per ragioni di privacy, mentre Google resta forte; l'accesso con Apple tende verso utenti iOS, che spesso hanno valori d'ordine più alti. Non serve pubblicare tutti e tre: abbina i pulsanti al tuo pubblico e rivedi il mix quando cambia il traffico. La domanda più ampia su quali piattaforme si ripaghino davvero è quella che affrontiamo in integrare i flussi Instagram e Facebook nel tuo negozio.
Gestire i clienti che hanno già un account
Questo è il caso limite che separa un modulo di accesso social pulito da uno disordinato. Che cosa dovrebbe succedere quando una persona già registrata nel modo tradizionale, con email e password, clicca su "Accedi con Google" usando la stessa email?
- Corrispondenza per email, poi collegamento: mai duplicazione. Se l'email social corrisponde a un cliente PrestaShop esistente, il modulo dovrebbe agganciare l'identità social a quell'account, non creare un secondo profilo che frammenta lo storico ordini.
- Conferma il collegamento la prima volta. I moduli migliori chiedono al cliente di inserire una volta la password PrestaShop esistente per confermare il collegamento. Quel singolo passaggio blocca un trucco di acquisizione dell'account in cui un aggressore che controlla un account social con la stessa email potrebbe altrimenti infilarsi nello storico ordini di qualcun altro.
- Consenti più provider per lo stesso account. Un cliente potrebbe usare Google dal portatile e Apple dal telefono. Salvare gli ID utente specifici del provider in una tabella di mapping permette a entrambi i percorsi di arrivare allo stesso account PrestaShop.
Raccolta dati e GDPR: la parte che non puoi saltare
L'accesso social porta dati personali da una terza parte dentro il tuo negozio, rendendoti titolare del trattamento per quei dati. Non è un motivo per evitarlo; è un motivo per documentarlo. Gli obblighi sono concreti:
- Consenso. La schermata di consenso OAuth del provider autorizza il trasferimento dei dati dal provider al negozio, ma non esaurisce i tuoi obblighi: il tuo negozio ha comunque bisogno di una base giuridica propria, di un'informativa privacy che spieghi che cosa ricevi tramite accesso social e che cosa ne fai, oltre a qualsiasi gestione del consenso richiesta nel tuo contesto.
- Minimizzazione dei dati. Richiedi solo le autorizzazioni che usi davvero. Importare la lista amici di Facebook quando ti serviva solo un'email non è solo poco elegante: è un problema di conformità.
- Diritto alla cancellazione. Quando un cliente chiede di essere eliminato, revoca il collegamento social e rimuovi i dati collegati insieme all'account.
- Trasparenza sul relay. Se accetti gli indirizzi "Nascondi la mia email" di Apple, le tue email transazionali e di marketing devono continuare a funzionare attraverso il relay: progetta i flussi sapendo che l'indirizzo inoltra, non che si risolve in una casella "reale" che puoi ispezionare.
Dove mettere i pulsanti
Il posizionamento decide in silenzio l'adozione. Alcune regole funzionano in quasi tutti i negozi:
- Sopra il modulo, non sotto. Sia nella pagina di accesso sia in quella di registrazione, i pulsanti social vanno prima: le persone leggono dall'alto verso il basso, e l'opzione con un tocco deve essere la prima cosa che vedono, non un premio di consolazione sotto una parete di campi.
- Offrilo nella procedura di acquisto come ospite. "Accedi con Google per compilare automaticamente i tuoi dati" è una frase davvero convincente proprio nel momento in cui il cliente si prepara a digitare un indirizzo.
- Usa gli stili ufficiali dei pulsanti. Google, Facebook e Apple pubblicano specifiche precise: colori, dimensioni, testi. Un pulsante fatto in casa sembra poco affidabile proprio dove la fiducia conta di più.
- Dimensiona per i pollici. Mantieni un'area di tocco generosa (44×44px e oltre). L'accesso social rende di più sui dispositivi mobili, dove digitare una password è più lento e più soggetto a errori: non lasciare che un pulsante troppo piccolo sprechi il vantaggio.
Dettagli di sicurezza che il modulo dovrebbe gestire correttamente
L'accesso social elimina il rischio legato alla conservazione delle password, ma ne aggiunge alcuni propri. Non devi implementarli tu, ma dovresti sapere che vengono gestiti:
- Il parametro state. Ogni flusso OAuth dovrebbe generare un valore casuale state, salvarlo in sessione e verificarlo nella callback: è ciò che blocca gli attacchi CSRF sullo scambio di accesso.
- HTTPS, sempre. Per i negozi in produzione, usa callback URL in HTTPS: i provider le richiedono per i negozi online attivi. Possono esistere eccezioni localhost o di test per lo sviluppo, ma non farci affidamento per un negozio in produzione: se il tuo negozio non è interamente su HTTPS, l'accesso social non funzionerà.
- I token restano fuori vista. Gli access token devono stare in un'archiviazione server-side sicura: mai negli URL, nei log o nel JavaScript lato client.
Misurare se ha davvero aiutato
Non dare per scontato il beneficio e non giudicarlo su tre giorni di dati. Prima di attivarlo, registra il tasso di registrazione e il tasso di abbandono del carrello dei nuovi clienti. Dopo, osserva gli stessi due numeri su una finestra significativa, con abbastanza ordini da leggere una tendenza e non rumore, e aggiungine altri due:
- Ripartizione per provider. Quali pulsanti premono davvero i clienti? Questo ti dice se il terzo provider che hai configurato sta ripagando lo sforzo.
- Tasso di collegamento degli account. Quanti clienti esistenti collegano un account social? Un tasso alto è un segnale pulito che i clienti apprezzano la comodità e che la funzione sta facendo la sua parte.
Domande frequenti
Perché il mio pulsante di accesso social torna indietro con un errore "redirect URI mismatch"?
L'URI di reindirizzamento registrato presso il provider non coincide byte per byte con quello emesso dal modulo. Controlla http rispetto a https, un percorso finale mancante o in più, e www rispetto al dominio nudo: tutti e tre contano come URI diversi. Questa singola mancata corrispondenza è la causa più comune di "l'accesso social non funziona" su tutti e tre i provider.
Devo configurare tutti e tre i provider?
No: abbina i pulsanti ai luoghi in cui si trovano già i tuoi clienti. Google e Facebook dominano la maggior parte dei mercati anglofoni; in Germania l'adozione di Facebook è più bassa per ragioni di privacy, mentre Google resta forte; Apple tende verso utenti iOS, spesso con valori d'ordine più alti. Pubblica uno o due provider usati dal tuo pubblico e aggiungi il terzo solo se i dati dicono che si ripaga.
Un cliente Facebook ha effettuato l'accesso ma non ho ricevuto l'indirizzo email. È un bug?
No, è un comportamento previsto. Facebook a volte non restituisce alcuna email, di solito quando il cliente si è iscritto solo con un numero di telefono. Un flusso di accesso che dà per scontato l'arrivo dell'email fallisce in silenzio. Il modulo dovrebbe rilevare l'indirizzo mancante e chiedere al cliente di inserirne uno prima di completare l'account.
Metà dei miei clienti Apple non ha un nome. Che cosa è successo?
Apple invia il nome del cliente solo alla prima autenticazione e poi mai più. Se il modulo non lo acquisisce e salva in quella prima callback, viene perso a meno che il cliente non autorizzi di nuovo. Assicurati che il modulo prenda il nome al primo scambio e accetti come validi gli indirizzi "Nascondi la mia email" @privaterelay.apple.com di Apple.
Che cosa succede se qualcuno usa Google con la stessa email del suo account esistente con password?
Un modulo ben costruito trova la corrispondenza sull'email e collega l'identità social all'account esistente, invece di creare un duplicato che divide lo storico ordini. I migliori chiedono una volta la password esistente per confermare il collegamento: quel passaggio blocca un trucco di acquisizione dell'account in cui qualcuno che controlla un account social con email corrispondente potrebbe altrimenti entrare nell'account di un altro cliente. Collegarsi in modo pulito al record cliente esistente è il tipo di dettaglio che i nostri moduli per procedura di pagamento e gestione clienti sono progettati per gestire correttamente.
Qui conta essere onesti: l'accesso social è una capacità, non una garanzia. Riduce l'attrito all'ingresso e nelle visite successive; che questo diventi più ordini dipende dal resto del tuo percorso di conversione. Ma tra le modifiche che puoi fare a un negozio PrestaShop, poche costano così poco da aggiungere e sono così facili da misurare. In mypresta.rocks costruiamo moduli che riducono l'attrito nell'esperienza cliente PrestaShop, e l'accesso social si affianca naturalmente a strumenti per una procedura di acquisto ottimizzata e per la gestione clienti come un altro punto in cui smettere di chiedere ai clienti cose che preferirebbero non fornire.
Commenti
Ancora nessun commento. Sii il primo!
Sii il primo a fare una domanda o a condividere un feedback utile.
Lascia un commento
Condividi una domanda, un dettaglio di installazione o un feedback utile per un altro lettore.