Post by StormDesigner » Thu Jan 04, 2018 12:05 am

Payment processes, shopper returns to the site with confirmation but then no order saved and items remain in shopping cart?

Details: Problem appears to be that orders placed on my cart using the authorize.net (sim) module are processing a payment, then returning to the cart which confirms the order was placed - BUT the order isn't saved as an order (neither pending, nor failed nor complete or anything) and the products return into the shopping cart as if the order was never completed. I spoke to authorize.net who indicated that this represents a callback timeout because (they suspect) that the clock on the server had not been advanced correctly, but inMotion (my host) indicated the clock was perfectly in sync with the us government clock. Anyone in the community have an idea why the payment would process but the order then returns into the shopping cart and never appears as an order? The Authorize.net technician seemed confident this would happen as a result of a clock timeout. Note that this was not happening last year (an order on 12/10/17 processed perfectly) but the order today (1/3/17) exhibited the odd behavior noted above.

:) If you want to save time, instead of reading the complete thread, note that the solution I stumbled upon was replacing the Authorize.net SIM payment module with the Authorize.net AIM module which worked perfectly! I thought it would require more advanced PCI compliance methods but was incorrect as cc info still never resides on my system. I only wish I didn't have to go through all of the following to figure that out. You can thank me whenever!

And I want to offer a special thanks to Straightlight for working diligently to try and help me overcome this directly. I appreciate your time.

Version: 3.0.2.0
Last edited by StormDesigner on Thu Apr 05, 2018 3:36 am, edited 3 times in total.

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by straightlight » Thu Jan 04, 2018 6:41 am

Authorize.net payment module complete name not provided. In the admin - > extensions - > extensions - > payment modules (x) page, click on the edit button on your Authorize.net and enable the debug mode. Then, test another transaction and either notice the log tab from the payment modules (x) page or see the most recent logs from your admin - > systems - > maintenance - > error logs page.

The most generated errors being found on Opencart forum originates from contributed programming. The increased counters are caused by posted redundancies of the same solutions that were already provided prior.

F. Rules:

- viewtopic.php?f=176&t=200480
- viewtopic.php?f=176&t=200804


Regards,
Straightlight


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by StormDesigner » Wed Jan 10, 2018 2:57 am

