Error 10415

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:

Attachment #15264

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] =>
)

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

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!

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.

jeking:

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.

@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.

mc12345678:

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

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. :)

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.

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?

mc12345678:

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

What's a 'vacation'?

I've heard and read some good things about them, but never had any personal experience. :-(

Cheers
Rod

barco57:

Directly addressing the php, sendmail versus smtp,smtpauth issue.

I've never considered this to be an issue. They are simply different methods used to achieve a certain outcome.

barco57:

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,

The question here is do you know why it is this way? (hint: The Email transport method descriptions in the ZenCart settings actually contains the clues/answer(s) to this).

Knowing how/why something does what it does can take a LOT of 'guesswork' in knowing what is best to use for any given situation/circumstance.

barco57:

which could lead to delivery issues.

Entering an invalid email address, using an invalid port#, and a zillion other things could also "lead to delivery issues".

barco57:

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.

Errr, the 'visible FROM: field' will be the most 'recent' FROM field contained in the message. There can be several/many FROM fields in any given message. What ends up in the 'final' message received by the recipient is controlled by many factors that are dependent on the path that the message travels and the configuration of the software doing the processing.
To state that PHP will add 'this header' or sendmail will add 'that header' or SMTP will add another, or the fact that any of these processes can also remove these headers (and even change them) at any point in the processing (even up to the final delivery into the recipients mailbox) actually negates any claims any one method could lead to delivery issues not experienced with with one of the other methods.

The message headers are little more than a diagnostic tool (that can be also used to control various aspects of delivery (or to reject delivery), and really shouldn't be considered as anything more than that.

Whether the inclusion or exclusion of a particular header has any effect on the final delivery is actually a function of the receiving server, not the transport method used to send them.

barco57:

As someone who works in hosting I would say it's always preferable to use smtpauth, when possible.

As someone that also 'works in hosting' (since 1997) I'm inclined to disagree with this (up to a point). One could argue that PHP is the best method (from a hosting perspective) because it adds a 'wrapper' to the sendmail function, and this wrapper can more easily be used to prevent unwanted messages reaching the sendmail server than feeding the mail directly to sendmail (or qmail, or whatever). The use of 'wrappers' for this purpose is nothing new or unusual, in fact most hosts/servers use 'TCP Wrappers' to help protect many server services (SSH being a classic example.

As a sidenote, sendmail is an SMTP server, so if/when it is argued that SMTP/SMTPAuth is somehow better or more secure than sendmail, it is just like arguing that SMTP is better or more secure than SMTP, which clearly makes no sense at all.

Then try to argue that SMTP 'direct' is better or more secure than a PHP wrapper around the sendmail/SMTP process, you are actually saying that removing this protection wrapper somehow increases security - Which makes even less sense than arguing that SMTP is better than SMTP.

By 'you' I am referring to anyone that also sees things the way you (apparently) are, I'm NOT specifically targeting you (or any other individual).

As is my way, I'm merely trying to explain things as they really are, which more often than not is a lot different than what many people think.

This is also why people get so easily confused as to what transport method they should be using because there isn't really a 'best' method. If that was the case zencart wouldn't have a need for so many options/alternatives. It would simply be hard coded to use this 'best method' and everyone would be happy and a discussion such as this would never eventuate.

Am I being pedantic/picky about this? Perhaps I am, but if it wasn't for people such as myself trying to separate fact from hearsay then the world will slowly sink into blissful ignorance with the impression that computers are little more than magic boxes that no one really understands. Will my attempts to educate make any difference? Probably not, but that doesn't mean I shouldn't at least try, otherwise I'd just be part of the problem rather than part of the solution.

Does anyone actually need to know this information? Probably not, well, not unless you happen to work in 'the hosting business', in which case I'd suggest that it is all essential knowledge, because unless you know how such things work, how can you possibly hope to keep things secure?

Again, nothing personal intended.

Cheers
RodG

smtpauth

The question here is do you know why it is this way?

The main reason I use it is because DrByte said it was a more reliable choice. Some may translate more reliable to being more secure. Before you ask, I can't go back and find the particular thread or post; nor did I ask for the logic that went along with the statement.

RixStix:

smtpauth

The main reason I use it is because DrByte said it was a more reliable choice.

LOL. Dare I say, but if that's what DrByte said then I'm not going to argue the point.

I do tend to advice that no one should ever fully trust a single source of information though (especially if I'm the source) <g>

RixStix:

Some may translate more reliable to being more secure.

Some might, but I have a very reliable car, and one of the doors doesn't lock.
The translation doesn't seem to work in this case :-)

RixStix:

Before you ask, I can't go back and find the particular thread or post; nor did I ask for the logic that went along with the statement.

No need. I am fully aware of DrBytes views/comments (and agree with him).

My stance is that because SMTP is always the peer-peer transfer protocol, regardless whether it is via sendmail, qmail, with or without auth, and with or without a protection wrapper (PHP) then both logic and common sense dictate that PHP has to be the most 'secure' - albeit, a little less reliable because of this extra security layer.

On the other hand, SMTP (all flavours) are more reliable, but less secure for the exact same reason.

This is the old triangle game, there's security, reliability, and ease of use. Pick any two.

Cheers
RodG