Archivio mensile:Ottobre 2009

Twitter, nascono le Liste (aggregare i Following)

twitter news lists

Stamattina ho aperto Twitter via web e nella Home mi è stata segnalata subito una novità molto interessante, diciamo che era attesa da tempo e da molti. Da oggi è possibile creare Liste e gli altri utenti possono decidere se seguirle. Nel momento in cui decido di seguire una lista questa viene aggiunta alle mie, cliccando poi  vedrò tutto il flusso degli utenti appartenenti alla lista.
In pratica ogni lista funziona come fosse un account autonomo, con i propri followers e following.

twitter news lists box

Nella colonna di destra della Home, come evidenziato nell’immagine qui sopra, è presente un nuovo box che elenca le prime 5 liste (credo, sto ancora studiando). Cliccando su “View all” invece vengono visualizzate tutte, sia le proprie (create da noi) che quelle che decidiamo di seguire.
Per creare una nuova lista invece basta cliccare su “New list” e assegnarle un nome. Come impostazione di default la lista è pubblica ma è anche possibile renderla privata (vedi lucchetto nell’immagine sopra).
Per aggiungere un utente ad una lista personale basta eseguire l’operazione dalla sezione dedicata ai propri following, cliccando sulla nuova icona appositamente creata.

A me questa novità piace moltissimo per due motivi:

  1. Organizzare i proprio following era qualcosa di veramente necessario
  2. Permette di seguire in un colpo solo altre liste sugli argomenti di proprio interesse “delegando” ad altri la scelta dei partecipanti alla lista

Twitter è sempre più bello e funzionale!

Segnalazione guasti e problemi via Twitter?

Semafori

Ieri sera, verso le 19.30, sono uscito per andare a prendere le pizze, oltre al latte crudo per il giorno dopo. Ho preso la bicicletta elettrica per fare meno fatica, lo ammetto.
C’era buio e il semaforo dell’incrocio tra Viale Risorgimento e Via E. Simonazzi aveva qualche problema, almeno quello da cui provenivo io (direzione ospedale). In pratica abbiamo atteso a lungo il verde ma non si accendeva, a dire il vero era completamente spento. Quando sono partite le macchine mi sono lanciato anche io sperando fosse davvero verde e rischiando anche qualche punto della patente.

Perchè vi racconto questa storia quasi inutile?

Perchè appena superato il semaforo avrei voluto chiamare qualcuno. Quando sono arrivato dal pizzaiolo (Anima e Core in Viale Risorgimento, ve lo consiglio!) ho pensato: “Chiamo i vigili.” … ero in mezzo alla strada… “Qual’è il numero dei vigili?“.
Poi ho pensato: “allora mando un tweet“. Ma chi lo legge? Nessuno, o forse domani quando sarà tardi. E poi, onestamente, non frega niente a nessuno.

Così ho avuto una mezza idea, ho pensato ad un canale Twitter del Comune, dei Vigili, ecc. Chiunque potrebbe in qualsiasi momento inviare una segnalazione. Le strutture preposte, monitorando il canale, avrebbero un quadro completo dei disagi e problemi che si susseguono nella città.

Fantascienza?

myGDM, la Community che non c’è. Dov’è finita?

GDM Community logo - OLD version
[GDM Community Logo – OLD version]

Prima di lasciar spazio alle modifiche che arriveranno e che lentamente cambieranno myGDM è bene analizzare il passato per non commettere gli stessi errori. Sempre.

myGDM 2.0 nasce l’8 Maggio del 2008 con tutte le buone intenzioni di risolvere diversi problemi che molti di voi, quelli che c’erano, hanno già dimenticato. Vorrei ribadire ancora una volta a tutti che siete stati “bianchi” prima di diventare quello che siete. I Newbie (bianchi) sono la linfa di GDM, senza sarei rimasto a giocare con i miei amici come era nel lontano 2005.

