Prevent Order on Credit Card Decline

[sweeperq]

Is there a way to prevent an order from being created if a credit card declines? I'm not talking soft failures like AVS mismatch, I'm talking straight up declines.

[jmestep]

That would be pretty complicated because the order is created and saved before the data goes to the payment gateway.

[plugables]

The order has to exist before payment can be made. If fact, when connecting to the payment gateway you also let it know the order id/number against which the payment is being made.

[sweeperq]

Good point plugables, I forgot that in AC5x the baskets were the orders, they were just missing the order number and the order date. They must have sent the order id instead of the order number with the transaction.

We might have to implement something like Amazon where we send them an automated email to inform them the card was declined and give them a URL to come back and make payment.

[sweeperq]

Couldn't AC make use of transactions here? Go ahead and create the order, but if the card has a hard decline, roll back the changes? Was looking at the code for OnePageCheckout and it looks pretty black box. Not sure I can even customize it to do what we want.

[Logan Rhodehamel]

There is a way to change the checkout handling so that if the card is declined the user is immediately shown the pay order screen with a warning that the payment did not go through. That's the best compromise we could offer quickly because the checkout flow is designed around the order being submitted first. (see viewtopic.php?f=42&t=7242&p=32112&hilit ... ing#p32112)

Way back when we thought this would be a well liked adjustment to checkout flow. The idea was to allow you to capture more potential sales. In practice it seems to have mostly caused frustration. In the future we are likely to return to a traditional checkout model and support the checkout always succeeds model as a store level option instead.

However even with transactions reconciliation with the payment gateway concerns me still. Imagine Joe comes along and tries to place an order, the transaction begins and we get order number 1. Order number 1 passes on to the payment gateway and the card is declined. Joe leaves the site because he is broke. Jill comes along a few minutes later and places an order. The transaction begins and we get order number 1 again. Order number 1 passes to the gateway and this time the card goes through.

I can't be sure how each gateway we support is going to react to that. Will the transaction history on the gateway merchant terminal be polluted with prior failed transactions? It will require some testing and research to make sure we don't cause new problems with that arrangement.

[jmestep]

I think that probably anything you do will cause problems for someone. I liked the new handle failed payments because that way you have an order and contact information and you can contact the customer and see if they want to try another payment method rather than just have them leave the site and not be able to place the order. In Able 5, I didn't like it the other way and didn't like the fact that the orderid got sent to the gateway because the order number wasn't created if the charge failed.
Once we explain to a client what is going on with a failed payment, they know how to react and often add more text to the pay my order page. But there are a few that don't like it because they don't want to deal with failed orders. An admin toggle on how to handle might be good and maybe an option to delete the order on failed payment would be good for some merchants. Delete it even before the order confirmation email gets sent. But then you would have merchants who wouldn't want to see a gap in order numbers.

[sweeperq]

Thanks for the comments everyone.

Logan, I understand your concern about rolling back the Order Numbers. If it were determined that was indeed an issue, gaps in order numbers wouldn't kill us. Maybe a checkout request could reserve an order number. If it succeeds, when the basket gets converted to an order it would be assigned that order number. If it fails, it remains a basket and the order number gets thrown away; or maybe is associated with the basket so if they do make a successful payment it gets assigned. While gaps in order numbers is not a problem for us, it could be for some of your other customers.

We also see Judy's point about having the customer information and being able to possibly close some additional sales. So we came up with a hybrid solution...

We changed our flow to work within the system. We added a new order status of Declined and set it to trigger on Failed Authorizations so the declines are not mixed in with the rest of the orders. We turned on the HandleFailedPayments flag and added some custom messaging on the order payment page so the customers know what to do when the card declines. If they end up making a successful payment, it will be moved out of Declined and into the normal order queue. When our Customer Service Manager checks orders, they have a list of the Declined orders and can decide whether to contact the customer or cancel the order.

We also changed our settings in the Authorize.net Fraud Detection Suite so that it does not "Hold" authorizations. When an authorization was held for review in the Fraud Detection Suite, the authorization was being reported as failed to AbleCommerce. This introduced issues because:
1) Held authorizations were basically treated as Declined
2) We had to log into Authorize.net several times daily to VOID or APPROVE authorizations
3) If we APPROVED the authorization in Authorize.net, it did not notify AbleCommerce. This meant we had to capture payment in Authorize.net, delete the existing payment in AC, and add another bogus payment in AC.

So, we changed the Fraud Detection Suite settings from "Hold for Review" to "Report Only". The suspect authorization passes through as a normal authorization, but we make use of the Authorize.net Reporting API to query against the Transaction ID and determine which Fraud Filters were tripped. We give the transaction a Fraud Score and if it is above a certain threshold it ends up in a "Review" Order Status. The View Order page was customized to visibly show a green (ok) or red (bad) status for each of the Authorize.net fraud filters on the last transaction. The customer service manager can look at the visualization and decide which orders can be moved to the normal order queue and which to Void Payment and Cancel Order.

[AbleMods]

Joe leaves the site because he is broke

It seems you know me all too well