Post tecnico
Guida introduttiva all'integrazione con i gateway di pagamento
Avviare un'applicazione di pagamento significa dover gestire almeno due diversi tipi di integrazione: innanzitutto, è necessario sapere come integrare l'hardware necessario (ovvero il lettore di carte e il dispositivo a cui è collegato); poi occorre sapere come integrarsi con un "back end" di pagamento, come un gateway di pagamento online (il soggetto che "autorizza" la transazione e la elabora per il regolamento).
Nella articoli precedenti, ho parlato ampiamente della parte relativa all'integrazione hardware di questo puzzle, che si rivela non poi così complicata, poiché con i lettori di carte ID TECH è possibile utilizzare il nostro Universal SDK per comunicare con i dispositivi da un ambiente di linguaggio di alto livello, oppure optare per una soluzione puramente in JavaScript, qualora si voglia integrare Node JS nella propria architettura. In entrambi i casi, comunicare con i dispositivi ID TECH non rappresenta davvero un problema significativo.
Rimane però una domanda aperta: una volta che il lettore di carte di credito ha letto il chip o la banda magnetica della carta, come si converte quell'informazione in una transazione approvata?
Presumibilmente, si sa già quale processore di carte di credito gestirà le proprie richieste. Il problema si riduce quindi all'individuare il tipo di supporto SDK che il proprio processore o gateway offre per gestire le richieste online.
La maggior parte dei gateway o dei processori dispone di un programma per sviluppatori o di un portale di sviluppo online, dove è possibile ottenere SDK per la creazione di applicazioni di pagamento. Gli SDK consentono generalmente di sviluppare una combinazione di componenti front-end e back-end per accedere alle API di pagamento del processore. Le API di pagamento, a loro volta, supportano la trasmissione via rete di dati MagStripe e/o di dati ICC (carte con chip) verso un processore back-end, al fine di ottenere un'autorizzazione in tempo reale.
L'autorizzazione di pagamento è in realtà solo uno dei diversi tipi di richiesta online che probabilmente sarà necessario gestire. Alcuni degli altri tipi di richiesta sono illustrati nella tabella seguente.
Tipo di richiesta
Descrizione
Auth
Richiedi autorizzazione per il pagamento
Conf
Conferma una precedente richiesta di autorizzazione
Offline
Liquida una transazione EMV offline
PreAuth
Verifica la validità dei dati della carta tramite una transazione di importo ridotto
Rimborso
Rimborsa una transazione precedentemente liquidata
Test
Verifica la connettività con il processore
VoiceReferralNotification
Notifica al processore il risultato di una richiesta di autorizzazione vocale
Storno
Utilizzato per annullare una transazione non ancora regolata
Studiando la documentazione SDK del proprio processore di pagamento, si noterà che a ciascun tipo di transazione si applicano numerosi codici risultato e/o codici di errore. Come si testano tutti questi possibili tipi di errore? La risposta è semplice: la maggior parte dei processori adotta uno schema in cui l'importo in centesimi di una transazione può essere impostato su un valore speciale per attivare un determinato errore nell'ambiente sandbox di test. (Ad esempio, se il codice di errore per "Importo troppo elevato" è 1243, l'SDK potrebbe consentire di attivare quell'errore specifico inviando una transazione di test per un importo di 12,43 $.) Consultare la documentazione SDK del proprio provider per ulteriori dettagli.
Molti processori di pagamento dispongono di soluzioni "in-app" pre-certificate (semi-integrate) che consentono di instradare i dati della carta crittografati direttamente verso il back-end in modo sostanzialmente trasparente, mantenendo l'applicazione di pagamento al di fuori del "perimetro PCI". Altri, invece, presuppongono che si gestiscano autonomamente le problematiche legate al "perimetro": in tal caso, i dati crittografati della carta verranno probabilmente trasmessi via rete al proprio server applicativo, protetto da firewall, dove — con l'ausilio di un HSM — i dati verranno decriptati prima di essere inoltrati all'acquirer o al gateway.
UN ESEMPIO PRATICO
Basta con la panoramica ad alto livello. Vediamo concretamente cosa significa integrare un back-end di pagamento.
Questo esempio specifico non si applica ovviamente a tutti i casi — nessun esempio singolo può farlo — ma dovrebbe dare un'idea concreta di ciò che si incontrerà nella pratica al momento di integrare un back-end.
In questo caso, il mio compito era sviluppare un'app demo di "terminale virtuale" in grado di inviare i dati delle transazioni al server di test di CreditCall per ottenere un'autorizzazione in tempo reale per le transazioni EMV. CreditCall dispone di un'API server back-end accessibile tramite HTTPS attraverso la loro ChipDNA Direct API, che a sua volta può essere "sviluppato" utilizzando un SDK in Java, C++, Perl o altri linguaggi. Ho scelto la versione Java.
Sul sito web di ChipDNA Direct , mi sono registrato come sviluppatore e ho ricevuto rapidamente (via e-mail) le credenziali per accedere al server di test di CreditCall. Ho anche scaricato il Java SDK di CreditCall e ho iniziato a esaminare il codice di esempio. In particolare, volevo capire come inviare transazioni EMV per l'autorizzazione. Fortunatamente, uno dei file di codice di esempio, ExampleAuthEMV.java, mostrava esattamente il tipo di codice di cui avevo bisogno.
Mi sono messo al lavoro scrivendo due classi Java: una classe servlet per gestire le richieste HTTP da un front end basato su browser, più una classe "worker" per trasmettere i dati del browser (ottenuti dal servlet) al back end di CreditCall. La prima è risultata di circa 250 righe di Java; la seconda, di 92 righe.
Non mostrerò il codice della classe servlet, perché si tratta essenzialmente di codice servlet Java standard, con la differenza che acquisisce i valori TLV (inviati come valori di campi del modulo tramite AJAX) e li inserisce in un oggetto java.util.Hashtable in fase di esecuzione. Tale Hashtable viene poi passata al metodo statico authorize() della mia classe worker. La classe worker utilizza le classi helper (librerie) del SDK ChipDNA Direct di CreditCall per creare un oggetto com.creditcall.Request, che viene quindi passato a un oggetto Client, il quale a sua volta effettua la chiamata al server di CreditCall. Ecco il codice:
Questo codice è così breve e autoesplicativo da non richiedere ulteriori commenti. La cosa interessante è che le classi Request e Client di CreditCall si occupano di creare i documenti XML necessari che vengono infine inviati al server di CreditCall. In quanto sviluppatore, non è mai necessario visualizzare, modificare, analizzare o preoccuparsi dell'XML grezzo (proprio come dovrebbe essere).
Si noti che è necessario fornire le credenziali del proprio account di test alle righe 18 e 19. (Le credenziali mostrate sopra sono fittizie. Non tentare di utilizzare il codice così com'è!) La riga 69 è dove si imposta l'URL dell'endpoint di CreditCall. La riga 72 effettua la chiamata HTTPS in uscita.
Il server di CreditCall non è particolarmente esigente riguardo ai tag TLV da includere nei dati della transazione, purché siano presenti quelli contenenti i dati essenziali della carta (ad esempio: i tag 5A e 57 per EMV a contatto; il tag 56 per i pagamenti contactless; oltre a 9F26 e 9F27, contenenti le informazioni sul crittogramma). In risposta ai dati EMV, il server di CreditCall restituirà generalmente i TLV per i tag 8A, 89 e 91, e facoltativamente 71 o 72 (se è necessario trasmettere script alla carta con chip). Il codice di autorizzazione desiderato si trova nel tag 89.
Dopo vari tentativi, ho scoperto che l'applicazione server CreditCall non è rapida nel rifiutare una transazione semplicemente perché la carta presenta un crittogramma AAC. (È possibile determinare il tipo di crittogramma esaminando i bit più significativi del tag 9F27. Il valore zero indica un AAC, ovvero un rifiuto.) Ciò non sorprende, tuttavia, poiché l'indicazione della carta è appunto questo: un suggerimento. La decisione finale di approvare o rifiutare una transazione EMV spetta generalmente all'acquirer. La carta può essere — e spesso lo è — ignorata.
Come si può notare, lavorare con questi strumenti permette di apprendere molti dettagli interessanti su EMV. Nulla è più efficace di un'autorizzazione in tempo reale per verificare il codice di un'applicazione di pagamento!
Cerchi ulteriori informazioni sulle transazioni EMV? Visita la nostra pagina Development Home sulla Knowledge Base di ID TECH. Scarica il nostro white paper sullo sviluppo EMV. Oppure chiama uno dei nostri esperti al numero verde per iniziare con un kit di valutazione: