Scegliere l’architettura di pagamento più adatta ti aiuta a evitare debiti tecnici man mano che i mercati e i metodi di pagamento si evolvono. In questo articolo trovi il confronto tra Payment Services e gateway di terze parti, metodi di pagamento B2C/B2B, ambito PCI, protezione dalle frodi e l’impatto dei protocolli di pagamento agentico annunciati nel 2026.

La strategia di pagamento è una delle decisioni tecniche più importanti in qualsiasi progetto Adobe Commerce, ma spesso viene definita in modo troppo limitato.

Il pagamento rappresenta il momento di massimo rischio commerciale nel percorso di acquisto. Un checkout fluido porta alla conversione, mentre uno confuso o lento genera abbandono. Se il checkout fallisce in modo silenzioso a causa di un timeout del gateway, di un problema di autenticazione 3DS (3-D Secure) o di una configurazione errata del metodo di pagamento, si perde sia la vendita sia il cliente. L’architettura dei pagamenti in Adobe Commerce richiede più scelte di quanto la maggior parte dei team di implementazione si aspetti: quale gateway o quali gateway adottare, dove mostrare ogni metodo di pagamento sulla vetrina, come gestire l’ambito di conformità PCI (Payment Card Industry), come affrontare le frodi e come strutturare il workflow di pagamento B2B quando sono inclusi ordini di acquisto e credito aziendale.

Questo articolo offre un quadro decisionale e indicazioni operative per ciascuna di queste domande, con particolare attenzione a Payment Services (la soluzione di pagamento nativa di Adobe, supportata su ACCS), alle considerazioni architetturali per le implementazioni multi-gateway, ai protocolli di pagamento agentici che Adobe ha deciso di supportare da febbraio 2026 e alle differenze nell’architettura dei pagamenti tra la vetrina EDS (Edge Delivery Services) e una vetrina tradizionale basata su tema.

Adobe Payment Services vs gateway di terze parti: quadro decisionale

La prima domanda strategica in qualsiasi architettura di pagamento Commerce riguarda se utilizzare Payment Services per Adobe Commerce, la soluzione di pagamento nativa e gestita di Adobe, oppure un gateway di terze parti come Adyen o Stripe. La risposta non è sempre esclusiva. Molte implementazioni enterprise adottano entrambi i modelli in modo complementare.

Payment Services: Perché scegliere la soluzione nativa di Adobe

Payment Services è la soluzione di pagamento nativa e gestita di Adobe, confermata dalla documentazione ufficiale Adobe come opzione predefinita per i pagamenti su Adobe Commerce come Cloud Service (ACCS). Si tratta di una soluzione SaaS che non richiede integrazione personalizzata di gateway e viene configurata direttamente da Commerce Admin, gestita tramite la stessa interfaccia dello storefront.

Copertura geografica: secondo i dati attualmente pubblicati da Adobe, Payment Services supporta oltre 35 paesi e più di 20 valute (Adobe la definisce una lista in continua espansione), coprendo i principali mercati in Nord America, Europa e Asia-Pacifico. La copertura si suddivide in due livelli: onboarding Avanzato (con tutte le opzioni di pagamento disponibili) e onboarding Standard, che offre un set ridotto di opzioni (Express Checkout, ovvero carte di credito e debito PayPal) in ulteriori paesi supportati oltre il livello Avanzato. I metodi di pagamento includono carte di credito e debito, PayPal, Venmo, PayPal Pay Later, PayPal Credit, Apple Pay, Google Pay e vaulting delle carte per acquisti ricorrenti; Buy Now Pay Later è disponibile tramite PayPal Pay Later, non come categoria BNPL nativa generica che copre diversi provider. I merchant possono collegare più account PayPal per regione e brand, un miglioramento significativo che consente la gestione multi-brand e multi-regione su un’unica istanza di Commerce.

Gateway di terze parti: quando scegliere Adyen o Stripe

