Stuck in Pending

are there any clues in the admin order that eShop sends out?

Tjhanks for replying, and actually, in that store we don’t get the admin order email – It goes straight to the customer… There aren’t many orders, but we’ll have to test it…

As there has not been an update to this topic for a while, I can only assume that the issue has now been resolved and I am now marking it as such. If this is incorrect, please feel free to change the topic’s status and/or post a follow-up.

This got set aside while catching up with things after holidays. Sorry for the delay – this still hasn’t been resolved.
And there’s nothing in the admin order of any help. It’s just the normal report with the customer info and order.
The one thing I noticed at auth.net is that it took about 3 days for the payment to finalize. So I would have to assume the information that auth.net returns to eshop after the person submits the payment is a code saying that the payment is processing rather than complete.
If that’s what could be causing the order to stay in pending – could that be edited in the eshop authorize.net file to say the order has been completed?
I also noticed the site thank you page now shows through more of an iframe at auth.net rather than just returning back to the site itself.
This all seems to be a recent change, but I don’t know if it’s a change in eshop or auth.net.

could that be edited in the eshop authorize.net file to say the order has been completed?

The order can only be marked as completed if eShop has received the completed code from Authorize.net.

I also noticed the site thank you page now shows through more of an iframe at auth.net rather than just returning back to the site itself.

That’s always how Authorize.net has worked and there’s nothing we can do about it. Unlike (say) PayPal, there is no option to return the user back to your site – only show a page from your site in a frame at Authorize.net.

That all makes sense. Do you know if this was a recent change with auth.net? (not the thank you page return of course)
The orders were going into completed before. Them going into pending was just recent. Which I can understand is going to happen if it’s taking a few days for auth.net to complete the payment and returning a code specifying that it’s processing – but as far as I can guess, they were returning a completed code before so the orders would go directly into completed rather than pending.
And thank you for your help on this, sorry we delayed in responding initially.

Do you know if this was a recent change with auth.net?

What change? We’ve had no reports of issues with the latest version of eShop and Authorize.net in the plugin’s dedicated forum.

For what it’s worth, I just tested a purchase on another site we have with eshop, and had the same issue – I was left hanging at this URL https://secure.authorize.net/gateway/transact.dll as the end user, and logging into WP admin I see that the transaction ID doesn’t get assigned – just in pending and saying Processing…

I’m sorry but right now, we cannot replicate your issues.

Okay thanks for the fast replies and i’m hoping Dzynit (our programmer) can chime in with any details…

Scott, on the other site you tested on – it will need the redirect page set in auth.net. That’s why it’s fully hanging there.

esmi, I see a new version released last night. So once I can test that upgrade I can let you know if the issue might be resolved.

After upgrading to the latest eshop version, we still have this issue. All auth.net orders stay in pending and the customer never receives their eshop receipt email with the download links.

On the one site that was still sticking in a hanging state at auth.net, the only way I could get the site’s thank you page to show is to hardcode the thank you url right in the auth.net files of eshop. The other site worked correctly just by setting the thank you url in auth.net as you’re suppose to. I believe the site that required the hardcoding is because that auth.net account contains several thank you urls, so since eshop doesn’t send that info when you check out – auth.net doesn’t know what url and uses the default of just showing only their receipt.

Right now, I can deal with that frustration – but the order MUST finish processing so the eshop receipt is sent to the customers. Several sites have downloads and the customers aren’t getting their links after payment.
The other payment options are working correctly, it’s specific to auth.net. I know the eshop site repeatedly says “no support for auth.net” but if it’s included in the plugin, I feel that it should work. When the orders don’t complete processing, we don’t get an email even letting us know someone put in an order – just an auth.net notice of a payment. And the customers are getting angry that they’re not getting their product after they’ve paid.

Can we please get more assistance with this?

Thanks, Heather

I believe the site that required the hardcoding is because that auth.net account contains several thank you urls, so since eshop doesn’t send that info when you check out

Why do you have multiple thank you urls?

For two of the sites where it’s not working, (both selling downloadable products), there are multiple “thank you” URLs in the Auth.net account because we have one credit card processing account that accepts charges from more than just one site –

Two of the sites are eshop, and another one is a web hosting company that auto-charges and accepts instant payments. The Auth.net account has been this way since 2002, accepting payments for multipole sites, and Eshop has been on the two for a couple of years, and we never had this Auth.net problem before.

We also have had a Zencart store processing to this same Auth.net account without issue for over 5 years.

On the second site (client) where this is happening, which is selling physical dvd for shipping there are not multiple “thank you” URLs in Authorize.net

All I can suggest is that you downgrade eShop to a version that was working previously.