Error 10415

[jeking]

We recently switched from PayPal Standard to PayPal Express and PayPal Pro. Client is now getting a few duplicate orders and almost all show in Zen Cart without any of the order data. See screenshot:



I've enabled dedugging and is seems this is the problem, but I don't understand what it means or how to fix it.

May-06-2015 13:03:19 (1430935399)
before_process - EC-5
resultset:
Array
(
[TIMESTAMP] => 2015-05-06T18:03:19Z
[CORRELATIONID] => e18e1d5611ff6
[ACK] => Failure
[VERSION] => 61.0
[BUILD] => 16566018
[L_ERRORCODE0] => 10415
[L_SHORTMESSAGE0] => Transaction refused because of an invalid argument. See additional error messages for details.
[L_LONGMESSAGE0] => A successful transaction has already been completed for this token.
[L_SEVERITYCODE0] => Error
[CURL_ERRORS] =>
)

[jeking]

The fix was to change the email transport method from smtp to php.

[Dreamer40]

Thanks very much for posting your fix! I have been plagued with the same issue and same PayPal error over the last few months so bit the bullet and switched from PayPal Standard to PayPal Express. The issue seemed to go away but this week one in 4 orders has been a double order and like you one of each of the orders had no PayPal transaction details. At least under PayPal Standard I just had duplicate orders but only one payment but with Express I was getting two payments as well.

After some testing and troubleshooting the problem seemed to be a large delay (up to 30 secs) between clicking on 'Confirm The Order' and being returned to the account to download. I initially assumed it was PayPal related but then found that free orders could be very slow as well:

01/06/2015 01:51:55 - /index.php?main_page=checkout_payment (0.166s)
01/06/2015 01:52:02 - /index.php?main_page=checkout_confirmation (0.243s)
01/06/2015 01:52:27 - /index.php?main_page=checkout_success (0.235s)

Having switched from smtpauth to php the checkout is now instant so hopefully the duplicate order issue will stop.

01/06/2015 04:01:26 - /index.php?main_page=checkout_payment (0.182s)
01/06/2015 04:01:29 - /index.php?main_page=checkout_confirmation (0.186s)
01/06/2015 04:01:32 - /index.php?main_page=checkout_success (0.179s)

I had noticed that I occasionally wasn't getting order confirmation emails so I did wonder if it was email related.

I use GMAIL as my provider and the emails are still coming through but are there any downsides of using php instead of smtpauth?

Although I wasn't hopeful it would fix the issue at least this has forced me to start looking at upgrading (1.3.9h > 1.5.4) so I am well down the path to achieving that!

[mc12345678]

Php email is not considered as secure a method. I believe this is covered in the FAQ area.

As for the email, why not an email account associated with your host/server instead of a generic gmail account? There have also been posts about using alternative email accounts as well and the problems associated.

[badarac]

The fix was to change the email transport method from smtp to php.

Jim,
What led you to the transport method as a possible cause from this error message? Rich is very curious.

[Dreamer40]

@mc12345678, thanks very much for your feedback. I will do some more research on a better solution but at least the problem appears to be sorted for now.

Google hosts the email system for my web site so the emails appear to come from it rather than a random Gmail account. It has been working fine for nearly 4 years and although my memory is a bit hazy now I think I did it to make it easier to interface it with my personal account and also monitor my emails all from one place.

The world and available solutions have moved on a lot in that time so it is probably a good time to have a review.

[RodG]

Php email is not considered as secure a method.

No email is secure, and the two words should never be used in the same sentence, unless it is to say no email is secure. :-)

PHP, sendmail, qmail. SMTP, SMTPAuth, etc, etc, all (ultimately) transfer the emails using the SMTP protocol.

Encryption (assuming that is what you mean by 'secure') is a different kettle of fish, as are the methods of authentication (if needed).

One must not use the term 'secure' so loosely for fear of deceiving thyself and others. ;-)

Cheers
RodG

[mc12345678]

Ahh, Rod. Back from vacation it seems. :)

Besides that I was short on available time when written, the product (email) was not at all the object of "concern". Instead it was the method of creation that I was attempting to address (method). I used to provide better email discussion assistance but that was when I was still trying to get a grasp on that aspect of ZC. Now that I have "settled in" on using smtpauth, parts of that have escaped me. But I recall the FAQ being helpful in the general aspect with subtle issues to be addressed in the forum.

Neigh do I consider email as secure regardless... All that can be asked is to do the best with what is available, support those that make improvements for us all and don't needlessly open the door to allow the nasties in. :)

[barco57]

Directly addressing the php, sendmail versus smtp,smtpauth issue. Depending on server setup (partly because I am not sure in all cases) php, sendmail will show the email as being sent from (NOT the FROM: field) user@servername instead of [email protected] as smtp,smtpauth does, which could lead to delivery issues. The visible FROM: field will still be filled out with what you set in the store admin, but if you were to view the headers of the email you would likely see [email protected] buried in there. As someone who works in hosting I would say it's always preferable to use smtpauth, when possible.

[Dreamer40]

Thanks for the info. You are correct. The headers in my more recent emails show my server console login then in brackets envelope-from [email protected] whereas the old ones appear to come directly from [email protected].

I wonder why the php emails seem to get to Google's servers in seconds whereas when I use smtpauth with smtp.gmail.com the delay can be 30 seconds or more?