Hi straightlight and thank you! I did the tests as requested (I think I did them correctly) by placing the "Authorize.net (sim)" payment module in "Test Mode" (you suggested debug mode which I don't see there, guessing test mode is what they call that in this module). The only difference I'm seeing is that the system did appear to send me an Auto-receipt invoice (which I think was sent to me as a merchant, not as a client as it's just titled "Auto-Receipt" ( :-\ ). I don't see a "Log Tab" on or near the Payment Modules page. When I reviewed the "Error Logs" from "System > Maintenance > Error Logs" the most recent entry was "2017-08-15 1:55:38 - PHP Warning: mysqli::mysqli(): (HY000/1045): Access denied for user 'hiddenForSecurity'@'alsoHidden' (using password: YES) in /home/myDomain/public_html/myDomain.com/shop/system/library/db/mysqli.php on line 7" but this was apparently from August 15th -last- year. It also appears that even though I selected and saved myself in "Test Mode" that authorize.net did process the transaction normally so I should get my $1.00 back -.03¢. ( ??? )

The process still failed to "Save an order, send customer invoice or empty the cart*" Though cart appears temporarily empty on the "Thank you" page then fills back up when visitor clicks "Continue". Are there other physical log files I should review? I feel as though something broke on the Authorize.net side of this where the module, already tested and used and was fine and now is largely broken. I believe that this module would have been something built by authorize.net? Do you think there is validity to their claim that my server has the time incorrect by a margin? My host verified that I'm set to the US Government Universal time within moments or seconds and that should not be an issue. Please advise also if I misunderstood your instructions and thanks again for you concern and assistance.

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by StormDesigner » Wed Jan 10, 2018 3:31 am

WAIT, something to add, I just noticed that orders could have a status of "Missing" so I filtered the orders for that status and that these orders were in there! I hope that suggests something as to why orders returning from the Authorize.net SIM module (which are set in extensions manager to set orders to "Processing") is setting orders instead to "MIssing". When I go to look at the orders in the Sales > Orders, they appear to be "Cancelled". When I reset the order by updating it to "Complete" they now appear in the order history correctly. hmmm - what gives here?

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by straightlight » Wed Jan 10, 2018 7:27 am

Then, it is not an Authorize.net issue. It is rather an order status setting issue set from the admin.

The most generated errors being found on Opencart forum originates from contributed programming. The increased counters are caused by posted redundancies of the same solutions that were already provided prior.

F. Rules:

- viewtopic.php?f=176&t=200480
- viewtopic.php?f=176&t=200804


Regards,
Straightlight


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by beachgeek » Wed Jan 10, 2018 8:50 am

seems so but the big question is how to correct it?

Newbie

Posts

Joined
Tue Aug 02, 2011 1:37 pm

Post by straightlight » Wed Jan 10, 2018 8:51 am

Take a look at your Authorize.net payment module settings and your admin - > systems - > settings - > edit settings page regarding the order statuses.

The most generated errors being found on Opencart forum originates from contributed programming. The increased counters are caused by posted redundancies of the same solutions that were already provided prior.

F. Rules:

- viewtopic.php?f=176&t=200480
- viewtopic.php?f=176&t=200804


Regards,
Straightlight


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by StormDesigner » Wed Jan 10, 2018 11:26 pm

Within Extensions > Extensions > Payment > Authorize.net (sim) Payment module, I have "Order Status" set to "Processing" which (by virtue of language) seems correct (You sent your order, the payment appears validated but may not be in our accounts yet, so we're processing it now). Within System > Settings > Option (Tab) > "Processing Order Status" (detail): [Complete, Pending, *Processing*, Reversed, and Shipped] are selected so any of those statuses should confirm as an order. Below that on "Complete Order Status": [Complete, and Shipped] are both selected.

As an experiment I can set the modules "Order Status" to "Complete" but I don't like to do that because the order is really anything but complete at the point where the payment itself is authorized but not yet confirmed or even transferred. It sounds more and more to me like Authorize.net is providing an invalid response to/from their payment module; yet I can't imagine why I'd be the only person impacted by this.

Additional note, I have relay response URL set to:

Code: Select all

https://www.mydomain.com/shop/index.php?route=extension/payment/authorizenet_sim/callback
- just noting that as it is a critical URL for this transaction so if something is wrong there - thought it may be obvious to someone more familiar. Does anyone know for a fact that others are successfully employing the Authorize.net sim module? Should I rule out what Authorize.net phone tech support suggested regarding a timing/delay issue?
.

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by straightlight » Thu Jan 11, 2018 7:17 am

thought it may be obvious to someone more familiar.
In order to distinguish that assumption, you'd need to post the Authorize.net SIM debug report. So far, I have not seen any reports from the API noticing which side contains the issue - either the store or the provider.

The most generated errors being found on Opencart forum originates from contributed programming. The increased counters are caused by posted redundancies of the same solutions that were already provided prior.

F. Rules:

- viewtopic.php?f=176&t=200480
- viewtopic.php?f=176&t=200804


Regards,
Straightlight


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by StormDesigner » Thu Jan 11, 2018 10:01 pm

Thanks again for your persistent guidance. I did note that even though the authorizenet sim module was absolutely in "Test Mode" the transaction processed "fully" with the only exception (still) that the order status was set to "Missing Orders" - The process returned to the cart, payment was approved and did transfer. I expected test mode to not process the payment. Some things don't seem correct with this payment module.

But on this subject - I don't know how to get to that report. I checked the FTP directory files, OC user admin, and authorize.net admin and can't see any such report. Do you know how to access that or do I need to contact authorize.net?
.

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by straightlight » Fri Jan 12, 2018 6:21 am

I did note that even though the authorizenet sim module was absolutely in "Test Mode" the transaction processed "fully" with the only exception (still) that the order status was set to "Missing Orders"
May be so. Although, the debug mode report was not provided while testing your passed transactions while using the debug mode for Authorize.net SIM. Ensure to have it enabled from your admin payment modules page and test another transaction by providing the Authorize.net SIM events generated from the logs.

The most generated errors being found on Opencart forum originates from contributed programming. The increased counters are caused by posted redundancies of the same solutions that were already provided prior.

F. Rules:

- viewtopic.php?f=176&t=200480
- viewtopic.php?f=176&t=200804


Regards,
Straightlight


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by StormDesigner » Fri Jan 12, 2018 9:53 pm

I don't see a link to error logs, how do I access them?

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by straightlight » Sat Jan 13, 2018 6:32 am

StormDesigner wrote:
Fri Jan 12, 2018 9:53 pm
I don't see a link to error logs, how do I access them?
No mention of error logs on my previous post but I did mentioned the use of the debug mode though. Admin - > extensions - > extensions - > payment modules (x) - > Authorize.net (SIM) - > enable debug mode.

The most generated errors being found on Opencart forum originates from contributed programming. The increased counters are caused by posted redundancies of the same solutions that were already provided prior.

F. Rules:

- viewtopic.php?f=176&t=200480
- viewtopic.php?f=176&t=200804


Regards,
Straightlight


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by StormDesigner » Wed Jan 17, 2018 10:36 pm

I saw the "providing the Authorize.net SIM events generated from the logs" - not sure where I can view the "logs"? There is no control for "Debug Mode" within the (my?) Authorize.net SIM extension. I suspect "Test Mode" is their term for Debug mode? This *is* the screen I should be looking at, correct?
Image
I used "Test Mode", but in addition to not seeing any log tables, the transaction processed fully with no differences. (Full credit card transaction occurred including the bank account deposit) Still was no difference in the behavior though as the order form didn't process as required or send an invoice or order confirmation. Feels like Authorize.net's sim is buggy but if I'm the only one experiencing the issues then there might be something peculiar about my setup which is tripping it up. I'm getting concerned now as I have a potential client for their cart now and wish I could be more confident in the ability to fulfill a financial transaction. I'm going to try another small transaction today to see if anything was discovered and modified since on Auth nets side of this and, if not, give them a call.
.

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by StormDesigner » Thu Jan 18, 2018 12:23 am

I saw the "providing the Authorize.net SIM events generated from the logs" - not sure where I can view the "logs"? There is no control for "Debug Mode" within the (my?) Authorize.net SIM extension. I suspect "Test Mode" is their term for Debug mode? This *is* the screen I should be looking at, correct?
Image
I used "Test Mode", but in addition to not seeing any log tables, the transaction processed fully with no differences. (Full credit card transaction occurred including the bank account deposit) Still was no difference in the behavior though as the order form didn't process as required or send an invoice or order confirmation. Feels like Authorize.net's sim is buggy but if I'm the only one experiencing the issues then there might be something peculiar about my setup which is tripping it up? I'm getting concerned now as I have a potential client for their cart now and wish I could be more confident in the ability to fulfill a financial transaction. I did try a fresh transaction and so far same behavior. I called authorize.net who indicated that since they are returning the user with completed transaction this is something within opencart failing. I did check the error logs (System > Maintenance > Error Logs) Nothing in there since 10/8/2017. Gotta love when it "was working and suddenly isn't"
.
Last edited by StormDesigner on Thu Jan 18, 2018 9:54 pm, edited 1 time in total.

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by straightlight » Thu Jan 18, 2018 5:36 am

Let's troubleshoot this issue. In catalog/controller/extension/payment/authorizenet_sim.php file,

find:

Code: Select all

$order_info = $this->model_checkout_order->getOrder($details['x_invoice_num']);
add below:

Code: Select all

foreach ($this->request->post as $key => $value) {
    $this->log->write("AUTHORIZENET_SIM :: DEBUG :: " . $key . " => " . $value);
}
Then, make another test with the payment transaction and see your admin - > systems - > maintenance - > error logs page noticing the beginning of the: AUTHORIZENET_SIM :: DEBUG :: lines by looking at the most recent date and time periods.
Last edited by straightlight on Fri Jan 19, 2018 7:23 am, edited 1 time in total.

The most generated errors being found on Opencart forum originates from contributed programming. The increased counters are caused by posted redundancies of the same solutions that were already provided prior.

F. Rules:

- viewtopic.php?f=176&t=200480
- viewtopic.php?f=176&t=200804


Regards,
Straightlight


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by StormDesigner » Thu Jan 18, 2018 9:25 am

UPDATE - Atfer I got back to this I realized I had the script in the wrong location - so below until next red notes are from THAT where it was producing error codes.

Saw a couple of things, first that I think the error log post script may have been missing an enclosing ".

Code: Select all

$this->log->write("AUTHORIZENET_SIM :: DEBUG :: print_r($this->request->post, true)[color=#BF0000]"[/color])
Was that missing an ending " ? it was getting an internal server error so...

Then on the order form I saw this at the last step where it will pass me off to the authnet SIM page.

Unknown: Object of class Request could not be converted to string in /home/uName/public_html/stormdesigns.com/shop/catalog/controller/extension/payment/authorizenet_sim.php on line 13

That said, the order processed as it had been. When completed and after seeing the same outward results I reviewed the error log as indicated and noticed

2018-01-18 1:06:26 - PHP Unknown: Object of class Request could not be converted to string in /home/uName/public_html/stormdesigns.com/shop/catalog/controller/extension/payment/authorizenet_sim.php on line 13
2018-01-18 1:06:26 - AUTHORIZENET_SIM :: DEBUG :: print_r(->post, true)

2018-01-18 1:08:13 - PHP Unknown: Object of class Request could not be converted to string in /home/uName/public_html/stormdesigns.com/shop/catalog/controller/extension/payment/authorizenet_sim.php on line 13
2018-01-18 1:08:13 - AUTHORIZENET_SIM :: DEBUG :: print_r(->post, true)

Now with the script in the location as you indicated it is not writing anything to the error log. Is still (as expected) processing orders in the same manner.
Image
Out of curiosity I decided to also try using a "Check" order method, that worked completely as expected. Updated invoice correctly, sent email, everything. This is definitely specific to the Authorize.net SIM module. Very curious to know if others aren't experiencing this and why! ???

To me these appear more like errors in the script, but this may reflect something more about how I'm set up. I did NOT put this in "Test Mode" prior to the test purchase and have since commented out the line until we review if I'm missing a step. Does any of this mean more to you than what I'm seeing?
.

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by StormDesigner » Thu Jan 18, 2018 10:11 pm

Had an idea...

The authorize.net tech had mentioned something about timestamp being off to such a degree that it failed in this manner. I'd spoken to my hosting admin who indicated the server date/time is accurate to within moments. I did notice though, with these tests, that the time on the error logs is off from my EST/EDT by +5 hours. I'm wondering if that discrepancy can be adjusted within the SIM module or if I need to let authnet know what time the shopping cart is set to. Speaking of which, I didn't see a place from which I can adjust the carts time-stamp. That appears to be tracking to GMT/UTC.
PS: I tried adjusting the time() in the module by adding (time()-(5*60*60)) but authorize.net's response was simply "This transaction can not be accepted" - thought it was worth a shot.

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am


Post by straightlight » Fri Jan 19, 2018 7:23 am

Code modified above: viewtopic.php?f=198&t=200899&p=710997#p710997 . Try the new code instead.

The most generated errors being found on Opencart forum originates from contributed programming. The increased counters are caused by posted redundancies of the same solutions that were already provided prior.

F. Rules:

- viewtopic.php?f=176&t=200480
- viewtopic.php?f=176&t=200804


Regards,
Straightlight


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by StormDesigner » Fri Jan 19, 2018 7:30 pm

New code still not writing a comment to the error log. Last error code was yesterday's date and time and result of me (intentionally) fouling the script. (adding bad characters to force it to fail) how odd is this?

StormDesigns, Inc. Website Design and Web Application Development - plus graphic design and print media.

www.StormDesigns.com


User avatar
New member

Posts

Joined
Wed Feb 01, 2012 1:53 am

Who is online

Users browsing this forum: No registered users and 0 guests