AVS mismatch leads to pending transaction for bank cards.

[codethisdb]

Currently I am experiencing a frustrating scenario, hopefully someone has a possible solution.

I submitted an order on my companies website and purposely entered an incorrect address in an attempt to have access to both ends of the failed transaction that our customers are experiencing.

The order is submitted, an AVS mismatch is returned, and an authorization from the bank for the full amount is approved and awaiting collection.

I dont experience this on other sites when entering an incorrect address. I do receive the AVS mismatch notification but no pending charge is placed on hold from my bank account.

We have been back and forth with Authorize about how to handle this.

I would assume the initial auth should be for $0.00 to collect the address info and perform the AVS check and then an auth for the full amount would be done as to not impose a pending charge on our customers bank account. Especially when they submit multiple failed attempts and lock up all of their funds and are unable to make a purchase.

The responses we've had is this is the way it is for all payment gateways however I do not seem to experience this on any other site but ours.

I need to know where the problem lies, is there something that needs to change in our account settings? Does the problem lie in our code?

Any advice is appreciated, thank you.

[grantoz]

I'm from the UK, and have only just started working with Authorize.net, having worked with a variety of card processors over here.

I don't know about other U.S. card processors, but AVS checking certainly doesn't work like that in the UK - the AVS check is carried out before the card auth is attempted!  Which means in the event of an AVS failure you don't get one or more auths hanging around on the card and possible denying the customer any credit.

I don't know if other U.S. card processors do what Authorize.net do, but you guys are getting a raw deal if it's true that they all do this.

What I have done for now is to make AVS checking much more permissive on our Auth.net merchant settings - but this is not an ideal solution.  

I too would like to find out if there's any way of circumventing this very undesirable behaviour of the card processing interface.

Cheers,

Grant

[Michelle]

Hi there,

There is no way of doing the AVS check prior to the authorization, so your assumption is correct. If you want to validate AVS before processing the transaction, then you'll need to do an authorization only transaction for $0.00. Then run the authorization for the full amount if the AVS check passes.

Thanks,

Michelle

[tommytl]

In this Wikipedia article:

"An authorization hold can be canceled by the merchant if the merchant uses an acquirer that supports a process known as authorization reversal. Different acquirers place different restrictions on the conditions that must be met for the merchant to make an authorization reversal, but it is typical that the reversal must be made very shortly (generally within a minute) after the original authorization. In cases where the merchant cannot perform a reversal, but wishes to cancel the authorization it is typical that the merchant would contact the acquirer by telephone. Alternatively the cardholder may contact the issuing bank to request cancellation."

Does authorize.net support cancelling an authorization like this?

[Trevor]

The ability to void authorizations is available, but until recently has not been widely supported by credit card processing platforms.  Authorize.Net has supported this capability for some time on both the TSYS and Chase Paymentech platforms.  Last year Visa introduced new rules mandating that this be supported to avoid penalties, as a result, most processors now support this functionality or are currently building it into their system.  Unfortunately, in order for Authorize.Net to provide this to our merchants, we must implement the functionality individually for each processor and we can only begin this process once they have implemented it themselves.

Recently, we have added support for these full reversals with Global Payment Systems (GPN) and Elavon.  We expect that within the coming weeks we will add support for at least 2 additional processing platforms.  Unfortunately, each release requires completing a certification process with each platform that is not entirely within our control.  As such, I am unable to provide specific dates.  There are also still multiple platforms that have not completed implementing support on their end. When possible, we will provide updates on which platforms support these reversals.

Please note that this is currently specific to Visa transactions.  Recently, Mastercard and Discover have introduced similar rules.  However, the implementation of these rules for each card type is separate, meaning that we must again wait for each platform to implement the new functionality so that we can in turn support it in our system.  It is our hope that this will happen more quickly than implementation of the Visa rules.

For each transaction which does support full reversals, Authorize.Net automatically issues a reversal when the Address or Card Code verification systems cause a decline.  A reversal signal is also sent when a transaction is manually voided.  In these circumstances, you will generally find that the Authorization Code is no longer visible to you within the transaction details.  Transactions run on the TSYS platform are currently an exception to this rule which will be updated in an upcoming release.

[EarlyImpact]

Hi Trevor,

Could you clarify whether a "void" and a "full authorization reversal" are the same thing on an authorized transaction? For example, let's say that for the purpose of checking the validity of a credit card before setting up a recurring billing profile in ARB we want to validate the card (there is a thread on this that we are participating to):

• We validate for $0.01 (as zero dollar authorizations are not supported by all processors)
• We void the transaction

Will the merchant incur the VISA Misuse of Authorization System fees?

Thank you very much.

[CDeCinko]

Realize that if you do an auth first to check the card, and then do an auth and capture for the real amount, you will be charged TWO transaction fees by Authorize.net.  For a small site that might not be much, but when you're talking about 20,000 transactions, that fee will nickle and dime you right out of your profits.

[TJPride]

Depends I would guess on the number of declines and what the ratio is between payment amount and the 10-cent fee. If you're charging $2 transactions, you're in trouble, but if you're doing $100+, it isn't going to matter -that- much except to annoy your accountant.