I am having an horrendous time implementing a Payments Pro gateway to Paypal and I wonder if anyone has had similar issues that may provide me with some insight?
We’re using PHP and have been attempting to interface via the paypalfunctions.php code generated at their own integrationwizard.x.com website. The original had an (acknowledge on reporting) bug in it that had there pilot and live website connects reversed, so my confidence in this was low to start with. However I implemented the code and the gateway is now taking live payments – well part of the time. On a large number of occassions the payment is rejected with an ‘invalid country code’ report.
On logging the request string immediatly before the call inside Paypals own code, and the returned result immediatly on return I can demonstrate that the string passed to Paypal is indeed correct. Paypal themselves acknowledge this, but are seeing truncate values, I quote
“Ok this is indeed a little bit odd. Your NVP string appears to be correct, but we are receiving intermittent truncation of the country code, so for example with GB we sometimes get nothing, a G, a B or a GB with the successful payments. This doesn’t leave much room for where the problem lies – can you search the server logs for the requests being made to us? ”
Now this is also odd because the string passed contains the country code embedded in the center of it – for example (with personal details changed)
USER=ZUTRB8C4OQ&VENDOR=OSO47W6EJP&PARTNER=PayPalUK&PWD=JITCMJA8VAN6YBMP&TENDER=C&TRXTYPE=S&ACCT=XXXXXXXXXXXXXXXX&CVV2=646&EXPDATE=0512&ACCTTYPE=Visa&AMT=55.60&CURRENCY=GBP&FIRSTNAME=John&LASTNAME=Smith&STREET=9/2 Oaklands Hill&CITY=Edinburgh&STATE=&ZIP=EH11AAA&COUNTRY=GB&CLIENTIP=82.19.219.153&ORDERDESC=The Order&VERBOSITY=MEDIUM&BUTTONSOURCE=PF-CCWizard
Which strongly suggests to me that the issue is how this string is parsed or processed. We have example NVP strings that are accepted and rejected and the layout is identical, and even one case where the same card is rejected at different IPs.
Anyone else had similar experience?
UPDATE: On checking the server (it’s shared hosting) I find a large error log consisting almost entirerly of lines like
[08-Jul-2009 10:14:27] PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/local/lib/php/extensions/no-debug-non-zts-20060613/sqlite.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/sqlite.so: undefined symbol: php_pdo_unregister_driver in Unknown on line 0
There’s no obvious link between an sqlite library and curl to my knowledge, but this implies PHP has not been configured corectly and could this cause the sort of random errors where seeing?
I downloaded a copy of paypalfunctions.php but it doesn’t send strings. Instead it uses curl with the CURLOPT_POSTFIELDS parameter to send all the variables as HTTP POST (separate fields in the POST body) instead of a long GET string.
I suggest using something like tcpdump and Wikeshark to capture and review what is actually sent to PayPal. If you get the same problem again, you can show them the tcpdump to show them that you actually sent the correct string.
PS: Note that if you sent it according to your TCP logs, that still does not mean that PayPal actually recieves that. I vividly remember hunting down a strange issue with HTTP POST at my former employer. My TCP dump said I sent it. Their TCP dump said they didn’t get it. After weeks it turned out there was a misconfigured transparent proxy halfway between us and them. It accidentally had deep packet inspection turned on to remove certain parts of HTTP POST forms. “Oops” said the network provider.