Per gli esercenti che necessitano di una copertura superiore a quella di Payment Services, o che richiedono metodi di pagamento locali specifici (iDEAL, SEPA, Alipay, GrabPay, PIX, Interac) non disponibili tramite Payment Services, la scelta migliore è un gateway di terze parti. Adyen possiede licenze di acquiring dirette in oltre 40 paesi e consente di elaborare pagamenti in più di 200 mercati a livello globale tramite un'unica integrazione, diventando così una soluzione frequente per grandi esercenti enterprise con operazioni complesse su più regioni; il numero di licenze di acquiring e l’ampiezza della copertura di elaborazione sono due dati distinti, da tenere separati quando si cita la copertura di Adyen.

I gateway di terze parti possono integrare con Adobe Commerce seguendo diversi percorsi a seconda dell’architettura: App Builder, moduli nativi ed estensioni, SDK di pagamento ospitati oppure integrazioni API dirette. Per le implementazioni SaaS/ACCS, la Documentazione di riferimento di Adobe indica App Builder insieme ad API Mesh come layer standard di estendibilità, con il pattern Integration Starter Kit Server-Side Gateway Integration (un’AIO Runtime Action che gestisce la comunicazione con il gateway, chiamata dallo storefront tramite GraphQL) come approccio documentato per integrare gateway di pagamento di terze parti. API Mesh stessa è confermata nella Documentazione dell’architettura ACCS di Adobe come supergraph API-first su cui si basa Commerce SaaS, quindi il suo ruolo di layer unificato per integrazione e instradamento in contesti multi-gateway e multi-valuta fa parte integrante dell’architettura documentata, non è solo una delle tante opzioni componibili. La specifica affermazione che "instrada il contesto di pagamento per ambito store" rappresenta un modello di implementazione plausibile in questa architettura, ma non costituisce una funzionalità ufficiale Adobe di instradamento dei pagamenti.

Ambito PCI DSS: cosa significa la tua scelta di pagamento per la conformità

Uno degli aspetti più sottovalutati nelle decisioni sui gateway di pagamento è l’ambito PCI DSS, ovvero quanto lavoro di conformità genera la tua architettura di pagamento. Il Payment Card Industry Data Security Standard regola come gli esercenti gestiscono, elaborano e conservano i dati dei titolari di carta. L’ambito del tuo obbligo PCI dipende direttamente da come i dati della carta transitano nei tuoi sistemi.

Con i campi ospitati di Payment Services, i dati della carta (numero, CVV, scadenza) non passano mai dai tuoi server. I campi vengono visualizzati da Payment Services e tokenizzati prima che la richiesta di pagamento raggiunga Commerce. Secondo la documentazione ufficiale di sicurezza di Adobe, nessun dato regolato da PCI viene trasmesso attraverso i tuoi servizi con i pulsanti di pagamento PayPal. I campi ospitati possono aiutare gli esercenti a qualificarsi per il Self-Assessment Questionnaire (SAQ) A o SAQ A-EP, percorsi di conformità più semplici e meno onerosi, a seconda dei dettagli di implementazione, degli script e del controllo della pagina. La classificazione finale dell’ambito PCI, compresa l’idoneità a SAQ (Self-Assessment Questionnaire) A, viene stabilita da un Qualified Security Assessor sulla base dell’architettura completa dell’esercente e non è automaticamente garantita dall’utilizzo dei campi ospitati.

Se i dati della carta passano dai tuoi server prima di raggiungere il gateway, senza campi ospitati, potresti rientrare nell’ambito SAQ D: il livello di conformità PCI più rigoroso, che richiede test di penetrazione annuali, scansioni di rete trimestrali e una documentazione approfondita. La gestione diretta dei dati dei titolari di carta aumenta notevolmente l’ambito PCI e può richiedere SAQ D, ma come per SAQ A sopra, il livello SAQ applicabile deve essere confermato da un Qualified Security Assessor e non semplicemente dedotto dall’architettura. La differenza in termini di carico di lavoro tra SAQ A e SAQ D si traduce in mesi di attività e migliaia di euro all’anno.