L’espansione di GDM ha fatto sì però che arrivassero Newbie di tutte le specie. In breve tempo ci trovammo una situazione ingestibile perchè avevano troppa libertà: entravano ovunque, facevano saltare tavoli, disturbavano pesantemente in chat con offese e lasciavano feed di ogni tipo. Il tutto era incontrollabile e i tempi in cui Stingary Smith ed emiro li insultavano, ribaltando la frittata, erano andati da tempo. La maggior parte delle volte invece c’era gente che si scandalizzava scrivendo email di protesta “a chi di dovere“. Più volte infatti abbiamo dovuto bloccare gli indirizzi IP delle macchine da cui alcuni di loro provenivano, spesso erano Università (o Istituzioni) e vi assicuro che la cosa non è bella: isolare un’Università intera per un cretino è devastante.
Di contro però, in mezzo a tanti rompic*****, c’erano i “buoni“. Quelli che non riuscivano, non dico ad emergere nel caos e nella bolgia più totale, ma nemmeno a giocare. Nel frattempo giustamente i Member (blu) avevano fatto quadrato considerando a priori i Newbie (bianchi) come utenti da tenere alla larga e quindi fuori dai Tavoli. Erano pochi coloro che continuavano ad ospitare i bianchi nei loro Tavoli. Pochi ma buoni, buona parte di loro divenne poi, guarda caso, Tutor.

La guerra tra Member e Newbie andava fermata e così iniziai a ragionare su una nuova era di GDM: myGDM 2.0 appunto. Era necessario bloccare il dilagare di Newbie “inutili” e allo stesso tempo garantire ai “buoni” un ingresso in Community. Per agevolare tutto ciò separai completamente i 2 ambienti garantendo da una parte, ai Member, un ambiente “sano e pulito”, dall’altra, ai Newbie, un corridoio preferenziale per l’accesso alla Community. Ma chi li controllava? Chi poteva umanamente stabilire chi erano in realtà i nuovi arrivati? E così pensai ai Tutor e a tutti gli strumenti necessari per agevolare questa “selezione”.

C’era un’altra necessità però, un po’ perchè i feedback non bastavano più, un po’ perchè crescendo la diversità tra loro si iniziava a far sentire, i Member avevano bisogno di ritagliarsi il proprio spazio, personalizzarsi l’ambiente. Nella totale democrazia ho sempre ipotizzato e lavorato per un GDM libero. Libero nel senso che ognuno doveva poter esprimere le proprie opinioni o poter giocare con chi desiderava nel modo in cui desiderava. Chi ama giocare divertendosi deve poterlo fare, chi ama giocando con passione e agonismo anche. Non devono esistere confini per nessuno, questo il mio “sogno” per GDM.
Ma come fare per raggiungere tutto ciò?
I Social network erano in piena espansione e il concetto di “amicizia” piaceva ai più. Sposai la loro strategia e creai le relazione sociali: gli amici.

In tutto questo avevo introdotto anche i GDM Player (azzurri). I Newbie che, dopo aver conosciuto un po’ le dinamiche del sito, venivano passati a questa categoria intermedia e potevano entrare in contatto con i Member. Divenivano Player però anche i Member a cui scadeva l’abbonamento e quindi non potevo dar loro troppe “restrizioni”.
Così per tagliare la testa al toro pensai alle esclusioni. Pensai ad un sistema dove la massa doveva vincere sul singolo. Ingenuamente.

Nel mio progetto “sogno” quindi le cose dovevano funzionare, ci credevo.
Gli utenti stringono tra loro relazioni di amicizia con quelli con cui desiderano giocare (ognuno a suo modo, secondo i propri criteri, la massima scelta liberale che potevo dar loro). Pensai che chi voleva giocare con soli “professionisti”, ad esempio, poteva circondarsi di amici di questo tipo. Idem per chi invece amava giocare divertendosi e non curandosi del tempo tra una giocata e l’altra.
Poi mi chiesi: ma come fanno ad estendere le proprie amicizie?
Se ognuno si chiudeva a riccio nel proprio “circolo di amicizie” il rischio era quello di tenere fuori nuovi giocatori potenzialmente compatibili con le esigenze di ognuno. Allora pensai al Tavolo. Il Tavolo da gioco è la nostra base, tutto parte da lì. I Member dovevano poter decidere se giocare con soli amici o con tutti gli altri. E feci anche questo enorme passo.

Pensavo…

