Jump to content

PayPal Instant Payment Notification, listener script


data888

Recommended Posts

Will try keep description of issue to less than 500 pages... :)

 

After a customer makes a payment using PayPal standard (note: user may add single or multiple items to cart & checkout), I need to capture/retrieve certain transaction details which would then be used to authenticate the user and display content based on their order. So there could be multiple items associated with a particular transaction.

 

When user supplies an email address during order process (along with other info), I need to retrieve the value of the email variable,  item name, user address etc., through the instant payment messaging service while simultaneously writing the info to database and emailing user for their records.

 

Note: Emailing user or writing variable data to database is not the issue but actually capturing/retieving the transaction data from PayPal.

 

Aparently PayPal offers something called 'Instant Payment Notification'. So the developer can place a call in code to PayPal to have transaction data sent to a page (notify_url) as a string of some sort, which you can then split to store into separate variables.

 

Problem, none of the integration code either by PayPal or others that I have seen, seem to function properly. It simply displays a blank page on the page where data should be displayed.

 

Does  anyone have a version of the 'listener' script that performs the stated function and actually displays the transaction info?

 

This is supposed to be an example of a similar code: https://www.geekality.net/2011/05/28/php-tutorial-paypal-instant-payment-notification-ipn/

Link to comment
Share on other sites

PayPal will call the script, not you. You cannot test it yourself directly - you need to use their testing tool (which is somewhere) while still in the sandbox environment, or by going through your checkout process and creating a "real" transaction. The script verifies the request and does whatever it wants, and since output is pointless (you can't see it) logging to a file or database is the next best option.

 

That thing you linked to looks reasonable enough.

Link to comment
Share on other sites

PayPal will call the script, not you. You cannot test it yourself directly - you need to use their testing tool (which is somewhere) while still in the sandbox environment, or by going through your checkout process and creating a "real" transaction. The script verifies the request and does whatever it wants, and since output is pointless (you can't see it) logging to a file or database is the next best option.

 

That thing you linked to looks reasonable enough.

Perhaps there is a misunderstanding.

 

I do not have an issue testing functionality of payment process using sandbox or live environment. Currently user is routed to whatever page is specified in PayPal after PayPal processes payment but process is not completed after user makes a payment.

 

The goal here is not to simply get a response from PayPal that transaction was processed but to have PayPal "pass" back certain transaction detail (user and transaction variables)  in real time for further processing.

 

We can technically manually log into PayPal and manually review each transaction to gather transaction details to figure out how to configure each customer account so they can have correct access when they log in but that would be technically unwise.

 

Rather, actual capture and display of user and transaction detail/variables is required after customer's payment has been processed and received.

 

Think of it this way.... what is required is something similar to having the ability to store transaction details in a globally accessible session variable and being able to access the session variable after receipt of payment has been made and received

 

$_SESSION['user_email'];

$_SESSION['user_password']; //not paypal password but password on our site

$_SESSION['order_date'];

$_SESSION['item_name1'];

$_SESSION['item_name2'];

 

etc...

 

The current process with PayPal is to collect the information, process payment and then route the user to a page you specify. That is not enough. I need to retrieve same info in real time from PayPal for further processing. Manually combing through transaction records to figure who ordered what and when just isn't an option. :anim_reading:

Link to comment
Share on other sites

The goal here is not to simply get a response from PayPal that transaction was processed but to have PayPal "pass" back certain transaction detail (user and transaction variables)  in real time for further processing.

That's exactly what IPN does. Have you looked in $_POST? There's a lot of data in there.

 

I always recommend to people implementing IPN support to log the message and all $_POST data to a database. Having historical records can be very helpful, not just for research and troubleshooting but for administrative needs too.

 

The current process with PayPal is to collect the information, process payment and then route the user to a page you specify. That is not enough.

Then IPN is not the answer. For one it's asynchronous, and while a confirmation message will likely come within a couple seconds after the transaction, you can't rely on that being the case. For two, any session used on the receiving page will be with the PayPal server (not that they keep the cookie) so sessions aren't helpful.

 

But I'm skeptical that you need the information immediately. What kind of "further processing" do you need to do?

Link to comment
Share on other sites

data888, PayPal IPN does exactly that (used it for many years). If you can't process sale information in your callback file, it means there's a problem with your code.

 

First of all, you should capture $_POST data on your script and save it (just write it to a text file using fwrite) for further review. If you see data is there, you can continue debugging your script further. If $_POST data is empty, it means either the URL you configured PayPal to send callbacks to is invalid (in other words, double-check the URL), either your server can't process callbacks for some reason (for example, maybe you have some mod_security rule which blocks such a request).

 

However, I'm not very sure about this part:

It simply displays a blank page on the page where data should be displayed

 

 

 

What do you mean? PayPal doesn't display any IPN data, it just sends this data to your server, and it's up to you to decide how data will be used.

Link to comment
Share on other sites

data888, PayPal IPN does exactly that (used it for many years). If you can't process sale information in your callback file, it means there's a problem with your code.

 

First of all, you should capture $_POST data on your script and save it (just write it to a text file using fwrite) for further review. If you see data is there, you can continue debugging your script further. If $_POST data is empty, it means either the URL you configured PayPal to send callbacks to is invalid (in other words, double-check the URL), either your server can't process callbacks for some reason (for example, maybe you have some mod_security rule which blocks such a request).

 

However, I'm not very sure about this part:

 

 

What do you mean? PayPal doesn't display any IPN data, it just sends this data to your server, and it's up to you to decide how data will be used.

There was an issue with the code.. apparently you need to specify the 'return method' initially when passing the data to PayPal for processing -- it wasn't. So it appears PayPal got confused when told to POST the transaction string in code.

 

Currently it displays a string of data that covers entire page. Apparently it is trying to display all of last 28 transactions in a single string?

 

How did you implement exporting the sting to a test file? That might be a start to getting the transaction details it in a database on the server.

Link to comment
Share on other sites

Are you sure? You do not pass data to PayPal, PayPal posts data to you.

Finally got this a few days ago. Good grief...it turns out 95% of the code posted in most of the forums regarding this is absolutely not required to get the job done.

 

The process we are using requires the buyer to fill out a form to provide certain basic information:

Name, login, password, address etc... before hitting the paypal site to process payment. You essentially have to use the paypal 'custom' variable to store all non paypal variables as a large string which you then retrieve and explode into separate variables when the buyer is routed back to our site.

 

Also, all along the actual PayPal data/variables I was initially trying to retrieve was always there to be retrieved by using POST[];

Link to comment
Share on other sites

That's exactly what IPN does. Have you looked in $_POST? There's a lot of data in there.

 

I always recommend to people implementing IPN support to log the message and all $_POST data to a database. Having historical records can be very helpful, not just for research and troubleshooting but for administrative needs too.

 

Then IPN is not the answer. For one it's asynchronous, and while a confirmation message will likely come within a couple seconds after the transaction, you can't rely on that being the case. For two, any session used on the receiving page will be with the PayPal server (not that they keep the cookie) so sessions aren't helpful.

 

But I'm skeptical that you need the information immediately. What kind of "further processing" do you need to do?

I did find all the data is typically returned as a very large string...I currently can post and assign to variables to store to database. It is a useful messaging service because we can choose to only write data to database if we get confirmation the payment process is actually complete or that user is verified etc. tons of information.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.