Symphony.

Who’s to blame? Three possibilities:

1. Me
2. PayPal
3. the extension

Stupid joke. Anyhow ;)

I am encountering a weird out-of-the-blue issue. I set up the PayPal Payments extension on a site I’m working on, and all was good. IPNs were being logged and entries reconciled. Great.
Now, today, I test a purchase as I always did:

• On submit, the entry gets saved in my “Orders” section
• I get redirected to PayPal’s sandbox, send the payment
• No log gets saved, no reconciling in the “Orders” section.

Now, here’s what I checked before dumping my desperation on fellow Symphonians:

First, I thought maybe PyPal is not sending the invoice number, but in my test seller account, under History -> IPN History, I see that all IPNs were sent to the right page, with the listener event attached. Status codes are all 200. Invoice IDs are being sent along…
What gives?

Then I tried with the IPN Simulator (manually entering an invoice number corresponding to some un-reconciled entry in “Orders”). Same thing; the simulator gives a “Successful” result, but nothing on my end.

Then the last thing I tried was to copy one the IPN responses from PayPal’s IPN History, and manually build a form to POST all the values, one per <input />, to my /ipn/ URL. This time with <form action="?debug"> in the hope of seeing something.
Nada; the XML I get is this:

<?xml version="1.0" encoding="utf-8" ?>
<data>
    <events />
</data>

Any ideas? In the extension’s Listener event description there is mention that:

All data returned from PayPal is included as the <paypal-payments-ipn> node in the XML output for use in frontend pages.

No idea how to see it to debug less blindly, since it’s being called by PayPal…

Could it be that PayPal suddenly changed their IPN response? This is what they say they are sending me:

mc_gross=320.00
invoice=286
protection_eligibility=Ineligible
address_status=confirmed
payer_id=HK7EYFHJSCKTS
tax=0.00
address_street=1 Main Terrace
payment_date=09:28:02 Nov 11, 2010 PST
payment_status=Pending
charset=windows-1252
address_zip=W12 4LQ
first_name=Test
mc_fee=11.08
address_country_code=GB
address_name=Test User
notify_version=3.0
custom=
payer_status=unverified
business=seller_1283858474_biz@gmail.com
address_country=United Kingdom
address_city=Wolverhampton
quantity=1
verify_sign=AFcWxV21C7fd0v3bYYYRCpSSRl31AW3umolaPJk38jSzNGlpFSbilYn.
payer_email=tommas_1287950376_per@gmail.com
txn_id=67W19399S0551403Y
payment_type=instant
last_name=User
address_state=West Midlands
receiver_email=seller_1283858474_biz@gmail.com
payment_fee=
receiver_id=SJ3R5BJZ67DFA
pending_reason=paymentreview
txn_type=web_accept
item_name=Janissary Black and Natural
mc_currency=GBP
item_number=BD001-BN
residence_country=GB
test_ipn=1
handling_amount=0.00
transaction_subject=Janissary Black and Natural
payment_gross=
shipping=0.00

Any help, of any kind will be massively appreciated.

You could try editing the PayPal event to do the following at line 28

var_dump($_POST);

That will tell you whether the data is at least getting to the extension, if nothing happens then the event isn’t even being fired, so then it may be something at PayPal’s end, or the data is being lost somewhere… :s

Not meaning to offend, but is the event still attached to the page?

To be honest, this sounds more like a PayPal thing as things don’t tend to just stop working, unless the source (in this case PayPal) has issues or changes things… The verify_sign parameter is being sent, so should arrive as planned…

Not meaning to offend

Too late, I am deeply offended ;)

Yup the event is still attached to the page.
I did the var_dump($_POST); change in event.paypal_payments_ipn.php. When I send my self-made form (mentioned in my first post), I get the full array of variables, but that’s because I am posting to that page directly, and obviously see the result…
But, how do I see whether the /ipn/ page is receiving them when PayPal posts to that URL? Should I write var_dump() to a file?

So, I tried with:

$myFile = "/home/.../testFile.txt";
$fh = fopen($myFile, 'w');
$stringData = $_POST['invoice'];
fwrite($fh, $stringData);
fclose($fh);

And the invoice is coming back fine and dandy from PayPal.
So what’s to check next? The VERIFIED confirmation after curl?

(sorry for this monologue by the way)

Tried this inside load():

$url = $this->_driver->_build_paypay_url();
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_FAILONERROR, 1); 
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_TIMEOUT, 3);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $req);
$result = curl_exec($ch);
curl_close($ch);

// MY DUMPS HERE

var_dump($_POST);

$myFile2 = "/home/.../testFile2.txt";
$fh2 = fopen($myFile2, 'w');
$stringData2 = $result;
fwrite($fh2, $stringData2);
fclose($fh2);

And unless $result is not a string, then I’m not getting anything back. What could it be? A crappy curl issue? Any extra pointers?

UPDATE

I find hard to believe, but $result is empty after $result = curl_exec($ch) when it should say “VERIFIED” istead. If this is not PayPal’s fault, I think I ran out of debugging options here.

