1.5.7 Problems

[websmith]

After modifying the code as indicated when I tested refunds everything seemed to be OK but now that I have it working on the live sites I am seeing the following problem. (This is using PayPal standard module)


Intermittently PayPal orders come in with duplicate order confirmation copies with sequential comfirmation numbers and 1 PayPal payment. The PayPal transaction ID on the top of each confirmation matchs the payment. There is nothing in the log file indicating any type of error/problem.

The server has been updated to PHP 7.4 (error was seen while it was at 7.2 also) Apache has been changed to event MPM and HTTP2 is enabled OS is Ubuntu 18.04 and Zen-Cart 1.5.7. The only thing we have changed with PayPal was updating the module for the refunds.

Any thoughts how to resolve this issue? The system is giving very little to track the problem.

[mc12345678]

After modifying the code as indicated when I tested refunds everything seemed to be OK but now that I have it working on the live sites I am seeing the following problem. (This is using PayPal standard module)


Intermittently PayPal orders come in with duplicate order confirmation copies with sequential comfirmation numbers and 1 PayPal payment. The PayPal transaction ID on the top of each confirmation matchs the payment. There is nothing in the log file indicating any type of error/problem.

The server has been updated to PHP 7.4 (error was seen while it was at 7.2 also) Apache has been changed to event MPM and HTTP2 is enabled OS is Ubuntu 18.04 and Zen-Cart 1.5.7. The only thing we have changed with PayPal was updating the module for the refunds.

Any thoughts how to resolve this issue? The system is giving very little to track the problem.

In which log file are you looking/reviewing? Is this the standard logs directory with PayPal Standard set to do its normal thing, or where the module is setup to log information and/or send email with the output put to the same logs directory or the store's email account?

Also, while haven't seen in this thread that the correction for using the admin_notification system has been applied (https://github.com/zencart/zencart/pull/3769/files) it appears that perhaps something like it has been incorporated as refunds from within ZC have been made possible. Perhaps others trying to replicate the issue though will benefit from that additional information.

[websmith]

In which log file are you looking/reviewing? Is this the standard logs directory with PayPal Standard set to do its normal thing, or where the module is setup to log information and/or send email with the output put to the same logs directory or the store's email account?

Also, while haven't seen in this thread that the correction for using the admin_notification system has been applied (https://github.com/zencart/zencart/pull/3769/files) it appears that perhaps something like it has been incorporated as refunds from within ZC have been made possible. Perhaps others trying to replicate the issue though will benefit from that additional information.

I will answer best I can, but let me clarify the sequence of events. The sites were recently upgraded to Zen Cart 1.5.7 and PHP 7.4. One of the problems noted (that had been present since 7.2 PHP but not addressed) was that a php error was generated when PayPal was refunded using the standard module. DrByte provide a fix which was incorporated into the ipn_main_handler.php this update resolved the issue on the refunds, but now I am seeing this second issue. Since it was a change it is suspect that it is related to the new problem.

Your second question I am not sure how to answer this is the first I have seen of this change and although I read everything I could find with all the merging I did not find anything that stated what the problem was was in terms I understood. This change has not been made and until I understand what error it creates I would be hesitant to apply it.

The logs referred in the previous poste was debug logs that appear in the Logs folder, but mention of logs reminded me there are IPN logs which also show 2 entries for the orders with the duplicated invoices. The PayPal module itself does not have logging enabled since it is a live site.

[DrByte]

(This is using PayPal standard module)
Intermittently PayPal orders come in with duplicate order confirmation copies with sequential comfirmation numbers and 1 PayPal payment.
The PayPal transaction ID on the top of each confirmation matchs the payment.
There is nothing in the log file indicating any type of error/problem.

