Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Multiple PayPal Standard _notify-validate[IPN] status updates


mattsc

Recommended Posts

Running on 2.3.4BS PayPal App v4.039 here and I'm running into a problem with the PayPal Standard IPN module. For whatever reason I can not determine, occasionally I'm getting 3 messages logged to an order. Whenever I only get 2 updates, everything works as expected. All the emails are sent, stock is deducted from inventory, all is good. When I get 3 messages logged to the order from PayPal things go downhill. None of the emails are generated and stock isn't removed from inventory. I'm at a loss as to what the cause of the 3 messages being logged is, or why some of the PayPal Standard IPN orders only get "_notify-validate [IPN]" entries logged. Here is an example of where I get the problematic 3 entries in the order status, 12 seconds apart:
image.png.0e008106098be469c6edec008ee094e8.png

Verses a "normal" transaction where I only get 2 log entries from PayPal which are all being processed 1 second apart:

image.png.24154a57f5d8dd4aedef25a9b4639f78.png

I'm not seeing anything weird in the PayPal log content wise other than it showing either the 2 or 3 entries in the log:

image.thumb.png.595b4089c7b090404d84ec1618ecd19d.png

The response code every time however is successful with a "VERIFIED" reply:

image.png.e7f080984669b965739fe573e5e99fe4.png

and the duplicate _notify-validate [IPN] entries being exactly identical and also "VERIFIED" as the reply:

image.png.67b69585429c7c1dfc61d4ecc72ebcc6.png

I tried asking a PayPal integration engineer to look at their logs to see if there was anything odd, and he said there was not. His only thought was "maybe your system is timing out" but if it is, I'm unsure what I could change other than possible the php.ini default_socket_timeout value, which is current set to 60 seconds.

I'm just running into one problem after another after another with the PayPal Standard IPN module here and can't figure out why it's working fine most of the time, but occasionally I get these three logged IPN entries, and the order somehow isn't completing with Order Process emails not going out and the stock not being updated.

I am TOTALLY stumped here and have no idea where else to look. I've eat, slept, breathed, and died in the /include/modules/payment/paypal_standard.php/order_process.php, and /ext/modules/payment/paypal/standard_ipn.php files.

 

 

 

Edited by mattsc
Link to comment
Share on other sites

may be a setting in your actual paypal account or an issue with the PayPal App version 4.

Have you tried updating the App to above version 5 as the App is at v5.0.18

No longer giving free advice. Please place deposit in meter slot provided.  Individual: [=] SME: [==] Corporation: [===]
If deposit does not fit one of the slots provided then you are asking too much! :P

Is your Osc dated try Phoenix  raising oscommerce from the ashes.

Link to comment
Share on other sites

15 minutes ago, 241 said:

may be a setting in your actual paypal account or an issue with the PayPal App version 4.

Have you tried updating the App to above version 5 as the App is at v5.0.18

I would expect a setting on the paypal account would cause ALL orders to fail if something were set wrong... and with duplicate entries a I would think it would have to be something on the server, tho what, I do not know. There doesn't seem to be ANY commonality between the orders that "fail" with 3 IPN records and thus emails not being sent and inventory not being updated, and the ones that "succeed" with only getting the 2 records in the log.

I have not updated the PayPal app. I don't remember what the problem was that I ran into when I tried to do it, as it was a while ago (about a year) when I attempted updating the PayPal app portion of OSC. Part of my problem is I no longer have an good means of creating an exact copy of the site in a development environment. So, any changes are made on a live system. I know, it's horrible, but it is what it is... so I'm VERY careful about the changes made, and considering more than half of all sales go through PayPal, I'm VERY pensive about making another go at doing the update.

Edited by mattsc
Link to comment
Share on other sites

You only get _notify-synch when the customer comes back to the site.

It looks to me like paypal  is sending multiple IPNs (they have different ipn_track_id values) ... but actually that shouldn't matter to the order completion and email sending.

On the double IPN transaction, the first is recorded at the same time as the customer comes back. On the single IPN, it is afterwards.

It is possible that the order completion processing in ext/modules/payment/standard_ipn.php isn't working properly but that in includes/modules/payment/paypal_standard.php is ok.

 

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

4 minutes ago, BrockleyJohn said:

It is possible that the order completion processing in ext/modules/payment/standard_ipn.php

