Fasi e stati delle transazioni

Ogni pagamento segue un percorso. Ciò che appare istantaneo a un consumatore (quel rapido messaggio di "approvato" su uno schermo) in realtà è una catena di passaggi strettamente orchestrati che avvengono tra diversi sistemi in pochi secondi. Ripercorriamo prima il tipico happy flow, quello in cui tutto va per il verso giusto.

Il flusso felice

Tutto inizia quando un consumatore avvia un pagamento: online oppure su un terminale. Il sistema del merchant o il payment gateway invia una richiesta di autorizzazione sicura tramite l'acquirer e la card network all'issuer, ponendo una domanda semplice ma cruciale: questa carta è valida, ci sono fondi sufficienti e questa carta può essere autorizzata?

Se l'issuer approva, la transazione è autorizzata. In questa fase, i fondi non sono ancora trasferiti. Sono semplicemente riservati sul conto del cliente, in attesa che il merchant li finalizzi in seguito. Questo stato riservato impedisce che lo stesso denaro venga speso due volte.

Una volta che il merchant conferma l'ordine o spedisce la merce, invia un'istruzione di capture. In alcuni casi, questo passaggio avviene automaticamente, senza approvazione del merchant. Questo dice all'acquirer: "Sì, trasferisci ora il denaro". L'acquirer quindi raggruppa più capture insieme e le invia alle card network durante il clearing.

Infine, nella fase di settlement, avviene il trasferimento effettivo dei fondi. L'issuer invia il denaro (meno le fee) all'acquirer, che poi paga il merchant. Questo di solito avviene entro uno o tre giorni lavorativi, a seconda dell'accordo di settlement del merchant.

In un mondo perfetto, ogni pagamento finirebbe proprio lì: il cliente è soddisfatto, il merchant viene pagato e tutti vanno avanti. Ma i pagamenti non sono sempre perfetti — a volte vengono annullati, rimborsati o contestati.

Quando le cose non vanno come previsto

Non tutti i pagamenti hanno un lieto fine. A volte i clienti annullano, le transazioni falliscono o sorgono contestazioni settimane dopo. Nei pagamenti, questi "bad flow" sono importanti da capire tanto quanto quelli positivi. Mostrano come funzionano in pratica rischio, reversal e protezione del cliente. Vediamo i tre flussi di eccezione più comuni: void, refund e chargeback.

Void / Cancellazioni

Un void avviene quando una transazione viene cancellata prima che sia captured o settled. Si può pensare come a un "annullamento" di un'autorizzazione che non si è ancora trasformata in un vero trasferimento di denaro.

Per esempio, un cliente potrebbe annullare un ordine subito dopo averlo effettuato, oppure un merchant potrebbe notare una transazione duplicata. In questi casi, invece di elaborare un refund (che riporta indietro il denaro e richiede alcuni giorni), il merchant può voidare l'autorizzazione.

Poiché i fondi erano solo riservati e non sono mai stati effettivamente trasferiti, un void semplicemente rilascia il blocco sul conto del cliente. Il saldo disponibile del titolare della carta torna alla normalità, di solito entro uno o due giorni (o istantaneamente, dipende dalla banca del consumatore!), e non sono previste fee oltre al costo originale dell'autorizzazione. In breve, un void è un reversal pulito: rapido, efficiente e invisibile per la maggior parte dei clienti.

Refund

Un refund arriva dopo che una transazione è stata captured e settled. Questo significa che il merchant ha già ricevuto i fondi, ma ora deve restituirne una parte o l'intero importo. I refund sono comuni nel commercio quotidiano: un prodotto restituito, una prenotazione cancellata o un errore di fatturazione. Possono essere full (l'intero importo) o partial (solo una parte del pagamento). A seconda del tipo di transazione, può essere possibile uno solo o più refund.

Quando viene attivato un refund, il sistema del merchant invia un messaggio tramite l'acquirer e la card network all'issuer, istruzioni per accreditare il conto del cliente. A seconda della network e delle banche coinvolte, questo processo può richiedere da uno a cinque giorni lavorativi. E può persino volerci più tempo perché il consumatore riceva i fondi (si pensi alla banca emittente o al merchant che impiega più tempo a elaborare una richiesta).

A seconda del gateway, un refund può essere creato come transazione separata oppure come parte dell'organizzazione padre all'interno dello strumento di gestione del merchant. In alcuni casi, i refund potrebbero non essere collegati a un'autorizzazione padre. Possiamo riferirci a questi come unreferenced refunds.

Pur essendo semplice dal punto di vista del cliente, i refund comportano un costo operativo per il merchant. La maggior parte degli acquirer addebita piccole fee per refund e, in molti casi, le fee della transazione originale non vengono rimborsate. Refund frequenti possono anche influire sulla reputazione del merchant presso gli acquirer o i payment provider.

