We have recently moved our drupal website which is integrated with our CiviCRM database. We're having a bit of a problem getting our payment processors to communicate back to our database to confirm when a payment is completed.
Our call back URL has changed. The api.Paypal.com IP addresses have been added to the white list but I need to update paypal with the new call back URL.
I can't work out where I need to do that at all! Can anyone tell me?
Thank you!
Related
We have migrated a bespoke php website to a new server on a new IP address. Since then the Paypal IPN system does not callback to the website so orders don't get updated etc. Could someone please give me some ideas of what to check on the webserver. Why would this stop working once the website has been moved to a new IP?
Ok it seems to be working now. It must have been related to the domain IP change taking time to propogate through the internet.
We have a cpouple of sites using website payments standard and are submitting the forms as a post to the https://www.paypal.com/cgi-bin/webscr address
some customers (not all) are experiencing a timeout when trying to get to the paypal payment page after the post.
The site sits and status bar says 'waiting for www.paypal.com'
The web Inspector on chrome shows a 504 Gateway Timeout error after 1 minute and then the user gets sent to a paypal page with a paypal debug-id down at the bottom
This is intermittent, sometimes there are no problems at all then sometimes a user cant get through, so we try at the same time and have no problem
has anyone else seen anything like this?
any ideas?
paypal support are 'looking into it' and said it couldb e a 'problem with our endpoint api' ... all we do is post to them and and then they send back a pdt/ipn when complete. and it works from different locations at the same time one person is down, someone accross thr country is fine, its like when there is a problem, the www.paypal.com address cannot be found by the browser trying to connect
You are not alone. The old PayPal webform integration seems to have this problem every now and then. I believe there is nothing you can do other than hope that your customers are not affected (much).
The only alternative is to use a different PayPal API to integrate it in your shop.
I'm using the callback API to prevent someone selecting a non-UK shipping address. I've supplied a callback url, I've set CALLBACKVERSION to 61.0.
When I go into the sandbox and choose an address I know the callback page is being called as I've added code to email me the values submitted to it and the value returned to PayPal. For anything with a SHIPTOCOUNTRY that isn't GB the response is
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1
I've also tried setting a fuller response in case it doesn't like some required field to be missing
METHOD=CallbackResponse&CURRENCYCODE=GBP&L_SHIPPINGOPTIONNAME0=Standard&L_SHIPPINGALABEL0=Standard&L_SHIPPINGAMOUNT0=2.95&L_SHIPPINGOPTIONISDEFAULT0=true&L_SHIPPINGOPTIONNAME1=Express&L_SHIPPINGALABEL1=Express&L_SHIPPINGAMOUNT1=5.95&L_SHIPPINGOPTIONISDEFAULT1=false&NO_SHIPPING_OPTION_DETAILS=1
But it's still allowing non-UK addresses and just using the shipping options set during the initial set up request.
Any suggestions on where I'm going wrong?
After opening a ticket as suggested by PayPal_Patrick the problem was that I was adding the callbackversion in the wrong place. The full response to reject a shipping address on callback is:
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1&CALLBACKVERSION=61
There are different transaction ID's for Buyer and Seller accounts.
I think this might be an issue caused by the country associated with the buyer account being used. I'm going to reach out to the product team for Express Checkout and see if it is intended functionality or not - I don't believe it would be.
If you want to stay updated on the issue I would recommend creating a ticket to PayPal.com/mts, give me the ticket number, I'll grab it and keep you involved.
I have a weird issue with Paypal IPN. Every alternate transaction is failing. So let's say if first transactions goes well then second one fails. Similarly if 3rd one goes well then 4th one fails.
HTTP status code I am getting for failed transactions in IPN history is 400.
I have implemented the new Paypal host header changes that were newly introduced by them.
Any idea why this is happening?
IPN History
http://i.imgur.com/NfqRsGi.png
IPN Detail
http://i.imgur.com/hcKdasw.png
EDIT
I am using PHP with curl to do IPN work (using same sample code as available on Paypal website)
ANOTHER EDIT
Ok I found another code sample for PHP 5.2 from Paypal site. This one is slightly different than the one I am currently using. I tested it on Paypal Sandbox twice and it worked. Later on I will test it on live to see if it is working fine or not.
Error 400 = bad request, this means that the get requests being made on the application layer (by your browser) may contain errors or the transport layer (syn, syn, ack, syn) 3 way hand shack is being interrupted. I would check your PC for Mallware to be on the safe side. Do a netstat -b in dos and see what's trying to get connections to the external network.
Also do a scan with malware bytes and a good virus scanner like Eset nod32.. Let us know how you get on^^
The new script I downloaded from Paypal website fixed the issue.
I'm trying to get this PayPal IPN tutorial to work:
http://net.tutsplus.com/tutorials/php/using-paypals-instant-payment-notification-with-php
I setup everthing and now I'm in the PayPal sandbox and sending with the "Instant Payment Notification (IPN) simulator" a message to my "ipn.php" and nothing happends.
The databse is still empty and I don't get a notification email.
I'm totally stuck with this. What can I do to find the error?
Thanks
Michael
Make sure your listener is on port 80. It is undocumented, but the paypal IPN simulator will fail to send to any other port.
The tutorial URL does not open for me, I get a "No input file specified.".
My first suggestion would be to open the PHP script that processes the PayPal IPN and write the following in the beginning:
file_put_contents('dump.txt', print_r($_POST, true));
Ensure you have write permissions in the directory that holds the script because "dump.txt" file will be created there. This way you can see what PayPal sends to you and give you a starting debugging point.
Also check your web server error log for PHP errors that might be happening to you. The tutorials are often written long time ago, on different systems, different PHP version, etc.
Edit: Also you probably already know this but the IPN processing script should be publicly accessible, not some localhost stuff.