Vuoi accrescere il tuo “parco” amici con nuovi giocatori “bravi” perchè quelli che hai sono pochi o ti stai stancando di giocare con loro? Rischi e ti metti in gioco. Fai Tavoli pubblici e ti apri ai Newbie (bianchi) e ai Player (azzurri). Rischi di trovare lo “scarso” o il “rompiballe” ma potresti anche trovare il “migliore giocatore di tressette” o il “più “simpatico”. Lo vuoi fare? Lo fai.
Non vuoi nemmeno metterti in gioco perchè non ne hai voglia? Perchè GDM per te è il momento libero e desideri giocare nell’unico modo che preferisci (professionisti, casinari, bordelli e bestemmie)? Bene, comunicherai al Tavolo con i tuoi amici nella speranza che almeno uno di loro si sia aperto al mondo e porti dentro almeno lui nuovi giocatori, aria fresca!
E poi… i tuoi amici non lo fanno? Bene, allora volete un circolo chiuso. Stringete le vostre amicizie e giocate solo tra amici. Chi vi dice nulla.

Appariva un disegno perfetto (anche se non amo quest’ultima parola).
Solo tra amici“. Mi piaceva.

E le esclusioni?

Sempre ingenuamente pensai che comunque gli utenti, al di là del Tavolo da gioco, dovessero avere uno strumento per isolare una persona (non saprei nemmeno come definirla!) diciamo disonesta. Scorretta, sleale, “malvagia”, giusto per usare alcuni sinonimi. C’era anche il problema che un Newbie, pagando, poteva saltare tutto il percorso di crescita ed entrare a piedi pari in Community, senza freni. E se questo era un disonesto (credetemi ce ne sono tanti che pagano anche solo per rompere)?

Le esclusioni erano una soluzione. Il popolo di GDM poteva escluderlo isolandolo dal resto della Community. Nella mia testa ipotizzavo un giocatore con 100 esclusioni subite: non aveva scampo. Non giocava più, non interagiva più. Completamente isolato. Ingenuamente ci credetti.

Pensavo…

Potresti utilizzare le amicizie e NON curarti nemmeno delle esclusioni! Chi è “capace” (o ti sta simpatico, o lo ami, a seconda del tuo modo di giocare) lo fai tuo amico, chi no lo ignori. Poi fai Tavoli con solo amici. Le strategie sono tante e l’intreccio delle relazioni vincerà su tutto.
E se proprio avete bisogno di uno strumento per paralizzare uno, per isolarlo e non vederlo più… beh, lo escludete in massa. Del resto un giocatore disonesto (o uno che entra solo per rompere) non piace a nessuno.

Solo tra amici“. Mi piaceva sempre più.
Era l’idea a monte quella vincente, non le esclusioni.

Pensavo…

E’ inutile che impegno energie per implementare l’esclusione reciproca perchè il singolo non può nulla contro la forza della Community. Il resto della Community lo massacrerà per tempo. E comunque se questo dovesse sentirsi attaccato ed inizia ad escludere lui tutti quanti beh… il risultato finale è lo stesso: si isola da solo. Alla fine è sempre il discorso di 1 contro 100. Se saranno compatti ce la faranno. Ne sono certo!

Lavorai sodo, 6 mesi di sviluppo. Un nuovo GDM fiammante.
Finalmente il progetto stava andando nella direzione giusta: dare potere alla Community in modo che questa possa difendersi autonomamente. Era il concetto a monte sul quale ragionavo da anni. Infatti è impensabile considerare che vi sia un’autorità garante dei diritti dei giocatori. Non è possibile. Sono troppe le variabili in gioco e poi questo prevedeva uno “schierarsi” da parte di myGDM che ho sempre odiato. Lo stesso Staff non può farcela, in un’ottica di crescita non resisterà.
La Community deve vincere da sola, con la propria forza. Ci riuscirà, pensai. Ce la farà.
Ma mi sbagliavo.

Il progetto ha visto la luce con decine di bug, risolti poi con immensi sacrifici e un grande lavoro di squadra dello Staff e tanti amici. Tutti per pura passione, non certo per lavoro!
Poi il declino, la delusione e l’abbattimento finale: la Community non esiste. Ognuno pensa a sè.

E’ inutile che vi racconti quale sia l’epilogo di questo capitolo di myGDM. Lo conoscete meglio di me!

