We are testing the AVS system right now and we find it inconvenient that when the Address Validation fails it returns to our website with an error. It would make more sense to keep the user on the Payment Form and display the validation error at the top of payment form like it does for the missing required fields. Is there a way to not send the user back to our website on this user error?
I believe I read somewhere that the AVS is not 100% validated with the test accounts. Which contradicts what was told to me here when they said the test and live environments are virtually identical.
There are two different types of address validation, right? The one that validates if the address exists and the other that validates that the Credit Card address and billing address match up. Do those operate under the same service? If so, do you need to enable them separately?
When using SIM, the customer will always be directed to your relay response or receipt page when a transaction is declined due to address verification. It is not necessarily recommended to tell customers that this is the only reason that a transaction declined, as this helps fraudulant card testers confirm that the number and expiration date are valid themselves.
The sandbox environment only simulateds transactions and does not connect to any banking network. Therefore, it is not possible to verify the customer's billing address. You can simulate address verification statuses by following our Error Generation Guide.
Matching of the billing address to the shipping address is part of our Advanced Fraud Detection Suite. This is separate from billing address validation and can be tested in the sandbox environment.
Thank you for the response. But now something doesn't make sense...
We were told that a HOLD with the address verification functions the same way as a regular hold - the money is reserved but not charged:
Response Code 4: What kind of Hold is performed?
"In this case, the transaction will be authorized but not captured, which means the money will be reserved but not actually charged."
If your address verification fails with the Credit Card, and you have the setting on "Approve" or "Authorize and Hold For Review", then how is the money reserved? If the Credit Card is rejected, where is the money being reserved from? It seems impossible to take money out of a credit card that you don't have access to or doesn't exist. That would mean anyone could use any credit card number (by guessing or brute force), fail on the address validation, but put the hold on the money in that card (which could be captured later on). I really hope I am hearing this wrong.
How is Address Validation even an option in this case? To me, address validation should be something that done on every single transaction regardless of what the merchant wants. You shouldn't be able to take money out of someone's account unless you know their address.
You said that the test environment can only simulate with the Address Validation. What is the test environment doing exactly when Address Validation is on? Is it always just returning the Response Code Y if you don't use one of the special zip codes?
The decision of whether or not to use address verification is entirely up to you as the merchant. However, if you accept credit cards without performing address verification, the risk is that you are leaving yourself very open to the risk of chargebacks from cardholders. Merchant banks also assess various penalties for merchants that receive too many chargebacks.
The precise way that an amount is reserved upon authorization is dependent upon the card issuing bank. Some banks don't show this on the general customer statement until the amount is finalized, some of them subtract it immediately as if the charge was already complete and only correct it later after the authorization has expired.
For most transactions, Authorize.Net will signal to the card issuing bank to release the hold/authorization when the decision is made to decline the transaction. If the card issuing bank respects that signal, then the money will not be held for the customer for more than a few seconds after an address verification decline.
You are correct that Y is always returned in the test environment unless you use a specific zip code to simulate another response.