Paypal IPN not working, a possible reason....a possible answer...

[idrisenoch]

I haven't tried this yet but though I'd share it. Wish I would have seen this two days ago...:/

It's from the paypal developer forums here...

http://www.pdncommunity.com/pdn/board/message?board.id=sandbox&view=by_date_ascending&message.id=9802#M9802


enspaceman
Visitor
Posts: 4
Registered: 06-04-2008


It sounds like to me, there is possibly a $_GET, or $_POST problem you are having. If your IPN receiving page is setup for $_POSTs then make sure that in your button code (that starts the PayPal purchase process) has <input type="hidden" name="rm" value="2"> listed. Otherwise PayPal's IPN will just send you everything to your IPN receiving page as a $_GET, and if your IPN receiving page is setup for $_POST, then nothing will happen. It will seem like IPN isn't working. Also NOTE: that as of today still, the normal sandbox IPN isn't sending back 'verified' on the normal port 80 (due to sandbox upgrades going on), but there is a temp solution that user: skyraider found and it works...

here it is:

this is skyraiders post below:

Ok, I have fond a solution that works.

For your headers, use:

$header = "POST /cgi-bin/webscr HTTP/1.1\r\n";
$header .= "Host: www.sandbox.paypal.com\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: " . strlen($req) . "\r\n\r\n";

then . . .

$fp = fsockopen ('ssl://www.sandbox.paypal.com&#039;,"443",$errno,$errstr,30);

The above code is what I had to modify to make my script fit with some changes that have apparently occured on the PayPal system.

[idrisenoch]

Update: In another script I was testing (Moodle) I made the changes to the $header and the $fp variables and it does indeed work (for now - 14 June 2008). From what I can gather at the Paypal Developer Forums this is something that has been going on for a couple of months with port 80 requests and no indication when that may change.

[idrisenoch]

Well, so far I cannot get the above incorporated into VM....

www.eliteweaver.co.uk is dead...the entire domain is MIA...so there's no way to debug that I see...

If I knew how to code...that might help...LOL

So far I've tried just replacing the $fp with;
$fp = fsockopen ('ssl://www.sandbox.paypal.com&#039;,"443",$errno,$errstr,30);

Still fails.

I'm wondering about this bit here;
$header .= "Content-Length: " . strlen($req) . "\r\n\r\n";

VM has;

$header .= "Content-Length: " . strlen($workstring) . "\r\n\r\n";

I swapped those also, no luck.

Any ideas?

[idrisenoch]

OK...when I had a default install over the last couple of days, after changing $url = "https://www.sandbox.paypal.com/cgi-bin/webscr"; in extrainfo....I tried every conceivable combination of Order Status settings I could...

What I  noticed then was that if Order Status for confirmed Payments was set to anything *but* Pending it would generate the FAILED message upon returning from Paypal...Order Status for pending Payments made no difference what it was set to, including Confirmed...

After finding out the info at the top of this thread and changing the $fp variable to $fp = fsockopen ('ssl://www.sandbox.paypal.com&#039;,"443",$errno,$errstr,30); ...in addition to changing the pointer in extrainfo *and* going into the sandbox "business" account under Profile>Language>More Options and changing the defaults to UTF-8....I can now at least change Order Status for confirmed Payments to Confirmed without it generating the FAILED message.

It says Success....but the order is marked pending in the control panel Orders...

I still have to mark notify client, change status to Confirmed, and update status to initiate the email with the download link....

This change seems to indicate that now VM is getting the response from Paypal...but I have no idea what that response is because the debug link is gone.

I can live with this for now but I do want automated downloads at some point without resorting to another script just for that purpose.

Any ideas?

[idrisenoch]

p.s. Using Joomla 1.5.3 and VM 1.1

[aravot]

PayPal should work in live mode, sandbox is down.

[idrisenoch]

Actually I just used the sandbox successfully usinmg the moodle.org paypal module and making the above changes...using port 443.

As the Paypal Dev forum post indicats...port 80, as you say, is "down", in that it is not returning a "verified" response under any circumstances...

However, port 443 *is* returning "verified" responses.

So we are both correct in a manner of speaking.

I just have not been able to make the changes to the $header and $fp variable work with Virtuemart, but it *does* work with other projects' paypal modules...

But I'm glad to hear that Virtuemart *is* working in livemode...thnaks!

[blanchg]

The reason it isn't sending back verified is because it is sending a temporary redirect to 443.  This is why the above patch also works.

When you are having problems with paypal edit notify.php and add


    error_log($msg);

at the end of the debug_msg function.  You will then be able to see why the notification is failing usually in a file called error_log in the /adminisrator/components/com_virtuemart directory.

[idrisenoch]

Thanks for the tip!...I really did want to see the messages being returned but couldn't figure that out...