Authorize.net - are CCV and Address truly optional?

Question

The Authorize.net DPM example code has only CC# and Exp. Date fields, and works without issue in the sandbox. But what about the other fields I've grown accustomed to filling out?

CCV Field

In the DPM documentation the only mention of a CCV field (x_card_code) is buried deep in the table of "Response Reason Codes". Why is it not listed in the API fields table next to x_card_num?

Address Field

According to the DPM documentation, the Billing Address is optional, and only used for the Address Verification Service (AVS).

I assume AVS is useful, but documentation like this hardly provides a concrete answer:

Most banks and Merchant Service Providers require merchants to use AVS in order to avoid non-qualified transaction surcharges (typically an additional 1%). If your business has a low factor of risk, or potentially paying a non-qualified discount rate will not adversely affect your business, you might consider being lenient in your application of AVS.

Questions:

• What happens if I don't collect any data other than CC# and Exp. Date?
• Why does the documentation hint at CCV checking, but not list x_card_num in the table? Is this not an important field?
• Without using AVS, would transactions be at a higher risk of being declined?
• Is there a definitive list of recommended fields or best practices?
• Why are the base requirements so lenient? Aren't there drawbacks?

---

All I want to do is set up a simple payment form and ensure nobody has trouble paying.

Am I missing something or does the documentation have as many holes as it seems?

Answer 1

The simple answer to all of this is that submitting those fields contribute directly to higher success ratio. You'll collect cards that were issued from various issuers, each having its own risk policy. Some consider non-AVS transactions coming from the web to be of higher risk, and reject them.
You'll have much higher chances of successfully charging the card if you collect all the optional data (especially CCV).
That said, the more input you ask from your user, the more likely she is to bail out of that annoying checkout page.
What most shops do is experiment a bit - starting with a full blown form (inc. CCV, AVS, card-type, etc.) and start dropping fields every few days to check if the conversion drops. It usually drops dramatically when the CCV is omitted.
Another useful piece of information - if your customers are globally distributed, the risk of decline increases dramatically as most issuers consider foreign transactions with caution.

Answer 2

What happens if I don't collect any data other than CC# and Exp. Date?

Then you don't submit it. There are very few required pieces of information to successfully process a transaction. But business rules may dictate otherwise.

Why does the documentation hint at CCV checking, but not list x_card_num in the table? Is this not an important field?

It is not required to process a transaction. But it is handy for reducing fraud and may be required to keep their rates at a minimum. If the merchant doesn't care about fraud or their processing fees, this field is not useful or necessary to collect.

Without using AVS, would transactions be at a higher risk of being declined?

No.

Is there a definitive list of recommended fields or best practices?

This will vary by card type. But generally always send over the card number, expiration date, cvv, address, and amount. If you will be processing level three cards there are other required pieces of information but i cannot name those off of the top of my head.

Why are the base requirements so lenient? Aren't there drawbacks?

Omitting certain pieces of information can result in:

1. Higher fees - AVS and CVV are not required to process a transaction but are required to keep fraud incidences low. Not performing AVS and CVV results in a higher incidence of fraud and this is passed on to the merchant in the form of higher fees for those transactions.

2. Higher fraud - AVS and CVV both together and combined with other methods can greatly reduce fraud for a merchant. Not capturing that information significantly increases a merchant's chances of experiencing loss due to fraud.