22 Mar 2009, 4:17pm
Business:
by

8 comments

paypal ipn simulator

If you use the Paypal sandbox you’ll notice that there is an IPN Simulator test tool. You must be logged to use it. This tool lets you test an IPN handler script for your application. If your script is not correct and you try to send a test IPN transaction the simulator will spit out a misleading error message. It will report

IPN delivery failed. Unable to connect to the specified URL. Please verify the URL and try again.

What this actually means is that your server was contacted and your script failed! If you’re using the wrong URL then this error message will apply, however. If you are using the right URL but you have a handler script that fails or is not right in some fashion, it seems logical to report the details of the failure! At the very least, it would be nice to hear

Indeed this URL address is correct, we said hello, but you refused our ‘handshake’. How rude! Link to more info…

When I first tried out the simulator I assumed that the problem was with my DNS. I was testing against a subdomain that didn’t have a cname set up. I wasn’t too sure though if this was the problem. I could visit the URL I specified in my web browser and ping my domain, etc. I eventually got it working after checking some log files. I had to parse my apache logs to fnd that the IPN parameters were indeed posted to my server. This led me to the error in my code.

I’m not blaming Paypal 100%. The error was ultimately on my end. Nonetheless, Paypal did not aid in my troubleshooting endeavor. Instead they exacerbated the problem with an error message that made some assumptions about how I was using their tool. The first being that I understood the IPN protocol. The second, that I understood the way the IPN simulator is meant to work and the protocol under which it operates. Not my error because there is no documentation for the test tool.

Having to parse log files was a needless step in this otherwise simple remote request. Another issue that confounded the problem were the Paypal forums. Some people seemed to think that the IPN simulator was not even operational. Could this be because of misleading error messages?

In my opinion the Paypal documentation is thorough, however, very poorly organized. It seems also that a lot of the Paypal core docs are available in multiple/too many places. I’ve seen the IPN documentation in at least 3 or 4 different areas on the site. Each page adds more information or has a slightly different verbiage to explain the same problem.  Not to mention, there are way too many PDFs available for download! PDFs are great, but the content, organization and display is different from same documentation online.

At any rate, here is a quick Rails controller that will at least get your IPN simulated transactions to return success!

require 'uri'
require 'net/http'
require 'net/https'
class PaymentsController < ApplicationController
  #skip this check b/c post comes in from paypal
  protect_from_forgery :except => [:ipn]
  def ipn
    begin
      if request.post?

      #you need to post back to paypal the name/value string
      #in the same order received w/added cmd=_notify-validate
      from_pp = request.raw_post
      data = from_pp + "&cmd=_notify-validate"
      url = URI.parse 'https://sandbox.paypal.com/cgi-bin/webscr'
      http = Net:HTTP.new url.host, url.port
      http.use_ssl = true

     response, data = http.post url.path, data, {
        'Content-Type' => 'application/x-www-for-urlencoded' }
      end
     rescue Exception => e
     logger.info("Error: paypal transaction #{e.message}")
    end
  end
end
  • http://riggy.homeip.net riggy

    Thanks a lot! I had the same problems with IPN. Simulator said “your url is BAD” instead of saying “your url is GOOD but handling IPN protocol is BAD”. Right now notifications are coming and all is going quite well :-)

    Thanks again!

  • http://riggy.homeip.net riggy

    One more thing. I posted info about IPN based on your post on my site, if you don’t mind (it’s in polish). If you do, please let me know. Thanks!

  • Dss

    I cannot confirm this behavior. I can enter my homepage into the IPN simulator and IPN Simulator shows SUCCESS. But for one of my clients, no matter what page of his site I goto, even a known working callback script page, Paypal show the “IPN delivery failed. Unable to connect to the specified URL. Please verify the URL and try again.” error. So I am not convinced the error means that the script didn’t callback. I am still thinking it is either dns or webhost port blocking.. like godaddy has.

  • admin

    the simulator only reports back a generic error message… which adds confusion in the debugging process. to debug dns try pinging the url you’re using from the command line.

    ping your.example-domain.com
    #PING your.example-domain.com (209.131.36.159): 56 data bytes

    you’ll get an ip address back so that you can confirm that your application is handling the request. check your log files (if you have access to them) most likely located in /var/log/*** from what i can remember you have to post data back to paypal in order for the simulator to work. therefore, i’m surprised that any old homepage would present a success message in the simulator.

    i’d also be very surprised if godaddy blocked port 80 and or port 443 (ssl). certain functions (in php for example) may not be available in your programming language depending on your hosting partner. however, paypal integration is one of the more common usages for ecom.

  • http://www.kappacs.com/ Brian Katzung

    In addition to fixing my implementation-specific issues, the following items were key to getting my IPNs to work:

    Use port 443. Use of other ports is not guaranteed to work/be supported. (Named virtual hosts on Apache using SNI does appear to work.)

    Make sure your host name resolves via a DNS A record and not a CNAME record.

    • Christoph Witzany

      Unfortunately my experience tells me, that paypal does not provide SNI information. Which is very annoying.

  • Gabriel Vítor

    Thanks a lot Sean, this post save my weekend. /

  • http://twitter.com/lowe_logic Brian Lowe

    You’re being far too generous in not blaming PayPal 100%

    It’s 100% their fault that I’ve wasted hours in their systems and the wider network trying to get round what is portrayed as a network or transport error, when it’s plainly nothing of the sort.

    Nobody is better suited than PayPal to offer an IPN test tool, so we as developers go first to PayPal and take their test results as gospel.

    By interpreting the test result PayPal has taken responsibility for it. The least they could do would be to show their interpretation and follow it with the HTTP response, or even just the header so we might understand a bit more. We might even be able to see the cause and feed back to PayPal to help them produce more helpful error messages.