Concludo dicendo che non abbiamo mai ascoltato il singolo ma sempre la voce della Community. La Community che non c’è più. Perdonerete myGDM quindi se in futuro Vi ascolterà un po’ meno e, soprattutto, se prenderà tempo prima di impegnare risorse inutilmente, sognando ad occhi aperti. Anche se …  “anche i sogni servono a diventare grandi” cantava qualcuno.

Tutorial per il Payment Gateway del Consorzio Triveneto SpA

e-commerce payment gateway

Lo sviluppo di un’applicativo e-commerce B2B per un cliente mi ha portato ad analizzare a fondo il Payment Gateway del Consorzio Triveneto S.p.A. Prima di iniziare mi complimento con il consorzio per aver redatto una documentazione molto precisa. Lo stesso gateway lo trovo veramente ben fatto ma su questo potrò darvi maggiori dettagli tra qualche mese, quando il cliente sarà in produzione.

Introduzione

In un’applicativo web-based di e-commerce solitamente le figure (sarebbe meglio parlare di macchine, PC, server, ecc.) con cui abbiamo a che fare sono tre:

  1. L’utente che acquista e che naviga il sito (definito Cardholder)
  2. Il negozio online: il server del sito di e-commerce (definito Merchant)
  3. Il Gateway per i pagamenti, in parole povere: il server che si occupa delle transazioni con carta di credito (denifito Payment Gateway, qui di seguito Gateway)

Dal punto di vista pratico quindi avremo il Cardholder che naviga il sito del Merchant ed esegue le sue operazioni di acquisto (ordini, carrello, ecc.). Una volta terminata la sessione di acquisti si dirige alla pagina del pagamento e qui entra in azione tutto quello che vedremo in questo Tutorial.

L’intero processo prevede comunicazioni tra le tre figure sopra elencate. Le comunicazioni tra Merchant e Gateway possono essere definite server-to-server, l’utente infatti non sempre interagisce con esse. I server si scambiano messaggi tra loro per ovvi motivi di sicurezza.

Sulla pagina del Merchant quindi deve essere predisposta una pagina che si occupa di inviare i dati (codice identificativo, importo da pagare, numero ordine, ecc.) al Gateway. Quando il Cardholder clicca sul famoso “Paga ora!” tali dati vengono inviati al server del Gateway che, dopo averli elaborati e controllati, restituisce una risposta al server del Merchant. In questo frangente il Cardholder resta in attesa davanti al pc!
Una volta ricevuta la risposta dal Gateway la nostra procedura (Merchant) elabora i dati ricevuti e decide se proseguire o meno. In caso di errori potrebbe visualizzare una pagina al Cardholder perchè qualcosa è andato storto, in caso sia tutto ok invece potrebbe direttamente redirezionare il Cardholder verso la HPP (pagina del Gateway su cui l’utente inserisce i dati della sua carta di credito).
Questa prima transazione (e relativo scambio di messaggi), nel modello predisposto dal Consorzio Triveneto, prende il nome di PaymentInit.

Il nostro utente (Cardholder) quindi, se i dati passati al Gateway sono congrui, viene redirezionato sulla HPP dove potrà inserire i dati della sua carta di credito. L’utente effettua quindi l’operazione compilando tutti i campi e poi dà l’invio.
Qui scattano nuovamente diverse comunicazioni prima di restituire l’esito al Cardholder.
Per prima cosa il Gateway deve interfacciarsi a sua volta ad altri server, quelli del Centro autorizzativo, e verificare la validità della carta, la disponibilità e quant’altro. Eseguita questa operazione ricontatta il Merchant riportando l’esito dell’operazione che, anche questa volta, può essere positivo o negativo. In base all’esito il server del Merchant restituisce un URL verso cui redirezionare il Cardholder. Il Gateway quindi si occupa poi di redirezionare il Cardholder sulla pagina dell’esito.
Questa seconda transazione (e relativo scambio di messaggi), nel modello predisposto dal Consorzio Triveneto, prende il nome di NotificationMessage.

Ora passiamo alla pratica, successivamente vedremo perchè il NotificationMessage è così importante dal punto di vista della sicurezza.