Chargeback

Il chargeback è lo scenario peggiore nella vita di una transazione. Si verifica quando l'issuer annulla forzatamente un pagamento dopo una contestazione del cliente. Ecco come si svolge tipicamente: il titolare della carta nota un addebito sconosciuto o problematico e contatta la propria banca per contestarlo. L'issuer indaga e, se la richiesta sembra valida, preleva i fondi dall'acquirer del merchant: che a sua volta addebita il conto del merchant.

Le ragioni dei chargeback variano:

  • Frode o uso non autorizzato di una carta
  • Merce non ricevuta o servizi non erogati
  • Articoli non conformi alla descrizione
  • Addebito duplicato o errori tecnici
  • Refund promessi ma mai ricevuti

Per i merchant, un chargeback è sia una perdita di fondi sia un potenziale segnale di scarsa customer experience o esposizione alla frode. Ogni chargeback comporta anche fee amministrative. Se il merchant ritiene che la contestazione sia ingiusta, può contestarla a sua volta. Questo comporta l'invio di prove (come conferme di consegna, ricevute o corrispondenza) per dimostrare che la transazione era legittima. Tuttavia, anche quando ha successo, la representment richiede tempo e impegno. Chargeback ripetuti possono comportare penalità o l'inclusione nei programmi di monitoraggio delle card scheme. Chargeback = niente di buono. La cosa migliore è risolvere prima la contestazione con il consumatore.

E poi ci sono gli errori

Anche i sistemi di pagamento costruiti con la massima cura a volte inciampano. Non tutte le transazioni arrivano al traguardo. Decline ed errori fanno parte della vita quotidiana dei pagamenti — l'attrito invisibile dietro "qualcosa è andato storto". Possono verificarsi per centinaia di motivi, da qualcosa di innocuo come un refuso a qualcosa di serio come una frode sospetta.

Per i merchant, questi momenti sono frustranti; per i clienti, sono semplicemente confusi. I principali responsabili:

  • Fondi insufficienti (≈ 30–40 % dei decline) — il motivo più semplice e più umano
  • Regole di rischio o frode dell'issuer (≈ 25 %) — le banche bloccano ciò che sembra sospetto, soprattutto transazioni cross-border o insolitamente elevate
  • Carte scadute o inattive (≈ 10 %) — ancora sorprendentemente comuni
  • Errori tecnici (≈ 10 %) — interruzioni di rete, timeout o incompatibilità di protocollo
  • Credenziali errate (≈ 5–10 %) — CVV, codice postale o fallimento di 3-D Secure errati

I provider validi mitigano questo problema con retry intelligenti, network tokenization e routing intelligente. Anche un miglioramento di due punti nel tasso di approvazione può significare milioni di ricavi aggiuntivi per i grandi merchant. I decline non scompariranno mai, ma capire perché accadono aiuta i merchant a correggere ciò che è sotto il loro controllo — e a smettere di dare la colpa a ciò che non lo è. Vediamo perché accadono e come vengono tipicamente classificati.

Hard Declines

Un hard decline significa che l'issuer — la banca del cliente — ha rifiutato senza mezzi termini la transazione e nessun retry aiuterà. Le cause comuni includono:

  • Fondi insufficienti o limite di credito superato
  • Carta scaduta.
  • Numero di carta non valido (PAN digitato male o obsoleto)
  • Carta smarrita o rubata
  • Carta con restrizioni (non abilitata per determinate regioni, valute o categorie di merchant)

Quando ciò accade, l'autorizzazione fallisce immediatamente. Il merchant può mostrare un messaggio di errore amichevole, ma riprovare non risolverà il problema — il cliente deve usare un altro metodo di pagamento. Molti hard decline possono essere prevenuti a monte intercettando errori di input evidenti: lunghezza errata del numero di carta, CVV non valido o carte scadute.

Soft Declines

Un soft decline è diverso. L'issuer rifiuta temporaneamente la transazione, ma un retry potrebbe avere successo. Questi sono spesso legati all'autenticazione o a problemi di rete temporanei, come:

  • Fallimento o timeout dell'autenticazione 3D Secure
  • Sistema dell'issuer non disponibile
  • Errore temporaneo di routing o dell'acquirer
  • Limite giornaliero superato o schema di spesa insolito

In questi casi, il gateway può riprovare automaticamente o invitare il cliente a riprovare. I soft decline sono comuni nell'e-commerce, dove più sistemi e network devono rimanere sincronizzati.

Decline legati alla frode

Poi ci sono i decline attivati dai sistemi di prevenzione frodi — lato issuer, lato acquirer o lato merchant. Esempi includono:

  • Posizione insolita o device fingerprint
  • Più tentativi falliti di CVV o 3D Secure
  • Velocity limits (troppi pagamenti in un breve periodo)
  • Card testing da parte di bot o dati rubati

