Pagamenti su Adobe Commerce: metodi, SCA e conversione

Ogni volta che apro il pannello dei metodi di pagamento di un nuovo progetto, so già che passerò lì dentro più tempo di quanto il cliente immagini. Sulla carta è una configurazione: attivi un gateway, spunti un wallet, salvi. Nella realtà è il punto in cui sicurezza, conversione e frizione si scontrano ogni giorno, ordine dopo ordine. E dal 2011, da quando lavoro su Magento e poi su Adobe Commerce, è anche il punto dove ho visto sparire più fatturato per errori che nessuno andava a cercare nel posto giusto.

Voglio raccontare come imposto i pagamenti su Adobe Commerce, cosa è cambiato con la PSD2 e la SCA (Strong Customer Authentication), e gli errori che vedo più spesso nel checkout. Niente teoria: quello che succede sul campo.

Come imposto i payment method su Adobe Commerce

Adobe Commerce arriva con una batteria di metodi nativi (PayPal, Braintree, i classici offline come bonifico e contrassegno) più tutto ciò che aggiungi via extension. Il primo lavoro non è tecnico, è di merito: quali metodi servono davvero a quel pubblico, e in che ordine mostrarli.

Il mio schema di base per un merchant EU mid-market è più o meno questo:

• Carte tramite un gateway serio (Braintree, Adyen, Stripe a seconda dell’acquiring): è la spina dorsale, deve funzionare in modo impeccabile.
• Wallet: Apple Pay e Google Pay. Sottovalutati in Italia, ma su mobile spostano il conversion rate in modo tangibile perché tolgono la digitazione della carta e portano dentro un’autenticazione biometrica.
• PayPal: piaccia o no, per una fetta di clienti è il metodo di fiducia. Toglierlo per “pulizia” del checkout è quasi sempre un autogol.
• BNPL (Buy Now, Pay Later): Klarna, Scalapay e simili. Su carrelli fashion e arredo alzano l’average order value, ma vanno messi con criterio, non ovunque.

Sul gateway ho una posizione netta: meglio uno o due gateway configurati bene che sei mezzi attivati. Ogni metodo in più è codice, è manutenzione, ed è una riga in più nel checkout che il cliente deve scansionare prima di decidere. La scelta non è “quanti ne offro” ma “quali coprono il 95% dei casi reali senza aggiungere rumore”.

PSD2 e SCA: cosa è cambiato davvero

La PSD2 ha reso obbligatoria l’autenticazione forte per la maggior parte dei pagamenti online con carta in area SEE. In pratica: per molte transazioni la banca dell’acquirente pretende un secondo fattore, e lo strumento con cui questo avviene sul web è il 3-D Secure, oggi nella versione 2 (EMV 3DS).

La differenza rispetto al vecchio 3DS non è cosmetica. Il 3DS2 scambia decine di data point tra merchant e banca (device, cronologia, importo, comportamento) e su questa base la banca decide se applicare un challenge esplicito — l’OTP, l’app che chiede conferma — oppure se lasciar passare la transazione in modo frictionless. Ed è qui che si gioca tutto.

Perché la SCA prevede delle esenzioni, e chi le conosce le usa:

• Low value: transazioni di importo contenuto (indicativamente sotto i 30 euro, con limiti cumulativi).
• TRA (Transaction Risk Analysis): se l’acquirer ha frodi sotto certe soglie, può chiedere l’esenzione per importi crescenti.
• Trusted beneficiary: il cliente inserisce il merchant tra quelli fidati e salta il challenge sugli acquisti successivi.
• MIT (Merchant Initiated Transactions): rinnovi e pagamenti ricorrenti, fuori dal perimetro SCA se impostati correttamente.

La mia posizione è semplice: la SCA non è solo un obbligo di compliance, è una leva di conversione da governare. Il merchant che tratta il 3DS2 come un interruttore acceso/spento lascia sul tavolo tutte le transazioni che potevano passare frictionless e non sono passate.

Il problema vero: i falsi decline

Se devo indicare la voce che costa di più e che quasi nessuno misura, sono i falsi decline: transazioni legittime rifiutate. Il cliente c’è, la carta è buona, i soldi ci sono — e l’ordine non passa. Non compare in nessun report di frode, perché formalmente non è frode; sparisce e basta.

Con l’introduzione della SCA il rischio è aumentato, perché ogni challenge in più è un punto di rottura in più: OTP che non arriva, app della banca che va in timeout, redirect su mobile che si perde. Su un checkout ho visto un tasso di abbandono sulla pagina 3DS che, da solo, valeva più di qualsiasi ottimizzazione grafica del carrello di cui il cliente voleva parlare.

Un caso concreto, reso anonimo: merchant fashion, ordini prevalentemente da mobile. Il conversion rate crollava proprio nell’ultimo step. La grafica era a posto, il gateway “funzionava”. Il problema era che ogni singola transazione andava a challenge, senza mai sfruttare le esenzioni: l’acquirer non riceveva i dati necessari per l’esenzione TRA e non era stato attivato il flusso frictionless. Sistemata l’integrazione con l’acquirer e passati i data point corretti nel 3DS2, una quota importante di transazioni ha smesso di chiedere l’OTP. Nessuna magia: solo aver capito dove si perdevano gli ordini.

Bilanciare sicurezza e frizione

Ogni challenge riduce la frode ma aumenta l’abbandono. Ogni esenzione riduce l’abbandono ma sposta sul merchant una parte del rischio (con l’esenzione TRA lato merchant/acquirer, il liability shift non è garantito come nel challenge pieno). Non esiste la configurazione perfetta: esiste quella giusta per quel catalogo, quel ticket medio, quel profilo di frode.

Come ragiono, in pratica:

• Carrelli bassi e clienti ricorrenti: spingo sulle esenzioni, frictionless dove possibile.
• Ticket alto o segnali di rischio: challenge pieno, mi tengo il liability shift.
• Sempre: misuro il tasso di autenticazione e il tasso di successo dopo il 3DS, non solo prima. È l’unico modo per sapere se sto perdendo ordini nell’ultimo metro.

Gli errori che vedo più spesso

• 3DS2 come interruttore: attivato “per compliance”, mai configurato per sfruttare le esenzioni. Si paga tutto in frizione.
• Non passare i data point all’acquirer: senza i dati giusti, il flusso frictionless non parte e ogni transazione va a challenge.
• Troppi metodi: un checkout con otto opzioni non è ricco, è confuso. La paralisi da scelta esiste anche qui.
• Ignorare il mobile: redirect e OTP che si rompono su smartphone, dove ormai passa la maggioranza del traffico.
• Non monitorare i decline: senza un report che separi frode reale, insufficienza fondi e abbandono 3DS, si ottimizza al buio.
• Wallet spenti: Apple Pay e Google Pay non attivati per pigrizia, buttando via la conversione più facile che ci sia su mobile.

In sintesi

I pagamenti su Adobe Commerce non sono una configurazione da chiudere in mezza giornata: sono un sistema vivo dove ogni scelta ha un costo in sicurezza o in conversione. La SCA ha alzato l’asticella, ma ha anche dato strumenti — le esenzioni, il frictionless — a chi si prende la briga di capirli. Il merchant che tratta il checkout come un dettaglio tecnico perde ordini che non vedrà mai nei report. Quello che lo tratta come parte del prodotto, li recupera uno per uno.

Domande frequenti

La SCA è obbligatoria per tutti i pagamenti online?
Per la maggior parte dei pagamenti con carta verso clienti in area SEE sì, con eccezioni previste dalla normativa (importi bassi, transazioni a basso rischio, pagamenti ricorrenti impostati come MIT).

Cos’è un falso decline?
È una transazione legittima rifiutata: cliente reale, carta valida, fondi disponibili, ma l’ordine non va a buon fine. Con la SCA il rischio aumenta perché ogni challenge aggiuntivo è un punto di abbandono in più.

Il 3-D Secure 2 aiuta o danneggia la conversione?
Dipende da come è configurato. Usato solo come obbligo, aggiunge frizione. Sfruttando le esenzioni e il flusso frictionless, permette a molte transazioni di passare senza OTP e protegge la conversione.

Quanti metodi di pagamento conviene offrire?
I pochi che coprono davvero il pubblico: carte con un gateway solido, i wallet (Apple Pay, Google Pay), PayPal e, dove ha senso, il BNPL. Aggiungere metodi oltre questo perimetro tende a confondere il checkout più che ad aiutarlo.

Fabio Canovi è specialista di Magento e Adobe Commerce, tra i primi in Italia a ottenere la certificazione Adobe Commerce. Progetta e ottimizza piattaforme e-commerce per merchant mid-market, con un occhio particolare a checkout, pagamenti e conversione.