Credit card rejected/declined, order goes through anyway

Not sure... I've seen some interesting behavior during development of the Card on File module in conjunction with relation to Authorize.Net as well. I always assumed the completed orders were just something funky with my development, but it could be there's a bug to root out in the Auth.Net code. Moving this issue to that queue.

I've encountered this as well. In my case, a customer entered incorrect billing address info, and Authorize.net returned an appropriate error, which was displayed when the page rebuilt, but the credit card form didn't render. Thus the user read the error, corrected their address info, and clicked "Continue to next step". Since the credit card form wasn't rendered, the Authorize.net verification and submit callbacks for the credit card form weren't called, and the cart moved to Pending.

I reproduced it myself once, but couldn't in subsequent attempts. Heisenbugs are tricky. But this seems to be an important one. Hopefully it's something that can be tracked down. If I find a workaround in the mean time that doesn't feel too nasty or risky, I'll post it here.

Thanks for looking into this, Ryan. I've been using Commerce in several projects this year, and it's one of the better-maintained and nicely constructed modules on D7 right now.

Do you have the commerce module configured to require a payment before proceeding with order?

This is in the store config admin settings.

Otherwise customer can view their order and add a payment later if they have authority to for that. This seemed too cumbersome so I restricted to requiring the payment before order is created.

Any tips on where you've set this up in the store/config/admin settings -

I'm assuming you've just added a condition to the Rule "Update the order status on checkout completion" - requiring an order balance of 0.

Is there another spot I'm missing that anyone is aware of?

This is a SCARY use case in real world deployment BTW.

We are seeing something similar to this on our DC site as well. Instead of card being declined, I am seeing it marked as a dupe and then charging.

According to watchdog, an order was submitted and a response back from Authorize.net says it was a duplicate order (its not- and they still charge the card), the order does not move to pending, so the user then fills out the form again and resubmits (order goes through, card is charged- a second time).

Not sure if this is related or should be a separate issue, but mine was APPROVED by auth.net (test mode) and i got emails and everything, but there is no order created?? Let me know if I should create a separate issue for this, but this was the first test I ran and it failed...

The order likely was created, but if checkout didn't complete, it would still be in the "Shopping Carts" tab on the Orders page.

no shopping carts listed...i checked in the DB and they were indeed created, but in Pending status and i just noticed that the default 'update the order state' rule is set to put the order in pending? why would that be the default? is that all there is to it? change the rule to move it to Complete when it's done? seems so, as i changed that rule and did an order and it works...clearly my issue was unrelated (sorry for the hijack) but still curious about the default rule being set to pending!?

Yeah, Pending is the default because we have no way of knowing in core what payment method or workflow anyone will have. You can alter that default checkout completion rule to meet your needs or add another that maybe changes the status on payment completion. However it works for you, it's there for you to customize. : )

i won't reopen myself, but i think i kinda hijacked this issue with my problem and the OP may still be relevant...may need to be reopened if the others above are still having their problem. sorry.

Ahh, you're right. Reopening, though this has been answered a couple times now in the core Commerce queue. Basically, if the payment pane is moved to the first page but there's still a review page after it - or if it's on a page with other panes and one of those panes fails validation - the payment will still attempt to process. We don't have a core way yet of either a) delaying payment processing until every other pane has ensured it has valid data or b) instructing payment modules to only authorize but not capture payment if there are additional steps after that one in checkout.

Something to figure out in the near future.

Tagging this as a release blocker in an attempt to define what issues are blocking a stable release (see #1621368: Create a stable release of commerce_authnet (beta or greater)). This problem seems kinda major to me because such a misconfiguration would routinely allow authorize.net and DC to get out of sync (e.g. auth.net accepts while DC thinks it was rejected and vice versa).

At the very minimum, there should be a way to warn a site builder that configuring a checkout process in a certain way could lead to that situation. Otherwise this will keep coming up again and again.

fwiw, there's a patch in the Commerce queue that I'll be committing prior to 1.4. In the meantime, I've documented the best checkout pane configuration on the project page's installation notes. See: #1415670: Some CIM Orders Stuck In Checkout

1.4 has now been released