Since this week the forwarding to our site after payment does not work anymore in production mode, while it still works within the sandbox.
Actually we use PDT for the direct forwarding and IPN as backup. For some reason the payment is not finished fully. There seems no PDT or IPN connection to be established from PayPal since beginning of this week.
A payment from March 9th was successful, but all payments since March 11th are marked as successful on the PayPal page, but our site "does not know it", so customers don't get their accounts updated.
When trying to track the bug, I switched to the sandbox, but there everything works fine there.
Has PayPal changed something recently? (The design during payment process ist now, but I don't know since when...)
Thanks!
The biggest downfall with PDT is the message is only sent once, where as IPN is repeatedly sent until the server responds with the correct message. You can run both, but from my experience it is very uncommon (and I build eCommerce systems for a living). Recently a lot of my company's clients who run PayPal as their payment method have come to us with a similar problem (even more so with RBS WorldPay). And the solution has been to try the following:
Confirm that the IPN listener URL is still working and pointing to
the right site (some people try to use one PayPal account for
multiple sites, and change it to the 2nd site not thinking it will
stop IPN for the 1st site).
Make sure the latest version of the PayPal gateway is installed (if
on OpenCart / WooCommerce / Magento / etc...). The latest version
requires SHA-256.
Ensure the server has SHA-256 enabled, as above PayPal is now asking
users to make sure they have it for the hashing to work.
Ensure that an SSL certificate is installed. It is not yet a certain requirement, but in this day and age if you don't have one, you are not likely to get many orders. Also for some strange reason it has fixed IPN for some clients.
Hope this helps!
Related
I'm brand new to setting up IPN's. I've built websites, but never a subscription site like the one I'm building now. I'd like to set up a recurring monthly subscription option and a recurring yearly subscription option.
My website is built on Joomla 3 and I'm using a plugin for the subscription module. I set up the PayPal subscription buttons just as explained in the directions, which I followed to the letter. Nevertheless, when I go to test it in the PayPal sandbox, I keep getting the same error, which says that it wasn't sent and the handshake wasn't made, and to check my settings. That's all it says. I don't know if the issue is with my site, my server or the settings I'm entering into the actual sandbox. I checked with my server and they said there's nothing wrong on their end. Do I need an SSL for the integration to work?
Please keep in mind that, while I can follow explicit directions, I'm so new at this that I don't even know how to access my 'listener,' so if you respond, please let me know where to find things, if necessary.
Any help would be very greatly appreciated - I've been at this for 12 hours now and I'm at a complete loss.
This issue has two sides
1. Is Paypal IPN enabled on the sandbox account where you are trying to receive the payments
2. You would need a IPN listener script to get the IPN notifications
This process is the same for Sandbox or live mode
https://www.jotform.com/help/276-How-to-Enable-IPN-for-Paypal
https://github.com/paypal/ipn-code-samples
This should help you get started
One of my customers had a website hosted on FusionHQ with subscription profiles through PayPal. When migrating the payments, I guessed I could just change the IPN and would get the new messages. But it seems that Fusion has manually set nofify_url parameters for their subscription profiles and there seems to be no way to change the notify_url.
Though slightly annoying, I guessed I could still use the classic payments API to get information and do something stupid like checking the subscribers' status on the assumed expiration date. But, it turned out that PayPal doesn't allow it because the specific API FusionHQ has used, with the following error message:
Subscription Profiles not supported by Recurring Payment APIs.
The thing is that there is no way I can get access to the old IPN server since it is on FusionHQ's domain. After searching through StackOverflow, I've really lost all hope of doing this in a decent way, and I'm about to redirect my customer's PayPal emails to some SMTP bot to parse them and give me the transactions update. But this is obviously a very crappy and unreliable way. So, does anyone have any idea of what to do?
I have a web site thats been operating for months, if not years. It takes payments via PayPal. IPNs are used to track the payment status against an order.
If the paypal account owner issues a refund, the IPN from that is tracked, and the order updated with the amount refunded.
Now: The problem: This was all working in February 2015. But since then I have made 4 refunds (buy logging into the PayPal website and refunding). Each one was days apart. In each case they were partial refunds.
In all cases the monies have reached the recipient, and logged transactions IDs etc in PayPal.
The first one, I never received the IPN.
The second one I did received the IPN (and decided the first one must have been a glitch, unusal though it would seem)
However the third and fourth also have not generated an IPN that I received.
From looking at the Apache logs, there appears to not have been even an attempt from notify.paypal.com that Apache received.
So I am much puzzled, have googled around but not found anything. Can anyone suggest what I have missed that have caused these IPNs to stop?
Perhaps I should add that I continue to receive all the payment notification IPNs just fine. It seems to be just the refunds that I miss.
I thought at one time there was a flag about IPNs in settings, but I can't see it anywhere in the new web interface.
Regards
Monathan
We have this website that was running since September 2013 and relying on paypal IPN for user registration. However, this week we got a report from the client where 3 users was able to pay through paypal but was not registered into the site.
We temporary changed the paypal email('business' field) from the client's to another paypal account. Went through the process of registration and the IPN was successfully delivered. The user was created in the system, the IPN transaction was logged into our system. When we tried to changed it back to the client's paypal email account, but unfortunately the IPN did not reached through our system.
Here are some questions that I have in mind
Does the type of paypal account (ie. business or personal account) matter when sending and receiving IPNs? Could this be a possibility? (even though last year it was working perfectly fine with the client's paypal account)
We've been receiving this paypal email (below) for the past months. That email was appearing after a few months when we opened the site and we didn't even changed a single code from our IPN listener. Could this be the reason why the IPN was not sent when we use the client's paypal account? However, we always use the notify_url field since we have multiple IPN listeners.
>Please check your server that handles PayPal Instant Payment
>Notifications (IPN). IPNs sent to the following URL(s) are failing:
>
>http://<site>/payment/postback/
>
>If you do not recognize this URL, you may be using a service provider
>that is using IPN on your behalf. Please contact your service provider
>with the above information. If this problem continues, IPNs may be
>disabled for your account.
thanks,
Your IPN script is not completing successfully, so PayPal's server is not getting a 200 result back, which causes it to send repeat IPN's and will eventually disable itself as the message says.
Your web server logs should provide the info you need. Check there to see the history of the IPN script getting hit and you'll probably find some 500 results. Those should also provide the actual error that happened so you can get it resolved.
It's possible that some IPN's are working just fine but others are failing based on certain characters in payer information or other similar issues. You need to get all of that worked out in your IPN script so it can handle anything thrown at it.
My website uses the PayPal Adaptive Payments API with the Embedded Payments flow and simple payments. On my checkout page I execute a Pay API call, receive successful response, then call SetPaymentOptions and again get successful response. The customer then reviews the order form and upon confirmation of the order is redirected to https://www.paypal.com/webapps/adaptivepayment/flow/pay in the PPDGFrame iFrame with expType set to "light" and the paykey received from the Pay API call.
I have successfully tested it in a sandbox and rolled it out to production. The application worked great for a day or two and then stopped working, with buyers now receiving a "Please try again later" error when trying to login. I am still getting successful responses on both the Pay and the SetPaymentOptions API calls and the customer is successfully redirected to the PayPal login screen. The customer enters the login credentials, clicks the Login button and a couple seconds later gets the "Please try again later" message.
Now here are some really odd behaviours if I've ever seen odd... This problem first appeared about 4 days ago. Since PayPal advised me that it will take them "several weeks" to get back to me, I have tried the checkout again two days ago and experienced the same problem. I have then tried a guest checkout and it worked! Next I tried a regular user checkout and it was successful as well so I thought to myself that the problem has somehow resolved itself.
Yesterday morning I tried the checkout again, and got the same problem as before. Again I tried to checkout as guest, which again was successful, and then immediately after I have tried regular checkout and again this time I was able to login successfully.
Today the flow is broken again. What gives? Nothing is changing on my site. Why does it sometimes work and sometimes doesn't, and how is it that a guest checkout seems to be able to temporarily resolve the issue?
The problem has been resolved with no action on my part and no change to the website or application code. After a couple weeks of the API simply not working, it started working intermittently with gradually improving success rate while my support ticket with PayPal was sitting in a "Waiting" status. I was told that the "engineering team" is waiting for a server code roll-out. The intermittent nature of the problem and a gradually improving situation suggests that PayPal was rolling out a fix to their servers in a staged approach and outcome of the API operation depended on which server the PayPal load balancer happened to send the request to. After about a week of that, the problem was resolved completely. PayPal of course maintains that they have not made any server changes.