Costruire il giusto mix di metodi di pagamento

La strategia sui metodi di pagamento non consiste solo nell’offrire più opzioni, ma nel proporre quelle giuste nei momenti chiave della customer journey, per il segmento di clienti corretto e nel mercato appropriato. Tre dimensioni guidano la scelta del mix di metodi di pagamento: segmento di clienti (B2C vs B2B), area geografica e contesto d’acquisto.

B2C: carte, wallet e pagamento rateale

Il baseline dei metodi di pagamento B2C comprende tre categorie che dovrebbero essere sempre attive in ogni implementazione di commercio digitale:

• Carte e wallet digitali: Visa, Mastercard, Amex, Apple Pay e Google Pay sono il punto di partenza irrinunciabile. La quota dei wallet digitali nei pagamenti cresce in ogni mercato; Apple Pay riduce la frizione del pagamento su mobile a un solo tocco. Configura Apple Pay su pagina di prodotto, mini-carrello e pagamento per ottenere la massima copertura di conversione.

• Archiviazione carte per acquirenti abituali: Payment Services supporta l’archiviazione delle carte, cioè i metodi di pagamento salvati che permettono ai clienti di completare gli acquisti senza reinserire i dati della carta. Questo migliora direttamente il tasso di conversione sugli acquisti ripetuti. Gli esercenti possono anche creare ordini in Admin utilizzando la carta archiviata del cliente per ordini telefonici o assistiti.

• Buy Now Pay Later: Le opzioni BNPL possono essere inserite su pagina di prodotto, mini-carrello, carrello e pagamento, non solo nell’ultima fase del pagamento. Mostrare il messaggio BNPL sulla pagina di prodotto (ad esempio, "A partire da $X/mese con Pay Later") aumenta la conversione su prodotti di alto valore e il valore degli ordini (AOV). L’esercente riceve il pagamento immediatamente; il provider BNPL gestisce il rapporto di rateizzazione con il cliente.

B2B: Pagamento su conto, ordini di acquisto e preventivi negoziabili

I flussi di pagamento B2B in Adobe Commerce sono sostanzialmente diversi da quelli B2C. Il changelog del drop-in di pagamento di Adobe conferma un importante aggiornamento di versione (Checkout v3.0.0), rilasciato l’8 gennaio 2026, che introduce il supporto completo al pagamento B2B e aggiunge esattamente i tre metodi di pagamento descritti di seguito. Lo stesso aggiornamento disattiva Fastlane per il pagamento B2B, evitando conflitti con i flussi di pagamento B2B.

• Pagamento su conto: consente ai clienti B2B di pagare utilizzando il saldo credito aziendale. Il drop-in di pagamento utilizza l’API getCompanyCredit per recuperare in tempo reale il credito disponibile e il limite di credito, con convalida per impedire ordini che superano il limite di credito.

• Ordini di acquisto: permette ai clienti B2B di inserire un numero di ordine di acquisto durante il pagamento, con convalida per assicurare che siano compilati i campi PO richiesti. Questo è il metodo di pagamento standard nei flussi di approvvigionamento in cui il regolamento finanziario avviene esternamente al sistema Commerce tramite i processi finanziari e AP.

• Pagamento con preventivo negoziabile: il pagamento distingue tra carrelli normali e preventivi negoziabili, gestendo eventi e contenitori separati per ciascun flusso. In questo modo è possibile acquistare sulla base di un preventivo negoziato prima del pagamento, una funzionalità fondamentale per il B2B.

Globali e regionali: metodi di pagamento locali

Per gli esercenti che operano in più regioni, i metodi di pagamento locali (APM) sono fondamentali per la conversione e non rappresentano un’opzione. Nei Paesi Bassi, iDEAL copre oltre il 60 % dei pagamenti online. In Brasile, PIX è il metodo digitale più utilizzato. In Germania e Austria, ci si aspetta SEPA Direct Debit. Una vetrina che propone solo carte internazionali in questi mercati avrà risultati inferiori rispetto ai concorrenti locali che offrono il metodo preferito dalla clientela.

