Post tecnico
Introduzione all'integrazione con il gateway di pagamento
Mettere in funzione un'app di pagamento significa saper gestire almeno due diversi tipi di integrazione: innanzitutto, è necessario sapere come integrare l'hardware richiesto (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 post precedenti, ho parlato ampiamente della parte relativa all'integrazione hardware di questo puzzle, che si rivela non così complicata: con i lettori di carte ID TECH, è possibile utilizzare il nostro Universal SDK per comunicare con i dispositivi da un ambiente di linguaggio ad alto livello, oppure optare per una soluzione in puro JavaScript, qualora si voglia includere Node JS nella propria architettura. In entrambi i casi, comunicare con i dispositivi ID TECH non rappresenta un ostacolo particolarmente 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 tale informazione in una transazione autorizzata?
Presumibilmente, si sa già quale processore di carte di credito gestirà le richieste. Il problema si riduce quindi all'individuazione del tipo di supporto SDK offerto dal proprio processore o gateway per l'elaborazione delle richieste online.
La maggior parte dei gateway o dei processori dispone di un programma per sviluppatori o di un portale di sviluppo online, attraverso cui è possibile ottenere SDK per la creazione di app di pagamento. Gli SDK consentono generalmente di sviluppare una combinazione di componenti front-end e back-end per l'accesso alle API di pagamento del processore. Le API di pagamento, a loro volta, supportano l'invio di dati MagStripe e/o ICC (carta con chip) tramite rete a un processore back-end, al fine di ottenere un'autorizzazione in tempo reale.
L'autorizzazione al 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 l'autorizzazione per il pagamento
Conf
Conferma una precedente richiesta di autorizzazione
Offline
Regola una transazione EMV offline
PreAuth
Verifica la validità dei dati della carta tramite un importo di transazione ridotto
Refund
Rimborsa una transazione precedentemente saldata
Test
Verifica la connettività con il processore
VoiceReferralNotification
Notifica al processore il risultato di una richiesta di referral vocale
Void
Utilizzato per annullare una transazione non ancora regolata
Consultando la documentazione SDK del proprio processore di pagamento, si noterà che a ciascun tipo di transazione si applicano numerosi codici di risultato e/o codici di errore. Come si fa a testare 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.) Per i dettagli, consultare la documentazione SDK del proprio provider.
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 più o meno trasparente, mantenendo l'applicazione di pagamento al di fuori del "perimetro PCI". Altri, invece, presuppongono che sia l'utente a gestire autonomamente le problematiche legate al "perimetro": in questo caso, i dati della carta crittografati verranno probabilmente trasmessi via rete al proprio server applicativo, protetto da firewall, dove (con l'ausilio di un HSM) i dati verranno decrittografati prima di essere inoltrati a un acquirer o a un 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 di ciò che è probabile incontrare al momento dell'integrazione con un back end.
In questo caso, mi è stato affidato il compito di realizzare un'app demo di "terminale virtuale" che invia 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, utilizzando il loro ChipDNA Direct API, che a sua volta può essere "sviluppato" tramite un SDK in Java, C++, Perl o altri linguaggi. Ho scelto la versione Java.
Sul sito ChipDNA Direct mi sono registrato per un account 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 ad esaminare il codice di esempio. Volevo in particolare capire come inviare transazioni EMV per l'autorizzazione. Per fortuna, uno dei file di codice di esempio, ExampleAuthEMV.java, conteneva 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 provenienti 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 si è rivelata essere di circa 250 righe di Java; la seconda, 92 righe.
Non mostrerò il codice della classe servlet, poiché si tratta essenzialmente di codice Java servlet standard, con la differenza che acquisisce i valori TLV (inviati come valori di campo modulo tramite AJAX) e li inserisce in un oggetto java.util.Hashtable in fase di esecuzione. Quell'Hashtable viene quindi passato al metodo statico authorize() della mia classe worker. La classe worker utilizza le classi helper (libreria) del CreditCall ChipDNA Direct SDK per creare un oggetto com.creditcall.Request, che viene poi 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 CreditCall Request e Client si occupano di creare i documenti XML necessari che vengono infine inviati al server di CreditCall. Come sviluppatore, non è mai necessario visualizzare, gestire, analizzare o preoccuparsi dell'XML grezzo (proprio come dovrebbe essere).
Si noti che è necessario fornire le credenziali del proprio account di test nelle 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 CreditCall. La riga 72 esegue la chiamata HTTPS in uscita.
Il server CreditCall non è particolarmente esigente riguardo ai tag TLV inviati nei dati della transazione, a condizione che siano inclusi quelli contenenti i dati essenziali della carta (ad esempio: i tag 5A e 57 per EMV contact; il tag 56 per il contactless; oltre a 9F26 e 9F27, contenenti le informazioni sul crittogramma). In risposta ai dati EMV, il server CreditCall restituisce generalmente TLV per i tag 8A, 89 e 91, e facoltativamente 71 o 72 (se è necessario trasmettere script alla carta chip). Il codice di autorizzazione desiderato si trova nel tag 89.
Con tentativi ed errori, ho scoperto che l'applicazione server CreditCall non è incline a rifiutare una transazione soltanto 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 AAC, ovvero Rifiuto.) Ciò non sorprende, poiché l'indicazione della carta è appunto un suggerimento, nulla di più. La decisione finale di approvare o rifiutare una transazione EMV spetta generalmente all'acquirer. Il responso della carta può essere — e spesso viene — ignorato.
Come si può notare, sperimentare con questi elementi permette di apprendere numerosi dettagli interessanti su EMV. Quando si tratta di verificare il codice di un'applicazione di pagamento, nulla vale quanto eseguire un'autorizzazione in ambiente reale!
Cerchi ulteriori indicazioni sulle transazioni EMV? Visita la pagina Development Home sulla Knowledge Base di ID TECH. Scarica il nostro white paper sullo sviluppo EMV. Oppure contatta gratuitamente uno dei nostri esperti per iniziare con un kit di valutazione: