Not a bug Paypal Merchant Technical Support recommend not relying on IPN

X

Xon

Well-known member
Affected version
2.2.15
A few sites I admin for recently experienced an issue where IPN just didn't get send. After opening a support ticket with paypal, I eventually received this:

Quick follow up:

We were waiting for our team to confirm whether the data were available or not to be resent and avoid any duplicate data on your end.

Unfortunately, the team has confirmed yesterday evening that this won’t be possible for those missing transactions.

In this case, the IDs can only be manually updated on your end.

We also recommend merchants not to rely solely on IPNs, as this backend communication can fail (rarely, but it could happen) due to any issue on our servers or yours.

We recommend you to use our available APIs method to verify the status of your transactions and update them accordingly.
Click to expand...
(Formatting from paypal)
 
While the REST api is a way forward, I think it needs a "force check paypal state" functionality for pending payments to catch the case where the webhook has failed and can't be resent would be ideal
 
Especially useful if there was a way to use existing rest API and to force it to consider a transaction to be considered payment for a user upgrade.

I haven't explored the rest api, but can it access subscriptions created the old way? If so this would allow finding the latest transaction for the recurring subscription which would allow "migrating" off the old IPNs process.
 
We use authorize.net, which is dependent on Webhooks. They recently had an outage where payment confirmation hooks weren't sent, so a large subset of orders showed as unprocessed/incomplete on our side. Post outage, we asked if they/we could retrigger confirmation events and we had the same response: "Oh sorry, go ahead and dig through your transactions and compare manually; we won't retrigger payment confirmation. Good luck". This is something that I'll have to dig into as part of the add-on as well; but interesting the processors are consistent in not allowing payment confirmation to be triggered back. Looks like it'll have to be a manual poll endpoint X and check orders for completion as a cron job every hour or so.

Not sure if such an implementation could be generic, but it'd be highly useful across all processors IMO.
 
It's worth noting that PayPal do not use the terms webhooks and IPNs interchangeably. While conceptually they are the same thing, IPNs and webhooks are two different things.

The term "Instant Payment Notifications" is only used by them when they're talking about their legacy NVP/SOAP APIs (and older).

The term "webhooks" is used when describing messages sent resulting from usage of their current REST API.

The point about "your server" potentially being an issue in the context of webhooks is moot:

Important: If your webhook endpoint is unavailable or takes too long to respond, PayPal resends the notification message 25 times over the course of three days until a successful response is given.
Click to expand...

So that just leaves the point about "their servers" being the issue. And, frankly, we're not going to be pandering to some over-engineered "fallack" solution just because they can't reliably guarantee the delivery of a simple HTTP payload. The onus is very much on them to ensure the webhooks/IPNs/whatever they want to call it to be delivered.

We're not taking this forward as a bug fix. I'd rather just remove support for PayPal entirely. I don't see them as a serious contender in this space if this is their level of commitment to ensuring the basic functionality of webhooks just works.
 
Top Bottom