There are longstanding threads here: #372272: Order status never gets further than 'pending' or In checkout #1317356: When users create orders, now the system puts the orders on "pending" #696850: UC roles and paypal standard, 30 day product not granting role, payment shows as 'pending'. I'm not going to relive it here, but I'm going to reopen it with the following:

Every so often I will get a block of 5-10 orders that will receive a proper payment from Authorize.net CIM Example:

Authorize.Net: CIM profile created - 1234567
2012-02-09 01:20 - Authorization and capture
ACCEPTED: This transaction has been approved.
Amount: $X
AVS response: Y - Address (Street) and five digit ZIP match

However, this shippable product will have its status set to pending instead of 'payment received'. Again, this will happen for a block of orders (usually sequential) and then begin working again.

Questions:

  • How on earth would I resolve this? I can order until I'm blue in the face on my local machine without any issues and then something trips.
  • Would I check the server log files? Would something like this appear in the watchdog logs?
  • Is there a test function that I can use to process 1000 orders to see if I can regenerate the occasional break?

I don't mind doing the legwork, but I'm at a loss where to start.

Difference from previous issues:

  • This is authorize.net CIM versus paypal w/IPN response.
  • I'm processing on the site versus outsourcing and redirecting back.

Comments

rickmanelius’s picture

rickmanelius commented

This problem continues to occur in the latest version.

Additional information:

  • Memcache is enabled on this server.
  • It goes in waves. That is, 100 orders will go to payment received, 20 to pending, and then they'll all return to payment received again.
  • The duration it trips off doesn't seem to correlate with anything I can find.
  • There are no log items in dblog that give insight as to what/where the issue is.
  • The user is logged in as expected.
  • The last item in order log comments is "Order created through website.'

This one might be the most insightful. Looking at order, it notified the customer at the 'pending' stage. But after it passed through granting the role and creating the order (at least that is the order in which the items are listed in the order log comments), the order is set to payment received.

I'm wondering if there is something batting out of order here... e.g. the order in which the actions firing off changes and in some instances the balance is not zero by the time uc_role is about to check.

How would one step through this? I have an authorize.net test account and will gladly make sure things are firing at the right time...

rickmanelius’s picture

rickmanelius commented

Edit: #287336: When selecting view products warning: Invalid argument supplied for foreach() in . This is actually just a theme issue on the front end. The actual product does appear when you visit the edit tab. Investigating more...

----
Found it!

The issue is that the order is going through as a $ amount and the product itself is no longer attached to the order.

So the error is more with respect to the order not properly retaining the product associated with the order and therefore not being able to trigger off any uc_role granting.

More coming soon...

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Category: bug » support
Status: Active » Closed (duplicate)

This is probably the same as #1450788: Inconsistent sales tax application -> memcache, load balancers, or configuration at fault? as the same site is involved and it appears to be memcache related.