Pro: Testing bookings in Paypal sandbox mode

[Stephen Harris]

Hi Dario,
You shouldn’t need to specify an notification url.

Ok, so the test site is working as expected for both of you. The ‘unilateral’ error means that the email address of the payment recipient has not been registered with PayPal. I’ll be adding improved gateway integration to make these error messages easier to handle.

Given that you’re using WordPress in a subdirectory I’m almost certain the error is the home_url() on mentioned above. In / gateways / paypal-standard.php (line 36), change home_url() to site_url(). That should resolve the issue for you.

I’ll release an update once that’s confirmed.

[Dario]

Hi Stephen,

After changing home_url() to site_url() I do indeed get a gateway response for the booking for which I didn’t get before.

The “unilateral” error occurred because I was using my real merchant account and not a sandbox merchant account.
Once that was fixed I was getting multi_currency errors (as the merchant account is AU, the payee account is AU and my currency is set to NZ). After changing my currency to AU the bookings confirmed automatically as intended.
I’m currently in the process of getting PayPal to create a verified NZ business sandbox account for me (as it is impossible to do this on the developer site), and I’ll test the plugin again when I get that account, but I’m fairly certain that the plugin will work fine.

Also it turns out that IPN doesn’t need to be enabled, or at least not using this setting screen, which didn’t allow me to enable IPN without a notification url.

[Stephen Harris]

Awesome, glad that this is sorted for you – I’ll include this in the next update, which should be out next week.

[David Musgrove]

Hi Stephen

This isn’t working for me at all I’m afraid. I can complete the transaction on both Sandbox and Live PayPal, but in neither environment does the booking end up as confirmed, so confirmation emails don’t get sent out without manual intervention.

When PayPal returns to my site, all I get is an empty booking form again, no confirmation message, which looks awful. All the expected PayPal emails are there, and I can see in Chrome developer tools that PayPal is posting a valid set of data back to WordPress. When I try to access the site with the querystring you suggested earlier directly, I get the empty page with the error box that I should do.

Any advice?

David

[Stephen Harris]

Sorry to hear you’re having trouble

If you view the booking’s admin page does it include a ‘Gateway response’ section, or is there a transaction number under the booking ID in the bookings admin table?

Could you include the plug-ins and themes you are using (you may want to try the plug-in on a fresh install of WordPress, or with all other plug-ins & themes disabled to rule out (or identify) the possibility of it being a plug-in/theme conflict.

(It might be easier to go to wp-admin/edit.php?post_type=event&page=debug and copy the information there into an e-mail.)

[David Musgrove]

Thanks for the prompt response Stephen. No, no gateway response section, no transaction numbers. I’m using the Responsive theme, and quite a number of plugins:

Archives for a category / Better WordPress Minify / Better WordPress reCAPTCHA / Contact Form 7 / Contact Form 7 reCAPTCHA extension / Event Organiser (+ Pro) / Google Analytics / Google XML Sitemaps / Map Categories to Pages / Member Access / Meteor Slides / NextGEN Gallery / NIVO slider light / Page Links To / Query Posts / Really simple Facebook Twitter share buttons / Remove Dashboard Access / SEO Slugs / SoundCloud Shortcode / UK Cookie Consent / Video Sidebar Widgets / W3 Total Cache / WordPress Backup to Dropbox / WordPress SEO

Any of those ring immediate alarm bells with you? I’d obviously prefer not to set up another clean site to test these one by one if I don’t have to…

[Stephen Harris]

Yup, quite a lot :).

None listed have are known to cause conflicts. And certainly most there should never cause any problems. Given that the PayPal says the payment is confirmed, and Event Organiser doesn’t seem to receive anything – not even an error message – indicates the problem is in the IPN getting through.

If you could verify the following: go to your account’s IPN history ( https://www.sandbox.paypal.com/us/cgi-bin/webscr?cmd=_display-ipns-history for sandbox accounts) and verify the IPN url is correct. Please note the response too – the HTTP response code should be 200. (In fact if you can email the IPN message that may help with debugging)

In terms of plug-ins I feel the most likely source of conflict will be with:

• W3 Total Cache (cached page being served to the IPN bot)
• Member access (if the IPN response page is hidden from logged out users)

It seems unlikely that any others would be the source of some conflct. If you want to quickly test your set up on a fresh install, you can set one up here: http://wp-event-organiser.com/try-it/ (but this will only help verify your account set-up, not your plug-in/theme or server set-up)

[David Musgrove]

OK, might be getting somewhere now in diagnosing this at least. PayPal is failing to post the IPN back. It’s posting to (but with the correct domain):

http://mydomain.com?eo-listener=ipn&eo-gateway=paypal

There is NO HTTP response code showing. Accessing that URL directly (GET rather than POST) brings up the empty page with the error box. Same symptom for four sandbox and one live PayPal order.

As for those plugins, I’ve now disabled W3 Total Cache. Member Access is off by default for every page, so I’m pretty sure that’s not the issue.

[David Musgrove]

Incidentally, this URL seems fairly “fixed” to me – you said that not having a fixed URL was the reason not to turn on the automatic IPN posting and redirection from PayPal I think, so does that mean you’ve fixed this and we could now enable automatic IPN posting and redirection in PayPal?

[Stephen Harris]

So the IPN url wont change, but its only set ‘on the fly’ (in each request)- so as far as PayPal is concerned, its not fixed – which is why redirection does not happen automatically. But you can provide the IPN url to PayPal and then it should redirect (Though I think whatever url you set will be over-ridden by the plug-in – but there’s a filter in place so that you can modify the request sent to PayPal, and so remove it).

So the lack of HTTP response code indicates the server not responding – might want to check your site’s log to verify if the IPN request is recieved. Also, do you know if your site has curl available? (If you could go to yoursite.comwp-admin/edit.php?post_type=event&page=debug and email me the contents, that might be helpful).

[David Musgrove]

Thanks Stephen, I’ll try that out. I think the fundamental problem is resolved. I interpreted the lack of a response code the same way, so Igot the IPN data from PayPal and posted it myself using curl. When I did this the transaction ID appeared in WordPress, and the booking was confirmed. The issue is PayPal communicating with my site, and I think the cause is that the DNS servers for this domain were changed on Wednesday morning, in order to point this website at the new version I’ve been putting together. Now, 72 hours should be plenty to propagate everywhere, but I’m guessing not for PayPal!!!!

I have an alternative URL that has been pointed to these servers for far longer, I’m going to try to set that in the IPN address, filter it out from the PayPal submission, and see where that gets me. I’ll post back the results. Thanks so much for your help during a weekend!

[David Musgrove]

Yes, that was the problem. The IPN address is now set to the other domain, and everything is flowing through (in the sandbox at least). Now for the first live sales…

Thanks once again Stephen.

[Dario]

So the IPN url wont change, but its only set ‘on the fly’ (in each request)- so as far as PayPal is concerned, its not fixed – which is why redirection does not happen automatically. But you can provide the IPN url to PayPal and then it should redirect (Though I think whatever url you set will be over-ridden by the plug-in – but there’s a filter in place so that you can modify the request sent to PayPal, and so remove it).

This non-redirection scares me as I’ll have 3000 bookings from mid-June to mid-July and some customers will most certainly close the PayPal window after the successful transaction and my site will never get a response from PayPal. This would mean a ton of manual confirmations.

Could you please further explain how I could set a automatic IPN redirect. Also is there a way to redirect users to a confirmation/thank you page instead of just the event page, or a message on the event page saying that payment went through?

Thanks

[David Musgrove]

Hi Dario

I’ve just done this. I set the IPN address in PayPal, and also set automatic redirection. Then I disabled the sending of the IPN address in the PayPal request with a bit of a dirty hack – I’ll let Stephen reply with a “clean” way to do this rather than give you the specifics. I now have everything flowing straight through as it should. I’ve also suppressed the return URL going through with the PayPal request in the same way, and I just have everyone coming back to a fairly generic “thank you” page.

David

[Stephen Harris]

Dario, David,

Sorry, I wasn’t thinking earlier. I mixed up IPN url and return URL.
To clarify that the IPN is still sent even if the user does not return to your site.

Regarding the return URL PayPal doesn’t like taking users from their site to an arbitrary site without the user explicitly choosing to. The fact that PayPal automaticaly redirects if you set the redirection url in your PayPal admin is because PayPal knows that you set that url, and it wasn’t injected malicously (I assumed).

Setting the IPN url should not matter. In fact if you have other plug-ins that use PayPal then it may mean they don’t seem to respond to payments (because the plug-in isn’t receiving the IPN).

[Author]

Posts