PayPal IPN email issues - paypal-ipn

I've been getting daily emails from PayPal for the last week, telling me that PayPal IPN's are failing to a specific address. I've changed the listening address in the PayPal IPN panel to the one listed on my site for the plugin it communicates with. But the emails still keep coming. Can anyone offer a solution?screenshot of email here
I changed the IPN address listed in PayPal's IPN panel. This made no difference.

The IPN url configured in the account is only used if no notify_url is specified at transaction time. If all your transactions specify their own notify_url, the URL configured there has no effect.
So, for new transactions, need to change the URL your integration is specifying at checkout time when it creates the payment attempt/redirects the payer over to PayPal.
For previous transactions and subscription payments that specified a different URL at transaction time, there is no way to change nor update that URL. An old one will continue to be used for refunds and future subscription payments.

Related

After modifying the PayPal IPN URL, still using old IPN listener URL for some notifications

I'm working on a project which has PayPal integration. We have two PayPal accounts for payment and choose the PayPal account based on the type of users. We previously had two IPN listeners for the two different PayPal accounts. Previously our IPN was pointed to "https://www.old-domain1.com/paypal/ipnhandler" and "https://www.old-domain2.com/paypal/ipnhandler". Yesterday we have updated two websites into one and we started to use a common IPN to this address "https://www.new-domain.com/paypalipn/paypal/IpnHandler" to the new project.
We have added the common IPN URL on both PayPal accounts. But we could see PayPal is still sending the IPN to the old IPN handler for the old recurring payment. Our old IPN handler URLs are not currently working and we don't have the option to update the payment if PayPal is still sending the notification to the old URL. For some users, it worked correctly. For some users PayPal still using the old IPN URL. Why does this happen?
Now we have one IPN listener for two different PayPal accounts. Is this related to the problem?
If a URL was specified as part of setting up the transaction (i.e. by the software/site when the user was redirected to PayPal), that transaction-level specification supersedes any setting in the PayPal account. It is now set in stone for anything related to that transaction/recurring profile, and cannot be changed.

Paypal IPN not working on another paypal account

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.

Not Receiving PayPal IPN With Invoicing API

On the introduction of PayPal Invoicing API documentation it states that.
PayPal sends IPN messages for invoice payments and for invoices
cancelled by the buyer.
But I've found this is not the case. IPN for invoice payment, cancel or other operation never get sent from PayPal (I have checked and confirmed it from IPN history page).
Worth Mentioning
Invoices are being created via Invoicing API successfully without any warning.
I am working on Sandbox and Creating for Third Party Merchant.
I do understand that paypal doesn't send IPN for api operation changes.
The IPN listener is working fine and I have successful implementation for subscription api with IPN.
Update
Today I tried the whole process with Live PayPal account other than sandbox account and I still not getting any IPN. So, I guess I am doing something wrong or Invoicing API is broken (which I highly doubt).
Which also makes me wonder about some additional questions:
I (merchant #1) has the permission information form merchant #2 for sending invoice to their behalf.
I have setup IPN to my IPN listener URL.
merchant #2 do not have IPN setup to my listener URL.
So, when Invoice that I created for merchant #2, Do I get IPN?
OR, merchant #2 also needs to setup their IPN url pointing to my listener URL?
IPN is get send from the account that receiving payment as #effone mentioned in comment. So, it seems I was confused from paypal documentation.
Answer: The IPN url from merchant #2 will need to setup in order to get notification about invoice payment. merchant #1 account who sending the invoice behalf of merchant #2 will not send any IPN as the payment isn't involves merchant #1
Way I see it, this is not a proper solution to create an invoice management system. As if I have 1000's of user they all need to set their IPN url to mine in order to get the application work correctly (aka, setting invoices as paid when they gets paid)
Your question reads strangely, because you say the IPN is working fine, then in your update, you say you're trying it in your live PayPal account. It sounds like it's working on the Sandbox, but not in production?
If this is the case:
Did you activate the IPN under your Production (Live) Paypal account?
Do you have the IPN URL for this?
Are you seeing the IPN being logged under the Production (Live) PayPal site?
If No -> it's been a while since I've worked with this, but there used to be an interface where you could send an IPN test- have you tried that?
If Yes -> make a bare bones listener- just a page that logs that it was hit, then add logic to it.
hth

How to recreate the IPN from PayPal?

We had an error in one of our scripts and even if the notify_url from PayPal was called properly, our system was not able to record it since it had errors.
Therefore we have several transactions in PayPal that were not added to our Data Base, is there any way to recreate PayPal's IPN or re-execute the notify_url for each transaction?
Thanks!
FYI: we are using Website Payments Standard.
Go into your PayPal profile, then into Instant Payment Notification Preferences. You'll see a link there for IPN history. You can see all of the IPN's that have been sent by PayPal to your system and their status. You can select IPN's from this history list resend them as needed so your system can process them accordingly.

How to check Payment failure for Paypal Express Checkout

We are using Paypal recurring billing service (using Express Checkout) at our website for monthly subscription.
Since we have an Australian account so we are not able use the DPRP (Direct Payment Recurring Payment) service offered by Paypal because it seems, DPRP service is limited
to only few countries (US, UK and Canada).
In Express checkout payment details are received at Paypal Website. So we do not have any information, whether the payment failed, user pressed the Back button in browser or He/She intentionally clicked the cancel payment.
After speaking to Paypal support team we get know that there could be multiple possible reason for Payment failure, and seller has to contact Paypal by themself. So we can
not provide any troubleshooting for that at our website.
So we want to know, Is there any possible solution to avoid this or atleast can we diffrentiate between the user for whom payment failed and who intentionally moved to
our website back without doing payment because this way we are not only unable to followup with them but also loosing a part of the customer base, interested in our service.
Any help in this is Appreciated.
Thanks
You should implement the Pay Pal IPN (Instant Payment Notification).
You configure the IPN url address on your PayPal merchant account settings. This page is simple HTML page with server-side programming that is listening for requests coming from PayPal.
There's no need to do something extra in the checkout process for making IPN work. Once you set this up, it will automatically work.
Every time something happens with a transaction in your merchant account, e.g. transaction completed/failed/canceled, PayPal will send an HTTP Post to your IPN listener URL.
Here you can get all the relevant information about the transaction, like the payer ID, the payment status. With this information you can decide what to do with your customer's order.