$var) { $var = urlencode(stripslashes($var)); $resp .= "&$parm=$var"; } // STEP 3 - Extract the data PayPal IPN has sent us, into local variables $item_name = $_POST['item_name']; $item_number = $_POST['item_number']; $payment_status = $_POST['payment_status']; $payment_amount = $_POST['mc_gross']; $payment_currency = $_POST['mc_currency']; $txn_id = $_POST['txn_id']; $receiver_email = $_POST['receiver_email']; $payer_email = $_POST['payer_email']; $record_id = $_POST['custom']; // Right.. we've pre-pended "cmd=_notify-validate" to the same data that PayPal sent us (I've just shown some of the data PayPal gives us. A complete list // is on their developer site. Now we need to send it back to PayPal via HTTP. To do that, we create a file with the right HTTP headers followed by // the data block we just createdand then send the whole bally lot back to PayPal using fsockopen // STEP 4 - Get the HTTP header into a variable and send back the data we received so that PayPal can confirm it's genuine $httphead = "POST /cgi-bin/webscr HTTP/1.0\r\n"; $httphead .= "Content-Type: application/x-www-form-urlencoded\r\n"; $httphead .= "Content-Length: " . strlen($resp) . "\r\n\r\n"; // Now create a ="file handle" for writing to a URL to paypal.com on Port 443 (the IPN port) $errno =''; $errstr=''; $fh = fsockopen ('ssl://www.paypal.com', 443, $errno, $errstr, 30); // STEP 5 - Nearly done. Now send the data back to PayPal so it can tell us if the IPN notification was genuine if (!$fh) { // Uh oh. This means that we have not been able to get thru to the PayPal server. It's an HTTP failure // // You need to handle this here according to your preferred business logic. An email, a log message, a trip to the pub.. } // Connection opened, so spit back the response and get PayPal's view whether it was an authentic notification else { fputs ($fh, $httphead . $resp); while (!feof($fh)) { $readresp = fgets ($fh, 1024); if (strcmp ($readresp, "VERIFIED") == 0) { // Hurrah. Payment notification was both genuine and verified // // Now this is where we record a record such that when our client gets returned to our success.php page (which might be momentarily // (remember, PayPal tries to stall users for 10 seconds after purchase so the IPN gets through first) or much later, we can see if the // payment completed; and if it did, we can release the download. You can go about this synchronisation between listener.php // and success.php in many different ways. How you do it mostly depends on your need for security; but here is one way I do it: // // When the client initiates the purchase by clicking the "buy" button, I write a new "unconfirmed" payment record in my Payments // table; this includes all the details of what they wish to purchase and their session-ID. I then pass the record "id" of this pending entry in the CUSTOM // parameter to PayPal when it processes my site visitor tranaction. // // After PayPal processes the transation, it doesn't return the client to your site immediately; it conveniently stalls them for around // 10 seconds, during which it quickly calls your listener program (this program) to give it the good news. I then extract the record_id // that was inserted in the Payments table database that was created just before the client was sent to PayPal, but now I know that // the payment is VERIFIED, so I can update the record in the PAYMENTS table from "Pending" to "Completed". // // When (or if) the user returns to my "Auto Return" success.php page, I query the database for all "Completed" transactions with the // same Session_id, read the digital products that they have purchased and then release them as downloadable links in // success.php. // // Yes, session_id is not totally reliable, but you could use cookies, or you could use a comprehensive user // registration, logon & password retrieval system that would give you the degree of "lock down" you require. Your choice. // } else if (strcmp ($readresp, "INVALID") == 0) { // Man alive! A hacking attempt? } } fclose ($fh); } // // // STEP 6 - Pour yourself a cold one. // // ?>