I am finding it hard to understand this... if I process a succesful transaction, Auth-Only or Auth-Capture, I can perform a Void via the gateway and the charge is removed from the customer's bank. This has the affect of releasing the funds back to their account, as if the charge never happend.
However, if I process a charge that results in an AVS failure, which I then chose to decline, the AuthNet gateway does not automatically nor allow me to manually cancel or void the pending transaction with the customer's bank. My customer then ends up overdrawn due to the holds placed for purchases never completed.
I have tried to perform a void on the declined transactions, as they have a valid TransID and AuthID, but the gateway reports that the transaction cannot be found! This is most definetly a bug in the AuthNet system. The merchant interface shows the transaction but the gateway does not.
I would also recommend that Authorize.Net modify their systems to automatically void/release the customer's funds when a transaction is declined for any reason.
09-30-2009 02:35 PM
@CDeCinko wrote:I would also recommend that Authorize.Net modify their systems to automatically void/release the customer's funds when a transaction is declined for any reason.
This is not something Authnet can do as it is the responsibility of the merchant account provider. Authorize.Net cannot release funds or otherwise affect an account. They merely facilitates the communication of information between your code and the acquirer.
10-01-2009 08:38 AM
AuthNet already performs this task when a succesful transaction is voided before it is settled. Why can this not also be done for declined transactions?
@stymiee wrote:
@CDeCinko wrote:I would also recommend that Authorize.Net modify their systems to automatically void/release the customer's funds when a transaction is declined for any reason.
This is not something Authnet can do as it is the responsibility of the merchant account provider. Authorize.Net cannot release funds or otherwise affect an account. They merely facilitates the communication of information between your code and the acquirer.
10-01-2009 08:41 AM
@CDeCinko wrote:AuthNet already performs this task when a succesful transaction is voided before it is settled. Why can this not also be done for declined transactions?
@stymiee wrote:
@CDeCinko wrote:I would also recommend that Authorize.Net modify their systems to automatically void/release the customer's funds when a transaction is declined for any reason.
This is not something Authnet can do as it is the responsibility of the merchant account provider. Authorize.Net cannot release funds or otherwise affect an account. They merely facilitates the communication of information between your code and the acquirer.
Authnet doesn't do it. The merchant account provider does it. Authnet is only a facilitator, they do not actually do any of the processing of the transactions. The issues you are having are not Authnet related but processor related. They apparently are handling approved transaction differently then AVS declined transactions.
Your solution probably is a programmatic one. Instead of having Authnet decline the transaction for you, you should be checking the results of AVS through the AIM API and voiding the transaction yourself. That would solve all of your issues and is easy as heck to program.
10-01-2009 08:46 AM
So, your solution would be...
1. Turn off AVS declines in the AuthNet interface, allow all transactions to be approved no matter if they pass or fail an AVS check.
2. Upon a successful transaction, check the response code for AVS. If AVS pass, continue, no change.
3. If AVS fails, then immediately perform a void on the transaction.
Questions:
1. Won't this result in higher fees due to an increase in transactions? Now, instead of a single transaction to handle a failed AVS, AuthNet will charge us also for the void?
2. Will the AVS failure code be stored in the AuthNet database so at a later date we can look up why a transaction was voided? AVS failures would no longer show in the daily log as declined and could become harder to reconcile as the number of voids will increase.
10-01-2009 09:17 AM
@CDeCinko wrote:So, your solution would be...
1. Turn off AVS declines in the AuthNet interface, allow all transactions to be approved no matter if they pass or fail an AVS check.
2. Upon a successful transaction, check the response code for AVS. If AVS pass, continue, no change.
3. If AVS fails, then immediately perform a void on the transaction.
Yes.@CDeCinko wrote:Questions:1. Won't this result in higher fees due to an increase in transactions? Now, instead of a single transaction to handle a failed AVS, AuthNet will charge us also for the void?
You would incur an additional transaction fee to preform each void. Based on the man hours it is costing you to deal with the customer service issues arising from the AVS-declined transactions the extra 5 or 10 cents per transaction would actually cost you less money since I'm sure whomever is handling the customer service issues costs more then that in salary. Plus save you bad word of mouth from angry customers.
@CDeCinko wrote:
2. Will the AVS failure code be stored in the AuthNet database so at a later date we can look up why a transaction was voided? AVS failures would no longer show in the daily log as declined and could become harder to reconcile as the number of voids will increase.
Don't quote me on this as I araely look up transactions in Authnet's control panel, but I believe the AVS result is saved with the transaction information so you should be able to research it at a later date even if the transaction is voided. But I would like a confirmation from an Authnet moderator if possible so we can be 100% sure. Worst case scenario is you store your voids in a database with all pertinent transaction information. Then you always have an easy to access record of them and it probably would make reporting easy, too.
10-01-2009 09:31 AM
From my experience, I don't think that that scheme will have the desired effect. We had a problem with our server last week, and some customers had multiple charges due to multiple clicks. We quickly voided those transactions before they were captured and explained to the customers what happened. However, we had one or two customers who called two days later asking why they still see multiple charges in their account. So our voiding the charges did not prevent them from showing up in the account. The charges were eventually reversed but not before they caused anxiety on the customers.
One thing I'd like to have a representative from Authorize.Net confirm is whether or not the AVS process is part of the authorization. My understanding is that Authorize.Net obtains AVS information in a separate process and possibly from a source different from the issuing bank. I know that with our card processor, we have the ability to verify billing address. So the billing info must also be available from other than the issuing bank. Can an Authorize.Net employee confirm my understanding?
Thanks.
Uly
10-16-2009 08:13 AM
Hi Sir
Is there any way to pass amount for void transaction ?
Thanks
Manish
04-13-2013 01:09 PM
No. read the void transaction
04-14-2013 01:55 PM