@designermonkey anything magic in your hat?

@tmslnz: I’m away from my computer for the weekend, so can’t offer much help. You’re on the right track with logging the response out to a file, easiest way to confirm what’s going on. It’s pretty odd that things have just stopped working, has something changed on the server that you mightn’t have done?

I would have thought that var dumping an event would just break Symphony with, probably, a headers error and all the data displayed on screen.

Anyhoo…

Hmmm.

I’d go through this step by step…

1. Dump out the $req variable at line 46 using var_dump, check it contains data.
2. If so, dump out the $ch variable at line 57 using var_dump, check it contains data.
3. Then dump out the $result variable.

If there is data in $req, not $ch, then there’s a curl issue.

I wish I could do this, but I haven’t got a PayPal site setup yet, it’s still in planning…

Thanks a lot for the suggestions. I’ve been enjoying some dinner and a movie with a friend, blaming PayPal and feeling better ;)

@designermonkey:

• point 1 I tried already, the $req is well formed.
• point 2 I did something different: I used an if ($ch == FALSE) $ccurl = "FAIL" which wasn’t triggered, hence I assumed Curl goodness. I didn’t test $ch content tho’. Will do.
• point 3 I tried, and $result is empty, but it might be bec of point 2 silent failure

Commenting out the check for $result == "VERIFIED", everything works. IPNs are logged and all is back to normal.

(for the record, all of this is happening in event.paypal_payments_ipn.php)

I’ll make more tests tomorrow. However, a little background before bed:

The Curl Case

I switched to a Linode VPS with Ubuntu 10.10. I am also running Nginx and PHP-FPM (with a backup Apache for some older stuff). Oddly enough it all seems to work fairly well.
However two days ago I tested a purchase, and bang: no worky. Going through the logs, I find out I had forgotten to install php5-curl. I install it, try again, and IPN gets logged fine, thank you page is displayed, etc.

Then today, I pick it up again to wrap it up, and here we are. This time it’s broken, but no tears in the logs (not in Apache’s, php’s or Nginx’s).

This said, I don’t think this setup is to blame, as it did work fine at some point.

Moreover PayPal Sandbox was being really shitty today, super slow and throwing errors all over the place on their end. Didn’t feel solid. Not that it ever does, but this time was really bad.

Sounds like it may be a PayPal thing then.

I’ve had issues with the sandbox before, it took me 20 attempts to even make a test account!

I hope it all works ok in the end.

Indeed it was. I hate them, deeply and sincerely. Wasted nearly a day on a non-issue.

Big thanks for the help anyway, I did learn a couple of things.

Hah! They can be a bit annoying.

I may try something similar for Google Checkout…

I found that installing php-curl solved my problems getting the Paypal IPN Simulator to work.

I seem quite close to getting this working on 2.2. I am trying to use the extension for the IPN bit only. The IPN page has the Paypal event attached and it seems to be accepting the IPN messages from Paypal as I get success messages in my IPN history.

I am doing £1 transactions with my live company and personal accounts to test this, so its not a sandbox issue.

On checking the IPN message I can see that verify_sign and invoice values are both being posted to the page, and the invoice value corresponds with the id of the record in the order section.

Although Paypal shows success for the IPN messages, no log gets saved and the order entry is not updated.

Like @tmslnz in the thread above, I have converted the IPN message to a form and posted it to the page (with and without/?debug). The form looks like this:

http://pastie.org/1839527

The event doesn't seem to receive the data as all I see in the XML is...

<events />

I have no idea whether this is a 2.2 issue or whether I have forgotten to do something, but would very much appreciate any suggestions. Thanks.

Hmm. I see a couple of problems and a couple of things you can try. My computer just died so I can't actually test any of these things myself this minute — I'll try and get up and running later today.

Firstly, there's a bug in the extension :p It's not returning the correct error XML from the IPN event. If you change line 252 of the /events/event.paypal_payments_ipn.php file from:

return $result;

to:

return $output;

...you'll actually get some output. That said, you probably still won't get anything as the extension tries to reconcile the data with PayPal before committing it to the log and updating the entry. This is to stop someone randomly posting data to the event. You can stop that check by commenting out line 59 of the event and making it explicitly call the trigger function by appending the following immediately below it:

return $this->__trigger();

Doing this should let you test with the manual form POST and see if the event is behaving as expected to that point at least.

I've updated the extension to be compatible with Symphony 2.2. It should the problems mentioned above.

Thanks Max, this has fixed the IPN problems I was getting. IPN entries are now created, and the corresponding section entry is also updated. My deadline is back on :-)

Fantastic.

Me again! I now need a way to send a confirmation email upon receipt of successful payment. Do you (or does anyone) have a way of sending an email at the point that the IPN event is triggered with a successful payment? Thanks again.

Sorry, haven't had to do that. I'd take a look at the Email Template Manager extension as it provides an API for sending templated emails — you'll probably need to customise the IPN event though to add the hook.

OK. Will look into it. Thanks.