Esplora E-book
Categorie
Esplora Audiolibri
Categorie
Esplora Riviste
Categorie
Esplora Documenti
Categorie
Nel frattempo esegui alcuni pagamenti di prova ed assicurati che l'utente venga
inserito nel database e che il pagamento risulti effettivamente nell'account di
simulazione.
Se tutto risulta corretto, siamo già a buon punto. Ma non significa che non vi
siano errori.
mysql_query($sql, $this->conn);Array
if(mysql_num_rows($res))Array {Array return
FALSE;Array }Arrayreturn TRUE;Array}Array
Cosa abbiamo fatto? Semplice abbiamo tolto gli apici a $_POST[tnx_id] nella query,
ma l'id della transazione è una stringa; questo solleverà un errore di livello
warning.
Se proviamo a fare un pagamento con questa modifica, la procedura va a buon fine,
perchè?
• L' esecuzione della query produrrà una risorsa non valida quindi
$res sarà FALSE
• mysql_num_rows(FALSE) ritornerà FALSE
• Quindi isNotProcessed ritornerà sempre TRUE
• Di conseguenza isNotProcessed non controllerà un bel niente
La prima cosa da fare, una volta che avremo eseguito alcuni pagamenti di test, è
andare a leggere il log degli errori del webserver (ti consiglio di farlo periodicamente
a prescindere dall'argomento contingente, è incredibile quante cose si possono
scoprire). Dove venga salvato questo log dipende molto dal tipo e dall'impostazione
del server, comunque generalmente si trova in /var/log/httpd/. Nel file "error_log"
vengono salvati tutti gli errori di qualsiasi livello sollevati da PHP.
Ora, se hai fatto un pagamento con il metodo isNotProcessed modificato, questo file
conterrà una riga simile a questa:
Dunque, dopo alcuni pagamenti di test, il file error_log non deve contenere
nessun errore sollevato dal listener (nemmeno un notice!).
isVerifiedIPN
Per controllare l'effettivo funzionamento di questo metodo, non dobbiamo fare altro
che inviare dei dati con il metodo POST al listener. Per fare questo, basterà un
semplice form che punta alla pagina YIIListener.php:
Array<form action="http://www.sito.com/Test/YIIListener.php"
method="POST">Array <input type="hidden" value="50.00"
/>Array <input type="hidden"
value="utente_1284367085_per%40bluewin.ch" name="payer_email"
/>Array <input type="hidden" value="Maurizio" />Array
<input type="hidden" value="Tarchini" />Array <input
type="hidden" value="2S978310JP2093304" name="txn_id" />Array
<input type="submit" value="invia" />Array</form>Array
isVerifiedAmmount
Per la verifica del funzionamento di questo controllo, basterà modificare il parametro
AMMOUNT nel file di configurazione. AMMOUNT contiene il valore del pagamento
che ci aspettiamo (50.00).
La verifica non andrà a buon fine in quanto la notifica contiene 50.00 e AMMOUNT
ora contiene un altro valore.
Nessun utente dovrà essere aggiunto al database.
isPrimaryPayPalEmail
Per la verifica del funzionamento di questo controllo, basterà modificare il parametro
PRIMARY_SANDBOX_EMAIL nel file di configurazione. In questo modo l'email
inviato nella notifica da PayPal risulterà diverso da quello che ci attendiamo, dunque
la verifica non andrà a buon fine
Nessun utente dovrà essere aggiunto al database.
isCompleted
Per verificare il corretto funzionamento di questo controllo, logghiamoci su Sandbox.
E ora, nella colonna Payment Review clicca su disabled per rendere questa
Pagina 4 di 5
Alla fine di questa serie di controlli, verifica ancora una volta il file error_log che
come detto non deve contenere nessun errore sollevato dal listener.
Conclusione
In questa serie di articoli abbiamo visto nei dettagli come procedere all'elaborazione
di un pagamento online allo scopo di concedere un instant access.
A questo punto la materia non avrà più segreti per te. Quindi nel prossimo articolo
svilupperemo un e-commerce completo (scherzavo).
Nel prossimo articolo vedremo come implementare un bottone di pagamento
dinamicamente, quindi senza utilizzare il comodo ma limitato sistema che abbiamo
visto.
1. Preparazione
2. Chiarirsi le idee
3. Le procedure generali
4. Le procedure specifiche
5. Testare l'applicazione
6. Creare dinamicamente i pulsanti di pagamento