Gateway di terze parti (Adyen per grandi aziende, Stripe per il mid-market) garantiscono la copertura dei metodi di pagamento locali necessaria per un vero commercio globale. Il routing in base al contesto del negozio, utilizzando API Mesh come layer di integrazione documentato per le implementazioni SaaS/ACCS, aiuta a mostrare il gateway e i metodi locali corretti per ogni vetrina regionale. Ogni connessione gateway viene configurata per ambito sito web in Commerce Admin.

Architettura dei pagamenti sulla vetrina EDS

La vetrina Commerce basata su EDS modifica il modo in cui vengono implementati e visualizzati i metodi di pagamento. Comprendere il modello dei touchpoint di pagamento e l’architettura drop-in del pagamento è fondamentale per una corretta configurazione dei pagamenti EDS.

Touchpoint di pagamento: dove compaiono i metodi sullo storefront

Payment Services supporta quattro touchpoint di pagamento nello storefront e la configurazione ottimale varia in base al metodo:

• Pagina di prodotto (PDP): pulsante PayPal express e messaggi BNPL. Non consigliato per tutte le implementazioni: aggiungere pulsanti di pagamento alla pagina di prodotto consente di saltare il carrello, il che potrebbe entrare in conflitto con promozioni, confezioni regalo o regole basate sulla quantità. Effettua test approfonditi prima di attivare questa opzione.

• Mini-carrello: pulsanti PayPal express e Apple Pay wallet. Consentono agli acquirenti di saltare il checkout completo dal cassetto del carrello, riducendo al massimo gli ostacoli per acquisti d’impulso e ripetuti.

• Pagina carrello: tutti i pulsanti dei metodi di pagamento, oltre a messaggi BNPL e idoneità Pay Later. La pagina carrello è il punto principale consigliato per mostrare tutte le opzioni di pagamento prima dell’inizio del checkout.

• Pagina di checkout: campi di pagamento ospitati per l’inserimento della carta (conformi alla Content Security Policy (CSP), nessun dato della carta sul server), oltre a tutti i metodi wallet. Questa è la pagina cruciale per la conversione: riduci al minimo gli ostacoli e verifica che tutti i metodi di pagamento configurati vengano visualizzati correttamente senza errori JavaScript.

Autorizza e incassa: configura la giusta azione per il tuo modello di evasione

Payment Services offre due modalità di azione di pagamento: solo autorizzazione (incasso separato al momento dell’evasione) e autorizzazione e incasso (incasso immediato sull’ordine). La configurazione corretta dipende dal modello di evasione che hai adottato:

• Solo autorizzazione (consigliato per beni fisici): autorizza sull’ordine, incassa alla spedizione. In questo modo eviti di addebitare il cliente prima della spedizione effettiva e riduci il rischio di chargeback sugli ordini annullati prima dell’evasione. Configura l’incasso come parte del workflow di spedizione.

• Autorizzazione e incasso (consigliato per beni digitali): l’incasso immediato sull’ordine è indicato quando la consegna è istantanea (download software, licenze digitali, abbonamenti SaaS). Solo autorizzazione non è utile quando l’evasione è immediata.

Protezione antifrode: il livello dell’architettura dei pagamenti spesso trascurato dai team

Nell’architettura dei pagamenti, la protezione antifrode viene spesso considerata solo dopo, quando arrivano i primi chargeback, invece che prima del lancio. Gestire le frodi in modo reattivo comporta costi molto più elevati rispetto alla prevenzione proattiva: i chargeback generano commissioni, un tasso elevato di chargeback attiva sanzioni da parte del gateway e i team di revisione manuale sono costosi.

