I'm having a problem with authorize.net and I'm hoping someone has an idea on how to fix it. On our website, we have integrated authorize.net into our shopping cart (using their Advanced Integration Method - AIM). When a customer clicks the final submit button, we do a real-time "authorize only" event on their credit card. We also have the address verification system (AVS) turned on. Authorize.net attempts to do the card authorization first, and if that succeeds, then they do the address verification. So what happens is sometimes a legitimate customer will put in the wrong billing address (e.g., moved recently, used work address instead of home address, etc.), which will result in a transaction being declined. However, in reality, the authorization on their card was approved, but since the AVS was declined, the overall status of the transaction from our end results in a decline. If a customer is using a debit card, the bank will withdraw the money immediately upon authorization, even if the AVS fails, because the authorization is done first. What we end up with are customers that never actually completed a sale, but still showing that we charged their card, or completed sales with duplicate transactions. These pseudo-charges can take up to 30 days to be removed from the customers account by the bank, and there is nothing we as a merchant can do to speed up the process. The banks have gotten even worse the past few months and often are hitting our customers with overdraft charges in these instances. Here is an example: - Customer has $500 in their checking account - Customer places a $300 order with us using their debit card. On the first submission, they put their new address, but the bank has not updated the AVS system, so the AVS fails, but the bank shows $300 withdrawn - Customer enters their old billing address and re-submits the transaction. This time AVS is successful. However, now the charge has gone through twice, so the bank has taken out a total of $600, and customer gets an overdraft fee. We are having these kinds of issues on a weekly basis now. Authorize.net claims they can't reverse the processing order to do AVS before authorization. There is also no way to do an "AVS only" type transaction. I can't believe that as big as authorize.net is, that nobody else is having this problem. I'm open to any suggestions on how to get around this issue. Thanks, Bill
2 questions... Did authorize.net confirm that AVS check occurs after an authorization is made. This is not the way it is supposed to happen. It sounds like you are declining on your application and not rejecting on the authorize.net level. I would double, triple check that first authnet is set to decline on AVS mismatches, etc. Feel free to post your authnet AVS setting here. I would next check to see if your application is looking at the AVS response at all, as it should only be looking at the approved, declined, or error response. Second question, is there a specific reason you are doing an auth only transaction?
This is what I got back from authorize after I basically asked them to reconsider: "We can not reconsider our policy. It is part of our agreement with the Card-Issuing Banks and the Payment Processors that we will only decline the transactions because of an AVS mismatch after the bank has already authorized the transaction. That is not something that we can reconsider or that we can do differently. I am so sorry about that." My application is only looking at the overall approval code to determine success. But if I login to their system on an AVS declined transaction, I will see it showing as declined, yet there is an authorization code and I can override the AVS error and do a manual forced capture. This is proof to me that the card authorization did in fact succeed, but that the overall status on my end is declined. We use "authorize only" during the checkout process because we may not ship the goods for a day or two, at which point we can use the prior auth capture function to actually charge the card. I don't think that should affect this issue though.
Clearly we see a flaw in their system. Pre-authorization I do not think it is settlement. I think it is a way to see if balance is available and probably a way to reserve funds. Sometimes some merchants preauthorize more than the actual value of goods or services like for example in gas pumping stations. Authorizenet to settle pre-authrization it does not give sense. If AVS is set first of all they should not preauthorize a payment request which fails AVS because the AVS feature says if a payment request does not meet the address check do not validate it. So Authorize.net they are contradicting themselves. It sounds the only option you have from their response is either to deal with it or change processor.
Your processor is actually the entity that assigns the AVS code. Authorize.Net just declines the transaction based on your settings. You can select or de-select any of your AVS settings. If you don't want Authorize.Net to decline transactions based on AVS you would have to de-select them. You are correct that an Auth-Only transaction will reserve the funds on your customer's bank account. Which is why you get the authorization codes...and you can do a Capture-Only with that authorization code. If you want to release your customer's funds sooner than the bank automatically does it (which could be anytime from 1 - 30 days), you can contact the customer's bank with the authorization code and your merchant ID from your Merchant Service Proivder, and you can try to request those funds be made available. Remember, funds on your customer's accounts are on hold (unavailable)...but they still have those funds...they just aren't available. Does this make sense?
What you are saying makes sense, but it is a lot of manual work which is what I am trying to avoid. Thanks.