I filtri antifrode si stanno costantemente regolando. A volte bloccano un acquirente legittimo — un falso positivo. Trovare l'equilibrio tra intercettare la frode e consentire il passaggio dei clienti reali è una delle sfide più difficili nei pagamenti. Alcuni provider ora consentono ai merchant di regolare le proprie regole di rischio per perfezionare questo equilibrio.

Errori di comunicazione e tecnici

A volte, il problema non è affatto la carta o il cliente. Gli errori tecnici si verificano quando un messaggio di transazione non riesce a viaggiare correttamente — timeout, dati malformati, interruzioni dell'acquirer o incompatibilità di protocollo.

Di solito i gateway gestiscono questi casi ritentando o mettendo in coda le transazioni per un invio successivo. La maggior parte viene risolta rapidamente, ma se l'errore colpisce durante l'autorizzazione, il pagamento semplicemente fallisce. Per merchant e PSP, questo è lo scenario peggiore — ricavi persi senza un colpevole chiaro. Nei casi gravi, tali interruzioni possono persino attivare penalità o richieste di service credit nei confronti della parte responsabile.

Stati delle transazioni

Ogni pagamento che fai o elabori attraversa una serie di stati. Istantanee di dove si trova attualmente quella transazione nel suo percorso.

Questi stati aiutano merchant, gateway e acquirer a monitorare l'avanzamento, rilevare problemi e riconciliare i fondi. Sebbene la vita completa di una transazione coinvolga autorizzazioni, capture, refund e chargeback, questi stati rappresentano i punti di controllo lungo il percorso. Questi stati possono differire a seconda del gateway o del service provider. Per semplificare, ho cercato di riassumere gli stati esistenti nella tabella qui sotto e il loro flusso.

Stati delle transazioni, riassunti.

Stato Descrizione Significato nel flusso
Pending La transazione è appena stata creata — da un utente, da un terminale POS o da una chiamata API. È la primissima fase, spesso dura solo pochi secondi prima di proseguire. Pensalo come "pagamento richiesto". Nulla è ancora stato confermato.
Authorized L'issuer ha approvato il pagamento e i fondi sono riservati sul conto del titolare della carta. Il merchant deve ancora effettuare il capture dell'importo per ricevere effettivamente il denaro. La transazione è riuscita dal punto di vista del cliente, ma non è ancora finalizzata.
Cancelled / Void La transazione è stata cancellata prima del capture. Nessun fondo si è mosso e il blocco dell'autorizzazione è stato rilasciato. Spesso usato per ordini cancellati o transazioni duplicate intercettate in anticipo.
Declined L'acquirer o l'issuer ha rifiutato la transazione. Non si è verificata alcuna riserva o trasferimento di fondi. Il cliente potrebbe dover provare un'altra carta o un altro metodo di pagamento.
Failed La transazione non è stata completata a causa di un problema tecnico — forse un timeout, un guasto di rete o un formato messaggio non valido. Non è stata ricevuta alcuna risposta di autorizzazione; si tratta di un errore di elaborazione, non di un decline finanziario.
Captured Il merchant ha confermato la transazione e l'importo specificato è in elaborazione per il settlement. Il denaro è di fatto impegnato e si muoverà durante il prossimo ciclo di clearing.
Submitted La transazione è stata consegnata all'acquirer per il clearing. Ora è in coda per essere elaborata attraverso gli scheme. Tra "Captured" e "Cleared". Utile per il tracciamento della riconciliazione.
Cleared L'acquirer ha inviato la transazione agli scheme e sta aspettando il settlement finale. (Stato specifico di Planet.) La transazione ha attraversato con successo la pipeline finanziaria ma non è ancora stata pagata.
Funded L'acquirer ha completato il payout sul conto bancario del merchant. (Stato specifico di Planet.) Il merchant ha ricevuto i fondi — la fase finanziaria finale.
Partially Refunded Solo una parte dell'importo captured è stata restituita al cliente. Comune quando un merchant effettua un aggiustamento per articoli restituiti o cancellazioni parziali.
Refunded L'intero importo captured è stato restituito al cliente. La transazione è chiusa da entrambe le parti; il merchant non detiene più i fondi.
Disputed Il titolare della carta ha contestato la transazione ed è in corso un'indagine. L'importo potrebbe essere temporaneamente trattenuto fino alla risoluzione della contestazione.
Chargeback La contestazione è stata risolta a favore del titolare della carta e i fondi sono stati restituiti al suo conto. È stato elaborato un refund forzato

Phuuu... se sei arrivato fin qui, complimenti. Capire gli stati è probabilmente una delle sfide più grandi quando si vuole capire i pagamenti.

Buy Me a Coffee
undefined