This is a common problem typical to using the PayPal Standard module, since it relies on ancient technology that was based on putting your products into PayPal, having people create a checkout basket on PayPal, submitting payments to buy those things, and then telling "your site" that a sale had occurred so you could fulfill orders. It was the first variant of PayPal payment processing, and was never (and still isn't) intended for online stores with their own catalogs and product management.
Standard doesn't give the store real-time verification that the payment has been completed. In fact, if the customer doesn't properly return to the store (clicking the Return button after payment is complete) and closes their browser, then no order will be stored at all, nor any confirmation email.
Instead, it posts an IPN "Instant Payment Notification" to the store, via the ipn_main_handler.php file which then attempts to re-instantiate the customer's session via very complex and fragile means, verify the incoming IPN is actually relevant to a current transaction (and not a spoof), and then stores the order, completes the sale, and sends the confirmation email. All out-of-band.
If IPN acknowledgements aren't responded to automatically then PayPal attempts the IPN again multiple times.
A PDT process attempts to do a payment verification "in-band" if the customer actually clicks to return to the store. This basically does the whole IPN thing as well. Hopefully before the IPN is actually sent from PayPal. This allows the order to be saved almost in-real-time, so the customer gets notification and a completed order while they're still on the checkout-success page.
There's a small possibility of a race-condition where the customer clicks the Return link at the same instant that PayPal sends the IPN, and both the PDT and IPN processes which are searching for the customer's account and session and inspecting the order don't discover that the other is already doing its thing, and thus each creates a sale, resulting in duplicates.
Further, if the IPN feature isn't turned on in the account, or if IPNs aren't acknowledged by the store for a period of time, PayPal will disable the feature on the account, meaning purchases made will never turn into actual orders in the store.
All this out-of-band, non-real-time stuff makes it rather unreliable (or unpredictable) and is exactly the reason why using PayPal Standard is not recommended. It purpose for still being in core code is (was) to support countries that can't (couldn't) offer Express Checkout while PayPal was still rolling it out around the world.
It will probably be removed in an upcoming Zen Cart release. Especially because I hate having to describe "why" it's unadvisable to use it, because it's so complicated.

But, ya, therein likely explains the cause of your duplicates.

[websmith]

Thank you, basically boiling it down you are saying switch to PayPal Express which is better aligned to do the job. I will start testing and see about converting.

I have been running the carts for several years, I started with standard and never had any problems with it. I had never seen the information you provide (and to be honest never looked because I never had a reason to). Now I know I will see if I can get them changed and avoid further problems.

[swguy]

This explanation was beautimous, and has been added to the documentation site.

[websmith]

Now I remember why I do not run PayPal Express.

It requires a separate account for each website. Both sets of my sites use a single bank account and are under the umbrella of the main company hence the necessary items to initiate separate PayPal accounts does not exist.

Not sure what I am going to do, even PayPal says to use PayPal standard for this particular situation. At this point still researching trying to find a solution that will resolve the issue.

[lat9]

Now I remember why I do not run PayPal Express.

It requires a separate account for each website. Both sets of my sites use a single bank account and are under the umbrella of the main company hence the necessary items to initiate separate PayPal accounts does not exist.

Not sure what I am going to do, even PayPal says to use PayPal standard for this particular situation. At this point still researching trying to find a solution that will resolve the issue.

Not true. If you contact PayPal Merchant Services and indicate that you'd like to create a parent-child business account, they'll be happy to oblige.

It winds up that you'll have a main account that's tied to your bank account (the parent) and each of your other companies will be its 'children' that can be set to auto-transfer funds daily to the parent for future pulling back to the bank.

[websmith]

I did not see anything like that in the information I read on the various accounts, they stated the main difference between standard and Express was the requirement for separate accounts, but what you said gives a ray of hope. I will talk with PayPal and see what is required and if this is a possible option. I thank you for the information.

[swguy]

Not true. If you contact PayPal Merchant Services and indicate that you'd like to create a parent-child business account, they'll be happy to oblige.

Cindy, when you get a second would you please post a link confirming this? I'll add it to the documentation.