Payment Services include il rilevamento antifrode basato su machine learning integrato di PayPal per i flussi di pagamento PayPal. Per le transazioni con carta e Apple Pay, la protezione antifrode di Signifyd si integra con Payment Services e offre copertura dei rischi per carte di credito, carte di debito, carte salvate, checkout tramite Admin e Apple Pay. Signifyd supporta sia i flussi pre-auth che post-auth.

Per i gateway di terze parti, la protezione antifrode è integrata nel livello del gateway: RevenueProtect di Adyen utilizza il punteggio di rischio basato su ML con soglie configurabili per metodo di pagamento e regione. Stripe Radar offre regole basate su AI e un builder visuale delle regole. Entrambe le soluzioni si integrano con il workflow di gestione delle dispute del gateway, riducendo la gestione manuale dei chargeback.

Prepararsi al futuro: il livello agentico dei pagamenti

Gli impegni agentici di Adobe nel commercio si sono sviluppati in due fasi: prima un impegno verso il protocollo Agent Payments Protocol (AP2) di Google, seguito da un annuncio dedicato a febbraio 2026 in cui Adobe Commerce ha confermato il supporto al Universal Commerce Protocol (UCP, guidato da Google e coprente l’intero percorso dall’esplorazione al post-acquisto) e all’Agentic Commerce Protocol (ACP, co-sviluppato da OpenAI e Stripe, che gestisce l’esecuzione del pagamento direttamente in chat). AP2 è passato sotto la governance della FIDO Alliance e ha attirato oltre 60 partner iniziali, tra cui Mastercard, PayPal, Adyen e Coinbase. Questi standard erano ancora in fase di maturazione al momento dell’annuncio, e un dato significativo sull’adozione: OpenAI ha chiuso la principale interfaccia consumer di ACP, Instant Checkout, a marzo 2026 dopo circa cinque mesi di vendite limitate, anche se il protocollo ACP continua.

Dal punto di vista pratico, l’architettura dei pagamenti cambia: gli acquirenti agentici non interagiscono con i pulsanti di pagamento. Eseguono in modo programmato le operazioni di carrello, pagamento e transazione tramite il server Commerce MCP (Commerce Model Context Protocol) e il layer di token di pagamento AP2. AP2 offre token di pagamento agentici con limiti di spesa e approvazione delle transazioni basata sul consenso, rispondendo così alla preoccupazione dei consumatori riguardo alla spesa autonoma degli agenti.

Le scelte sull’architettura dei pagamenti che fai oggi non devono ostacolare la preparazione al commercio agentico. In particolare:

• Payment Services su ACCS: lo stack di pagamento su ACCS è in linea con la roadmap agentica di Adobe per il commerce. Tra i partner di Payment Services, PayPal e Adyen sono confermati direttamente nell’elenco iniziale di oltre 60 partner AP2; Stripe, invece, è principalmente allineato con ACP per l’agentic commerce, una soluzione co-sviluppata con OpenAI, e non è confermato come partner AP2. Considera l’allineamento AP2 confermato per PayPal e Adyen, mentre per Stripe è valido solo lato ACP (non AP2).

• API Mesh come livello di instradamento dei pagamenti: il ruolo di API Mesh come endpoint GraphQL unificato e supergraph per Commerce SaaS è parte dell’architettura Adobe documentata, non un modello ipotetico; per questo rappresenta una base solida sia per le query di pagamento agentiche sia per l’instradamento multi-gateway di nuova generazione. Implementare ora API Mesh è una scelta architetturale attuale che ti prepara anche all’agentic commerce.

• Headless pagamento con EDS drop-in: la vetrina EDS con i drop-in per il pagamento crea un’interfaccia di pagamento programmabile ideale per i flussi agentici. Anche i pagamenti tradizionali basati su temi (Luma, PWA e simili) possono essere gestiti in modo programmabile tramite API esistenti e automazione del browser; la differenza più rilevante è che i drop-in EDS offrono un’architettura più pulita e orientata alle API, più adatta ai flussi agentici e composable commerce, non che i pagamenti tradizionali non siano programmabili.

Errori comuni da evitare

• Configurare i pulsanti di pagamento solo sulla pagina di pagamento. PayPal Express, Apple Pay e la messaggistica BNPL sulla pagina del carrello e nel mini-carrello aiutano a ridurre gli ostacoli al pagamento per chi ha maggiore intenzione di acquisto. Inizia dalla pagina del carrello: è il luogo con il rischio più basso per aggiungere nuovi metodi di pagamento.

• Utilizzare Authorize e Capture per i beni fisici. Acquisire il pagamento prima che la consegna sia confermata aumenta il rischio di chargeback e complica la gestione delle consegne parziali. Usa solo Authorize per i beni fisici e acquisisci il pagamento al momento della spedizione.

• Non configurare 3DS per i negozi UE/UK. 3DS è obbligatorio secondo la PSD2 (Direttiva sui servizi di pagamento rivista) per le transazioni con carta nell’UE e nel Regno Unito. Se manca il 3DS, le transazioni legittime vengono rifiutate dalle banche emittenti nei mercati conformi.

• Attivare sia Fastlane che Signifyd. Si tratta di un’incompatibilità documentata: la documentazione di Adobe sulla protezione dalle frodi con Signifyd specifica chiaramente che Fastlane non è compatibile con Signifyd e, inoltre, la release per il pagamento B2B di gennaio 2026 di Adobe disabilita Fastlane per il pagamento B2B proprio per evitare conflitti con i flussi di pagamento B2B. Scegli una delle due soluzioni per il flusso interessato, invece di presumere che possano funzionare insieme.

• Instradare tutte le regioni tramite un unico account Payment Services. Payment Services supporta più account PayPal per regione e brand. Configurando account separati per ogni sito puoi ottenere reportistica per regione, gestione delle valute e controlli di rischio specifici.

• Scegliere un gateway che non supporta i mercati locali futuri. Se l’espansione globale è prevista, scegli un gateway che offra la copertura APM globale di cui avrai bisogno, non solo quella attuale. Migrare i gateway dopo il lancio compromette la cronologia dei pagamenti, le carte salvate e i dati dei modelli antifrode.

• Assenza di un processo di riconciliazione documentato prima del lancio. Payment Services offre report di riconciliazione all’interno di Commerce Admin. I gateway di terze parti esportano verso dashboard separate. Non è stato confermato se l’accesso a reportistica e riconciliazione sia uniforme tra le implementazioni PaaS e ACCS: verifica direttamente con Adobe per il tuo modello di deployment. Definisci e testa il tuo flusso di riconciliazione in staging; eventuali discrepanze finanziarie rilevate in produzione sono costose da risolvere a posteriori.

Punti chiave

• Payment Services è la soluzione di pagamento nativa e gestita di Adobe, confermata come predefinita su ACCS e, secondo il changelog di Adobe di gennaio 2026, attualmente disponibile nella versione v2 drop-in. La copertura è pubblicata per oltre 35 paesi e più di 20 valute, suddivisa tra i livelli Advanced (supporto completo) e Standard (Express Checkout).

• La riduzione dell’ambito PCI è un vantaggio strategico, non solo una questione di conformità. I campi ospitati impediscono che i dati delle carte entrino nei tuoi sistemi e possono aiutarti a qualificarti per SAQ A o SAQ A-EP invece del più oneroso SAQ D, anche se la classificazione finale viene stabilita da un Qualified Security Assessor.

• BNPL sulla pagina di prodotto e nel carrello aumenta l’AOV, non solo la conversione. I messaggi BNPL all’inizio del funnel influenzano le decisioni di acquisto, non solo il completamento del pagamento.

• I pagamenti B2B richiedono drop-in separati con relativa autorizzazione. Payment on Account, Purchase Orders e pagamento tramite Preventivo Negozia­bile sono stati aggiunti insieme nella release Checkout v3.0.0 confermata dell’8 gennaio 2026. Verifica l’autorizzazione nella Admin Console prima di definire l’ambito.

• Fastlane e Signifyd sono indicati come incompatibili nella guida di integrazione di Signifyd di Adobe; inoltre, Fastlane è completamente disabilitato per il checkout B2B. Tieni conto di questo aspetto nella pianificazione, invece di considerarlo solo una limitazione opzionale.

• API Mesh è il supergrafo e layer di integrazione documentato da Adobe per ACCS, e rappresenta una base solida per il routing multi-gateway in base al contesto dello store; ti prepara anche per il routing dei pagamenti agentico, anche se non è una funzionalità specifica di routing dei pagamenti.

• I protocolli di pagamento agentico sono passati dalla fase di roadmap a una parziale implementazione. Il server Commerce MCP di Adobe è attivo da aprile 2026. AP2 è ora gestito dalla FIDO Alliance con PayPal e Adyen come partner confermati; l’allineamento agentico di Stripe avviene tramite ACP, ma la partnership AP2 non è confermata. Scegli oggi una piattaforma di pagamento che non ostacoli la prontezza agentica, basandoti su questi dettagli invece che su una generica nota di “in fase di sviluppo”.

Strumenti e risorse Adobe per la strategia di pagamento:

• Panoramica del prodotto Payment Services per Adobe Commerce

• Guida utente di Payment Services

• Sicurezza di Payment Services e conformità PCI

• Integrazione della protezione contro le frodi Signifyd

• Note sulla versione di Payment Services

• Panoramica dei pagamenti su Adobe Commerce (tutti i metodi)

• Metodi di pagamento B2B — Pagamento su conto e ordini di acquisto

• Protocolli agentici di commercio Adobe Commerce (AP2, ACP, UCP)

• Posizionamento dei pagamenti nello storefront EDS e checkout drop-in

Prossimi passi operativi

• Verifica la configurazione attuale dei pagamenti: elenca tutti i metodi di pagamento abilitati, le pagine in cui sono presenti e se è impostato solo Authorise oppure Authorise and Capture. Questa baseline è spesso presente solo in modo informale nella maggior parte delle implementazioni.

• Esamina la mappa di copertura dei Payment Services (attualmente più di 35 paesi, oltre 20 valute, suddivisi tra livelli Advanced e Standard/Express Checkout) e controlla che copra tutti i mercati attuali e futuri. Documenta quali mercati richiedono la copertura di gateway di terze parti e quale gateway offre gli APM locali necessari.

• Conferma il livello del questionario di autovalutazione PCI. Se utilizzi un gateway che trasmette i dati delle carte tramite i tuoi server, valuta la migrazione agli hosted fields per avvicinarti all’ambito SAQ A e conferma la classificazione ottenuta con un Qualified Security Assessor.

• Per i negozi UE/UK: assicurati che 3DS sia configurato e testato su tutti i flussi di pagamento con carta. Una transazione 3DS non riuscita equivale a un pagamento rifiutato; esegui il test con carte reali emesse nell’UE in ambiente di staging.

• Per le implementazioni B2B: verifica di avere il diritto nell’Adobe Admin Console per i B2B drop-in prima di definire i flussi di lavoro Payment on Account o Purchase Order e assicurati di utilizzare Checkout drop-in v3.0.0 o successiva (rilascio di gennaio 2026) per avere disponibili questi metodi di pagamento. Esegui il test di convalida del limite di credito e del numero PO in staging con dati realistici.

• Se hai sia Fastlane che Signifyd configurati, disattiva uno dei due: Adobe li documenta come incompatibili e l’uso simultaneo non è supportato.

• Definisci e testa il flusso di lavoro di riconciliazione in staging: come i dati di pagamento vengono trasferiti dall’Admin di Commerce al sistema finanziario, come viene convalidata la riconciliazione giornaliera e chi si occupa di indagare sulle eventuali discrepanze. Verifica direttamente con Adobe se ci sono differenze tra PaaS e ACCS se operi su entrambe le piattaforme.