Pagamenti con carta
Pagamenti con carta: dal terminale all’acquirer e ritorno al libro giornale
Terminali EMV e gateway di pagamento collegati agli acquirer via ISO 8583 o API, con file di regolamento riconciliati nell’ERP.
Blueprint
Scorra lateralmente per vedere l’intero disegno.
Pagamenti con carta: autorizzati alla cassa, regolati in seguito, riconciliati nell’ERP
Il terminale o il checkout interroga il gateway, il gateway interroga l’acquirer e l’acquirer instrada verso il circuito di carte e l’emittente. I file di regolamento arrivano in seguito e sono riconciliati con vendite e commissioni nell’ERP. Un timeout attiva uno storno, così il cliente non viene mai addebitato due volte.
- Flusso principale
- Asincrono
- Percorso di eccezione
Il flusso in 8 passi
Il flusso, passo per passo
- Da Terminale EMV o checkout online a Gateway di pagamento: Richiesta di autorizzazione, tramite EMV · REST/JSON (flusso principale).
- Da Gateway di pagamento a Acquirer: Autorizzazione, tramite ISO 8583 (flusso principale).
- Da Acquirer a Circuito di carte ed emittente: Instradata all’emittente, tramite ISO 8583 (flusso principale).
- Da Acquirer a Gateway di pagamento: Approvata o rifiutata, tramite ISO 8583 (asincrono).
- Da Acquirer a Livello di integrazione: File di regolamento e commissioni, tramite SFTP (asincrono).
- Da Livello di integrazione a ERP: Vendite, commissioni e pagamenti in uscita regolati, tramite REST/JSON (flusso principale).
- Da Gateway di pagamento a Terminale EMV o checkout online: Nessuna risposta in tempo: storno automatico, tramite ISO 8583 0400 (percorso di eccezione).
- Da Livello di integrazione a Team operativo dei pagamenti: Discrepanza di regolamento o chargeback (percorso di eccezione).
Panoramica
Questo è il percorso di un pagamento con carta, dal terminale o dal checkout online all’acquirer, al circuito della carta e all’emittente, e ritorno. Il cliente aspetta la risposta alla cassa. Il denaro, meno le commissioni, arriva più tardi in un file di regolamento da riconciliare con le vendite nell’ERP.
Il progetto di riferimento invia le autorizzazioni attraverso un gateway di pagamento che tokenizza la carta e instrada la richiesta all’acquirer, su ISO 8583 o tramite l’API dell’acquirer. I file di regolamento e commissioni sono raccolti dallo strato di integrazione, riconciliati con le vendite originali e registrati nell’ERP come vendite, commissioni e pagamenti ricevuti.
Il progetto copre anche ciò che va storto. Una richiesta che non riceve risposta in tempo viene stornata, così il cliente non viene addebitato due volte. Un regolamento che non torna, o un chargeback, arriva al Suo team operativo dei pagamenti con la vendita originale allegata.
Come funziona il flusso
Partire dal terminale o dal checkout
Il terminale EMV legge il chip o la carta contactless, oppure il checkout online raccoglie la carta tramite una pagina ospitata, e invia una richiesta di autorizzazione al gateway.
Autorizzare tramite il gateway
Il gateway sostituisce il numero di carta con un token e invia l’autorizzazione all’acquirer, su ISO 8583 o tramite l’API dell’acquirer.
Instradare all’emittente
L’acquirer instrada la richiesta attraverso il circuito della carta all’emittente, che la approva o la rifiuta.
Restituire la risposta
L’approvazione o il rifiuto tornano lungo lo stesso percorso al terminale o al checkout, con il relativo codice di risposta.
Ricevere il regolamento
L’acquirer invia più tardi i file di regolamento e commissioni, che lo strato di integrazione raccoglie e valida.
Riconciliare e registrare
Lo strato riconcilia le transazioni regolate con le vendite originali e registra vendite, commissioni e pagamenti ricevuti nell’ERP.
Quando qualcosa fallisce
Nessuna risposta in tempo
Se il gateway non riceve risposta entro il limite dell’acquirer, invia uno storno, un messaggio ISO 8583 0400 o il suo equivalente API, così il cliente non viene mai addebitato per una vendita non completata.
Un pagamento viene rifiutato
Il codice di risposta arriva alla cassa o al checkout con un messaggio chiaro. I tassi di rifiuto sono monitorati, così un balzo che indica un guasto tecnico genera un avviso.
Il regolamento non corrisponde
Un importo regolato diverso dalla vendita, o una vendita senza regolamento, finisce in un elenco di revisione per il Suo team operativo dei pagamenti, con entrambi i record affiancati.
Un titolare contesta un pagamento
Il report delle contestazioni dell’acquirer viene importato e collegato alla vendita e al regolamento di origine, così il Suo team può rispondere con le prove in un unico posto.
Standard e sistemi
- Standard e canali bancari
- SFTP (H2H)
- Pagamenti
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integrazione
- REST
- Webhooks
Domande e risposte
Qual è la differenza tra un gateway e un acquirer?
L’acquirer è la banca o l’istituzione autorizzata che elabora i pagamenti con carta per Lei e Le versa il denaro. Il gateway è il servizio tecnico davanti ad essa che accetta richieste da terminali e checkout, tokenizza le carte e le instrada. Alcuni fornitori sono entrambe le cose. Il progetto funziona in ogni caso e tiene distinti i due ruoli.
Questo tiene i dati delle carte fuori dai nostri sistemi?
È l’obiettivo del progetto. I numeri di carta sono acquisiti dal terminale certificato o da una pagina di pagamento ospitata e sostituiti da token al gateway, così POS, ERP e archivi dati vedono solo token. Questo riduce la parte del Suo patrimonio a cui si applica PCI DSS. Il Suo valutatore conferma il perimetro finale.
ISO 8583 è uguale per ogni acquirer?
No. ISO 8583 definisce una struttura, e ogni acquirer o circuito pubblica la propria specifica di campi, tipi di messaggio e codici. Per questo costruiamo dalla specifica dell’acquirer ed eseguiamo i suoi test di certificazione. Un’API gateway davanti all’acquirer nasconde queste differenze, cosa spesso più semplice per gli operatori del commercio al dettaglio.
Perché il regolamento arriva dopo la vendita?
L’autorizzazione riserva soltanto i fondi. L’acquirer regola in lotti, dopo aver dedotto le proprie commissioni e gli oneri del circuito, e versa secondo il proprio calendario. Per questo il progetto tratta autorizzazione e regolamento come eventi separati e li riconcilia, così la finanza vede che cosa è stato venduto, che cosa è stato regolato e che cosa deve ancora arrivare.
Supportate EMV 3-D Secure per i pagamenti online?
Sì. Per i pagamenti con carta online integriamo EMV 3-D Secure tramite il gateway, così l’emittente può autenticare il titolare dove la normativa o il rischio lo richiedono. Gestiamo i flussi challenge e frictionless nel checkout e collaudiamo entrambi con le carte di test del fornitore.
Possiamo usare più di un fornitore di pagamento?
Sì. Lo strato di integrazione mantiene un unico modello interno del pagamento e lo mappa su ogni fornitore, così può instradare per canale, Paese o tipo di carta, oppure spostare volumi tra fornitori. Ogni fornitore richiede comunque la propria integrazione e certificazione, che pianifichiamo fornitore per fornitore.
Inizi con una conversazione, non con un contratto.
Ci racconti che cosa deve costruire, collegare o proteggere. Un architetto lo esamina con Lei e poi consiglia da dove iniziare.
Che cosa succede dopo
Concordare un orario
Il nostro team Le invia un’e-mail per concordare un orario per la sessione.
Sessione di preconsulenza
Una sessione di preconsulenza online gratuita di 30 minuti: esaminiamo i Suoi obiettivi, i Suoi sistemi e i Suoi vincoli.
Revisione di preparazione
Nell’ambito di una revisione di preparazione gratuita di 48 ore, un architetto principal verifica il Suo progetto rispetto alla definizione di «pronto» in 6 punti e raccomanda il Track più adatto.
Scelta del Track
I progetti con perimetro definito ricevono una proposta vincolante entro 3–5 giorni lavorativi. I progetti in fase di concept iniziano nel Blueprint Studio. Un sistema in produzione che non funziona, non è documentato o richiede integrazione inizia con una diagnosi di 1–2 settimane. Il Blueprint Studio e la diagnosi hanno ciascuno un compenso fisso, indicato nella proposta.