La Classe PgConsTriv

Ho implementato questa classe e l’ho rilasciata sotto licenza GNU Lesser General Public License su SourceForge.
Questa la pagina che ho predisposto per la documentazione tecnica per la classe PgConsTriv e qui link per il download dell’ultima release (PgConsTriv.zip).
Insieme alla classe trovate una cartella example, in cui risiedono i file di esempio che vedremo insieme in questo Tutorial, e il file di configurazione. In dettaglio:

  • PgConsTriv.php (classe)
  • PgConsTriv.inc.php (file di configurazione)
  • example/
    • paynow.php
      Pagina per predisposizione e invio del PaymentInit
    • responseURL.php
      Pagina per ricezione ed elaborazione del NotificationMessage
    • errorURL.php
      Pagina per esito negativo
    • goodURL.php
      Pagina per esito positivo
    • test_PG.php
      Form che invia POST per testare la pagina del Response URL

Prima di iniziare dovete configurare i parametri della classe presenti nel file PgConsTriv.inc.php

Il PaymentInit e l’inizio della transazione

Come dicevamo sopra, tutto ha inizio con l’invio da parte del Merchant del PaymentInit. Da questo riceveremo una prima risposta che ci fornirà:

  • In caso di esito positivo: l’indirizzo verso cui redirezionare il Cardholder e il PaymentID
  • In caso di esito negativo: una stringa con !ERROR! e relativa descrizione

Analizziamo ora il file paynow.php in dettaglio.

N.B.: Preferisco creare una pagina separata alla quale passo via GET l’id dell’ordine. Tramite questo recupero dal database tutti i dati necessari dell’ordine e avvio la procedura. In questo modo si ha una maggiore sicurezza perchè se, ad esempio, invio tutti i dati via POST o GET direttamente alla pagina l’utente “furbetto” potrebbe intercettarli e variarli.

Al paynow.php quindi arriva il mio id ordine ($idp), poi recupero i dati dal database e li sistemo in un array ($arRp).
A questo punto verifico i dati e decido se procedere o meno:

// VERIFICO se può accedere all'ordine
if( count($arRp) > 0 &&
$idp > 0 &&
isset($arRp["stato"]) &&
($arRp["stato"] == "NEW" || $arRp["stato"] == "PAYMENT_INIT" )
) {

N.B.: Nel mio ordine gestisco un campo stato. E’ lo stesso che poi andrò ad aggiornare tramite risposte del server del Gateway in base ai vari esiti e passaggi. In questo modo avrò sempre sotto controllo l’andamento dell’ordine.
Qui sopra, infatti, verifico che lo stato sia consono a ciò che sto per effettuare: il PaymentInit. Il mio ordine quindi deve essere o in stato Nuovo (NEW) o in PaymentInit. Questo secondo caso lo lascio passare perchè ipotizzo la situazione in cui l’utente clicca su “Paga ora!” e, dopo aver visualizzato la HPP del Gateway, chiude il browser.

A questo punto siamo pronti per inviare il PaymentInit che altro non è che l’invio di una serie di dati via POST ad un indirizzo specifico. Creando un’istanza della classe andremo ad inserire i soli dati che potranno variare da ordine ad ordine mentre tutti gli altri dati saranno gestiti dalla classe stessa.
Vediamo ora l’istanza della classe e la preparazione del PaymentInit con l’invio dei dati al Gateway.

// init PgConsTriv Class
$pg = new PgConsTriv($lng);
$pg->setAction('Purchase');
$pg->setSecurityCode_PI( $secCode );
$pg->sendVal_PI($importo, $idp);

Per istanziare la classe devo passare il parametro della lingua ($lng). Tale parametro è opzionale e nel caso non venga passato la classe utilizzerà la lingua di default settata nel file di configurazione. Per maggiori dettagli leggi il Tutorial multi lingua.
Il metodo setAction imposta l’Action. Purchase si occupa di eseguire direttamente l’accredito dell’importo (vedi documentazione del Gateway, Appendice A).

Veniamo ora al discorso sicurezza e il parametro SecurityCode.

N.B.: Nella documentazione del Consorzio (pag. 23) si raccomanda di verificare sempre l’autenticità del NotificationMessage. Una delle soluzioni proposte è quella di inviare via PaymentInit un valore che il Cardholder non vede e non può conoscere. Lo stesso valore verrà poi restituito al Merchant successivamente attraverso il NotificationMessage. In questo modo potremo verificare il dato ricostruendolo e confrontandolo con quello passato dal NotificationMessage.

Impostiamo quindi il nostro SecurityCode ($secCode). Per generare un codice univoco potreste crearvi una stringa criptando in md5 alcuni dati presenti nel database (es: data ordine, idordine, importo, ecc.). In questo modo, successivamente, all’arrivo del NotificationMessage sarete in grado di ricostruirla con la stessa logica e verificarla con quella che vi verrà passata dal Gateway.

A questo punto punto siamo pronti per inviare il PaymentInit. Il metodo sendVal_PI riceve 2 valori:

  • $importo – Importo della transazione
  • $idp – Denominato trackid nella Documentazione del Gateway e deve essere un id univoco dell’ordine

Il metodo sendVal_PI invia i dati al Gateway e ne elabora la risposta.
Ora vediamo come gestire tale risposta:

// Verifico esito del PaymentInit
if( $pg->hasError_PI() )
{
// SEGNALAZIONE ERRORE!
echo "<h1>ERRORE: ".$pg->getError_PI()."</h1>";
} else {
// Registro il PaymentID nel database e invio l'utente alla HPP del Gateway
mysql_query("UPDATE ordini SET .... ....");
header("Location: " . $pg->getPaymentURL_PI() );
}

Il metodo hasError_PI ci restituisce true se si sono verificati errori, in tal caso l’errore lo possiamo recuperare con il metodo getError_PI.
In caso di esito positivo recuperiamo i dati con:

  • getID_PI – PaymentID generato dal Gateway
  • getPaymentURL_PI – URL della HPP

Redirezionando l’utente verso la HPP del Gateway abbiamo concluso le operazioni del PaymentInit. Il Cardholder (utente) caricherà tale pagina e potrà inserire i dati della sua carta di credito. Solo dopo che avrà dato l’invio sulla HPP il Gateway ci contatterà per inviarci il NotificationMessage.

Il NotificationMessage e la chiusura della transazione

Nel momento in cui l’utente invia i dati della sua carta di credito al Gateway questo, dopo averli controllati presso il Centro Autorizzativo, contatta il server del Merchant inviando il NotificationMessage. Il Merchant risponde con un stringa che include l’indirizzo verso cui redirezionare il Cardholder.
La pagina di esempio che si occupa di tutto ciò è responseURL.php.

La prima operazione è creare una nuova istanza della classe per poi passargli i dati ricevuti via POST.

// init PgConsTriv Class
$pg = new PgConsTriv($lng);
$pg->setAction('Purchase');
$pg->setVal_NM($_POST);

setVal_NM si occupa appunto di registrare tutti i dati nella classe.
A questo punto iniziamo i nostri controlli per verificare la validità dei dati ricevuti.

// get paymentid
$paymentid = $pg->getPaymentID_NM();
// Verifico se esiste il PaymentID
if( $paymentid !== false ){
// Recupero Ordine dal database in base al PaymentID settato in fase di PaymentInit

Nel caso in cui qualcosa fosse andato storto o il PaymentID non risulta correttamente impostato il valore restituito da getPaymentID_NM è false. Lo verifichiamo e proseguiamo.
A questo punto posso recuperare i dati dell’ordine agganciando il PaymentID che mi ero registrato nel database in fase di PaymentInit. Recuperando i dati dal DB posso generare nuovamente il SecurityCode e verificarlo:

// set Security Code per verifica validità del Notification Message
$pg->setSecurityCode_PI( $secCode );
// Verifico autenticità del NotificationMessage
if( $pg->isValid_NM() ) {

Il metodo isValid_NM si occupa della verifica del SecurityCode. Controlla quello passato dal metodo setSecurityCode_PI con quello appena ricevuto dai dati POST.
Una volta superata questa verifica i nostri dati sono stati validati e possiamo ora procedere alla verifica dell’esito della transazione.
Nel caso abbia avuto esisto positivo avremo:

# Transazione Elaborata
if( $pg->isTransGood_NM() &&
$arRp["stato"] == "PAYMENT_INIT" &&
$pg->getVal_NM("trackid") == $idp // Verifico idp
) {
// OK, Registro STATO e dati TRANSAZIONE nel DB
$stato = $pg->getVal_NM("result");
$TranID = $pg->getVal_NM("tranid");
$Auth = $pg->getVal_NM("auth");
mysql_query("UPDATE .... SET ....");
// Verifico se elaborare l'ordine o meno a seconda del campo result

Per prima cosa verifichiamo con isTransGood_NM l’esito positivo della transazione. Poi (vedi documentazione del Gateway a pag.18) controlliamo che effettivamente sia il primo NotificationMessage che riceviamo. Potrebbero verificarsi dei casi in cui ne vengono inviati anche più di uno. La documentazione a riguardo dice di considerare attendibile sempre e solo il primo. Noi quindi, verificando lo stato, ci assicuriamo di ciò (lo stato infatti viene poi modificato e il secondo eventuale NotificationMessage non passa). Superati questi controlli possiamo prelevare i dati con il metodo getVal_NM (vedi documentazione del Gateway per elenco dei campi disponibili).

Attenzione: fino ad ora abbiamo parlato di esito della transazione. Parliamo in termini di elaborazione effettuata e non di effettivo accredito dell’importo prelevato dalla carta di credito (esito dell’acquisto). Per questo esistono altri metodi che controllano il campo result dei dati inviati tramite NotificationMessage.
I metodi sono diversi in base al valore che il campo result può assumere:

  • isCaptured_NM()
  • isNotCaptured_NM()
  • isApproved_NM()
  • isNotApproved_NM()
  • isDeniedByRisk_NM()
  • isHostTimeout_NM()

Nel nostro caso (Action = Purchase) il valore che corrisponde all’effettivo accredito dell’importo è “CAPTURED”.

Nel caso in cui la transazione invece dovesse avere esito negativo la funzione isTransError_NM restituisce true e noi possiamo procedere alla registrazione dell’errore nel DB:

# Transazione NON Elaborata a causa di errori tecnici
if( $pg->isTransError_NM() ) {
// ERROR, Registro Errore nel DB

Anche in questo caso registro comunque lo stato ERROR nel campo del mio ordine (questo per quanto spiegato sopra sul discorso di un eventuale doppio NotificationMessage) e anche l’eventuale errore recuperato con getVal_NM(“ErrorText”).
A questo punto non resta che comunicare al Gateway l’URL verso cui deve redirezionare il Cardholder:

// Restituisco al Gateway l'URL su cui redirezionare il Cardholder
echo "REDIRECT=". $pg->getURL_NM();

Il metodo getURL_NM restituisce il goodURL o errorURL a seconda che l’esito della transazione sia positivo o negativo. Esso considera inoltre, in base all’action impostato, anche l’esito dell’acquisto (accredito importo).

A questo punto si concludono anche le operazioni del NotificationMessage.
Resta un’ultima considerazione da fare come ben rappresentanto nella documentazione del Gateway (pag. 23).

Se il NotificationMessage non viene eseguito regolarmente

Cosa accade se, ad esempio, il Gateway invia il messaggio ma per qualsiasi motivo il server del Merchant non lo riceve?
In questo caso, sia che la transazione abbia esito positivo, sia negativo, il Gateway reindirizza il Cardholder verso la pagina ErrorURL. In questo caso l’utente vede esisto negativo mentre la transazione magari è andata a buon fine e, ad esempio, anche l’esito dell’acquisto è positivo (con tanto di accredito dell’importo).
Come da documentazione:

E’ quindi importante che il Merchant prepari l’ErrorURL in modo tale da ricavare informazioni utili per poter investigare l’accaduto e informare successivamente il Cardholder sull’esito dell’acquisto.

– –

Bene, siamo giunti alla fine del Tutorial.
Spero di implementare presto anche la tipologia di messaggio Payment (per operazioni in differita tra Merchant e Gateway, es: storno, riaccredito, ecc.).

Nel frattempo spero che questo Tutorial sia risultato chiaro e utile.
Buon lavoro! 🙂