so the call back...

mattsc are you TLS 1.2

 

No longer giving free advice. Please place deposit in meter slot provided.  Individual: [=] SME: [==] Corporation: [===]
If deposit does not fit one of the slots provided then you are asking too much! :P

Is your Osc dated try Phoenix  raising oscommerce from the ashes.

Link to comment
Share on other sites

Digging through some old code, I think that early versions of the  app had no order completion processing in standard_ipn.php

I think your best approach is to update the app and sort out any issues that arise. There is a lot of change between your version and the current (see attached)

paypal-app-versions.png

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

2 hours ago, BrockleyJohn said:

You only get _notify-synch when the customer comes back to the site.

It looks to me like paypal  is sending multiple IPNs (they have different ipn_track_id values) ... but actually that shouldn't matter to the order completion and email sending.

On the double IPN transaction, the first is recorded at the same time as the customer comes back. On the single IPN, it is afterwards.

It is possible that the order completion processing in ext/modules/payment/standard_ipn.php isn't working properly but that in includes/modules/payment/paypal_standard.php is ok.

 

My post might have been confusing. I was trying to provide as much info for the transactions which didn't have a problem vs the ones that do. That's why you are seeing the two different IPNs. In both orders, the results came back with "VERIFIED" to the was all. The double IPN records are exactly the same. The ext/modules/payment/standard_ipn.php script is OK. I've verified that with PayPal as well with making sure their callback was successful. The scripts are OK as well because MOST of the time, I don't get the duplicate IPN 10-15 seconds later. The only correlation I've found between the orders that have a problem and those that go through correctly is when there is this duplicated record. Earlier I had an issue where if the order totals differed, I also had the problem (see Not getting Order Process mail if Total Mismatch of $0.01) but I've since put in a variance check so when that issue is encountered, those orders are succeeding now. 

 

So I've just been working through one issue after another here. I considered adding to the prior post, but this seemed like it was different enough to justify a separate thread.

I am getting multiple IPN from PayPal, but I don't know why. I would think that would be caused by something on the host failing but the PayPal integration tech guy tells me they are getting a success 200 reply so I'm a bit at a loss to explain why they are making the second attempt. 

I have other instances where the success happens at different times, so it's not always that _notify-sync and _notify-validate [IPN] occur at the same time or at different times... so that's not it either.

image.thumb.png.daf301ac1f99942fed1341f627b06153.png

 

1 hour ago, BrockleyJohn said:

Digging through some old code, I think that early versions of the  app had no order completion processing in standard_ipn.php

I think your best approach is to update the app and sort out any issues that arise. There is a lot of change between your version and the current (see attached)

paypal-app-versions.png

No I -=AM=- getting Order Process email notifications for MOST of the PayPal Standard transactions. Just not all. I'm unsure at this point how to even attempt to debug this further as I'm not seeing any semblance of a pattern. Maybe I need to tell my client I need to take the website offline so I can update the PayPal module. They won't be happy about that in the least, but if that's really down to my last option to try and fix this then maybe that's what will need to be done.  I am seeing a note in there about 2.3.4  BS compatibility. The timestamp is right around the time when I was doing the coding for the site, so maybe those changes not being there was why my attempt at updating failed the last time I tried to update the PayPal app code. That "lot of change" is what is making me nervous tho. I'm not sure how much effort or time it'll take to update the PayPal app, or how much time it'll take to "sort out any issues" once the changes and complete. I'll just have to present it as an option to them and let them make the call as to if it's a big enough of a deal to them or not.

Link to comment
Share on other sites

Your new transaction sample shows the same pattern; the HI customer comes back to the store before the IPN, the Dieg customer is slower - there's an IPN with the same logged time as the sync and then an extra one afterwards.

Does the IPN history at the paypal end show any further info? You can find it by going to https://www.paypal.com/cgi-bin/customerprofileweb?cmd=%5fprofile%2dipn%2dnotify and then clicking the link in the first paragraph.

Does that offer any clue as to why another gets sent? Does the second also show as 'original'? Logic suggests that the problem should lie in the first that arrives at more or less the same time as the customer... the processing that's not happening should happen then. I take it that the order gets changed to the proper status but the subsequent stock and email processing doesn't happen.

