payment module generating spurious "order already processed" errors

[Kent Multer]

Hi folks,

Is there a full moon this week? No? Darn, I can't use that excuse .. I'm having an odd problem with a custom payment module. It works flawlessly when I use the store with Firefox, but fails every time when using Chrome. I hope one of you has seen something like this, and can help me find the cause.

When we test the module using Chrome, it always gets an "order already processed" error. This is a false error message. We can tell that the orders are actually getting processed correctly. They show up just fine on the Order Processing admin page, and the confirmation emails go out as expected. The problem seems to occur only after all that is finished, when the store tries to render the INVC page.

I did some searching in the LSK source code, and found that the "order_alreadyprocessed" exception code is called in five places. Four of them are in the processing of the AUTH action. The fifth one is in the Merchant_Screens() function, in the part of the code that handles the INVC page; I think this must be where the error is being generated.

The relevant code looks like this:

<MvIF EXPR = "{ NOT g.Basket:order_id }">
    <MvFUNCTIONRETURN VALUE = "{ UIException( 'order_alreadyprocessed' ) }">
<MvELSE>
    ... (normal INVC page rendering) ...

So the cause must be that the variable g.Basket:order_id is zero.

The module is keeping a log file of its activities. The log provides further confirmation that g.Basket:order_id contains the correct value all the way through the processing of the payment and creation of the records in the order-related tables. So why would it be changed to zero after all that is done, but before the rendering of the INVC page? And why would this happen when using Chrome, but not Firefox?

I suppose the answer must be related to cookies and session management. Maybe there's something slightly off in a cookie value, and Chrome is stricter than Firefox about accepting it.

Another possibility is that something is causing the store to try to render the INVC page twice. I've occasionally seen behavior like this when working on other projects. When I'm testing a component module, I sometimes see debugging messages or log-file entries that show that the component is initialized twice, even though the page is only displayed once. Not sure if that's relevant in this case, but it could certainly explain the "already processed" error. If the duplicate processing is triggered by some Javascript, that would explain why it is browser-dependent.

Before I do any more digging into this, I wanted to ask if any of you know what's causing this? Have you seen anything like this before?

Thanks --

[Bruce - PhosphorMedia]

Don't know why, but it sounds like something is interacting with chrome and the 'single' post you do to INVC is actually causing chrome to sumbit twice. I've had expiranced this myself (non-miva site) while using chrome but since these where not my sites, had no way of looking into why...best i got.