I'm still clinging to the theory that there's something up with your code in standard_ipn.php and that doesn't work properly when it has to complete the order. You could try replacing it with the original file from the addon version 4.039 if you don't want to update.

If, for example, you hit a mysql query error in the download query after updating the order, you would still get the green transaction log in admin, the HTTP 200 return to paypal and the order changing status but without the rest.

A successful update of the paypal app takes seconds; it is completely automated from the osc admin section. I have run it on 6 live sites and lots of test ones without a failure so I can't comment on how long it would take to unravel if it does go wrong. They've all been BS sites though.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

I've just had a look in a couple of pp standard users. I couldn't find any examples of duplicated IPNs in the data I looked at, but both also sell on ebay which muddies the waters somewhat as you get IPNs for those sales too. I did find examples where the IPN arrived at the same time as or before the customer came back with a _notify-sync

@mhsuffolk are you saying your typical order has three Paypal [Transactions] status history records? Two ending source: IPN and one without?

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

@BrockleyJohn 95% have two Two.JPG.549fa3e76cfff14583e64af80ddb02ce.JPG

5% have one One.JPG.b85f4f925be9391df488d27c78826284.JPG

None have three

I am unsure which is normal or correct. I have no IPN errors from PayPal and non failed in the log on the PayPal site.

 

Edited by mhsuffolk

Live shop Phoenix 1.0.8.4 on PHP 7.4 Working my way up the versions.

Link to comment
Share on other sites

10 hours ago, BrockleyJohn said:

Your new transaction sample shows the same pattern; the HI customer comes back to the store before the IPN, the Dieg customer is slower - there's an IPN with the same logged time as the sync and then an extra one afterwards.

Does the IPN history at the paypal end show any further info? You can find it by going to https://www.paypal.com/cgi-bin/customerprofileweb?cmd=%5fprofile%2dipn%2dnotify and then clicking the link in the first paragraph.

Does that offer any clue as to why another gets sent? Does the second also show as 'original'? Logic suggests that the problem should lie in the first that arrives at more or less the same time as the customer... the processing that's not happening should happen then. I take it that the order gets changed to the proper status but the subsequent stock and email processing doesn't happen.

I'm still clinging to the theory that there's something up with your code in standard_ipn.php and that doesn't work properly when it has to complete the order. You could try replacing it with the original file from the addon version 4.039 if you don't want to update.

If, for example, you hit a mysql query error in the download query after updating the order, you would still get the green transaction log in admin, the HTTP 200 return to paypal and the order changing status but without the rest.

A successful update of the paypal app takes seconds; it is completely automated from the osc admin section. I have run it on 6 live sites and lots of test ones without a failure so I can't comment on how long it would take to unravel if it does go wrong. They've all been BS sites though.

Unfortunately I don't have access to the paypal account or logs. He reports he rarely (1 or 2 a month) would see a transaction not send the Order Process email with the PayPal Pro HS module. I recently enabled the PayPal Standard module for him, but I've been using it on my site for the last year and have never noticed a transaction not post the Order Process emails. They have duplicate code and the only difference in the stores is the catalog SKUs, and I have a different shipping module (a UPS mod) where as their store is all zones based to calculate shipping costs.

I'm going to take an hour and see if I can manage to get the PayPal app migrated on my store, and if that works then I'll migrate the other two sites. wish me luck!

Link to comment
Share on other sites

@mhsuffolk that's not a double IPN - it's one from the IPN (with IPN) and one from the customer coming back to the store first and completing the order in checkout_process. You'll  only get one [Transactions] history record if the IPN comes in before the customer or the customer doesn't come back at all.

@mattsc good luck!

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

11 minutes ago, mattsc said:

I recently enabled the PayPal Standard module for him, but I've been using it on my site for the last year and have never noticed a transaction not post the Order Process emails. They have duplicate code and the only difference in the stores is the catalog SKUs, and I have a different shipping module (a UPS mod) where as their store is all zones based to calculate shipping costs.

I just did a mod to the Paypal Standard module for a client this week - they didn't get any processing at all (the order still in preparing status) and didn't notice the payment email from paypal amongst all the others from ebay. That was likely a different cause though - there are corresponding red entries in the paypal log in osc admin because paypal didn't respond when osc attempted to verify both the IPN and the customer return to the store. The mod was to send an alert email when the notify seems to correspond to an order but paypal fails to respond to the verification request.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...