AnsweredAssumed Answered

CVV and AVS Response Codes - inconsistent behavior

Question asked by yabadabadoo on Jul 14, 2017
Latest reply on Jul 16, 2017 by jbevington

Like • Show 0 Likes0
Comment • 3

Hello,

I am unable to get the expected CVV and AVS response codes to come back from the test platform.

I'm not sure why. The behavior I'm seeing isn't very consistent.

I'm sending in the right values as far as I can tell.

As an example, I'm trying to simulate a specific AVS response test-case from your certification script.

I'm using Visa test-card #1. I'm sending in the AVS Address of "123 AVE R" and a ZIP-code of "12345" as specified in the test-case.

However, instead of getting the expected AVS response of R, it came back with an AVS response code of N.

Any direction that you can provide would be appreciated!

Thanks!

paulblick Jul 14, 2017 2:50 PM

Correct Answer

Hello Fred,

When testing for specific CVV or AVS response codes, you may need to include a specific CVV/AVS trigger value to get the expected result.

As an example - for the test-case you are working on:

In order to get the AVS response-code of "R" that you're looking for, you actually need to include a specific CVV trigger value - in this case the CVV value of 000 should be submitted.

I checked our reporting system - it looks like you sent in a CVV value of 123. Although this is what's printed on the card as the correct CVV value, the AVS response code you're trying to trigger will require that CVV 000 be used instead.

Here are the main things to keep in mind:

For AVS
If NOT using

Address: 150 Mercury Village

Zip: 81301 or 813011234

then, use CVV 0000 (Amex) or 000 (Disc, MC, Visa).

Otherwise, if you're using the values above, the standard CVV of 123 is used to provide the expected result.

---> Alternately, do not include a CVV value at all - that should also cause the appropriate response code to be returned.

For CVV

When attempting to simulate U or P CVV response codes on specific cards, you will need to use these AVS values:

Street: NO1

ZIP: 12345

---> Alternately, do not include any AVS values at all- that should also cause the appropriate response code to be returned.

Please feel free to contact me with any additional questions or concerns.

Big thanks to jbevington for these details regarding MercuryCert.Net!!!

- paulblick

See the reply in context

No one else had this question

Outcomes

paulblick Jul 14, 2017 2:50 PM

Hello Fred,

When testing for specific CVV or AVS response codes, you may need to include a specific CVV/AVS trigger value to get the expected result.

As an example - for the test-case you are working on:

In order to get the AVS response-code of "R" that you're looking for, you actually need to include a specific CVV trigger value - in this case the CVV value of 000 should be submitted.

Here are the main things to keep in mind:

For AVS
If NOT using

Address: 150 Mercury Village

Zip: 81301 or 813011234

then, use CVV 0000 (Amex) or 000 (Disc, MC, Visa).

Otherwise, if you're using the values above, the standard CVV of 123 is used to provide the expected result.

---> Alternately, do not include a CVV value at all - that should also cause the appropriate response code to be returned.

For CVV

When attempting to simulate U or P CVV response codes on specific cards, you will need to use these AVS values:

Street: NO1

ZIP: 12345

---> Alternately, do not include any AVS values at all- that should also cause the appropriate response code to be returned.

Please feel free to contact me with any additional questions or concerns.

Big thanks to jbevington for these details regarding MercuryCert.Net!!!

- paulblick

2 people found this helpful

Actions

jbevington Jul 16, 2017 6:59 PM

Greetings Fred--things have progressed a long way in Bedrock since the days of the gravel pit! For fraud protection on manual entered credit cards, your merchants will appreciate the additional layer of Address + Zip (AVS) and/or the card's security code (CVV). Even Bam-Bam will like the ease of how our test environment simulates these complex and card brand specific responses! At it's simplest, our test simulators send back three kinds of responses based on the AVS and CVV trigger values you supply:

Something either matches or does not. AVS uses Y (yes) and N (no) CVV uses M (match) or N (no match)
Part of the values supplied match, but another part does not. This is used by AVS: A when the address only matches and Z when the Zip only matches.
The third and more problematic kind of response is when the system generating the response is either unavailable or incapable of responding. Typically you will see a U (system unavailable or issuer does not support), an R (retry) or an E if the request errors.

AVS and CVV can be tested independently or sent together in the same transaction request. If sent together, the test may require a special trigger value. Be sure to reference the transaction review for a deeper dive into these triggers. This is, by the way, always true for this third kind of response--U, R and E.

The use of AVS and CVV is a great way to add a layer of fraud protection for your card-not-present merchants. It is important to make this available to your merchants so they have the option to make the best business interpretation of the response. Issuing banks will still approve the transaction even if the AVS or CVV are incorrect. If selling high-end pterodactyl hand bags, the merchant should opt for tighter controls; if selling low ticket carry out, maybe less restrictive. Where a N sends a clear red flag, a U does not necessarily mean the card is fraudulent, just that the system is unavailable.

Keep up the good work Fred and a hearty "yabba-dabby-doo" to you!

1 person found this helpful

Actions

3 Replies

paulblick Jul 14, 2017 2:50 PM
Unmark Correct
Correct Answer
Hello Fred,

When testing for specific CVV or AVS response codes, you may need to include a specific CVV/AVS trigger value to get the expected result.

As an example - for the test-case you are working on:
- In order to get the AVS response-code of "R" that you're looking for, you actually need to include a specific CVV trigger value - in this case the CVV value of 000 should be submitted.
I checked our reporting system - it looks like you sent in a CVV value of 123. Although this is what's printed on the card as the correct CVV value, the AVS response code you're trying to trigger will require that CVV 000 be used instead.

Here are the main things to keep in mind:
- For AVS
  If NOT using
          Address: 150 Mercury Village
          Zip: 81301 or 813011234
      then, use CVV 0000 (Amex) or 000 (Disc, MC, Visa).
      Otherwise, if you're using the values above, the standard CVV of 123 is used to provide the expected result.
---> Alternately, do not include a CVV value at all - that should also cause the appropriate response code to be returned.
- For CVV
     When attempting to simulate U or P CVV response codes on specific cards, you will need to use these AVS values:
          Street: NO1
          ZIP: 12345
---> Alternately, do not include any AVS values at all- that should also cause the appropriate response code to be returned.

Please feel free to contact me with any additional questions or concerns.

Big thanks to jbevington for these details regarding MercuryCert.Net!!!

- paulblick
2 people found this helpful
Like • Show 2 Likes2
Actions
jbevington Jul 16, 2017 6:59 PM
Mark Correct
Correct Answer
Greetings Fred--things have progressed a long way in Bedrock since the days of the gravel pit! For fraud protection on manual entered credit cards, your merchants will appreciate the additional layer of Address + Zip (AVS) and/or the card's security code (CVV). Even Bam-Bam will like the ease of how our test environment simulates these complex and card brand specific responses! At it's simplest, our test simulators send back three kinds of responses based on the AVS and CVV trigger values you supply:
1. Something either matches or does not. AVS uses Y (yes) and N (no) CVV uses M (match) or N (no match)
2. Part of the values supplied match, but another part does not. This is used by AVS: A when the address only matches and Z when the Zip only matches.
3. The third and more problematic kind of response is when the system generating the response is either unavailable or incapable of responding. Typically you will see a U (system unavailable or issuer does not support), an R (retry) or an E if the request errors.
AVS and CVV can be tested independently or sent together in the same transaction request. If sent together, the test may require a special trigger value. Be sure to reference the transaction review for a deeper dive into these triggers. This is, by the way, always true for this third kind of response--U, R and E.

The use of AVS and CVV is a great way to add a layer of fraud protection for your card-not-present merchants. It is important to make this available to your merchants so they have the option to make the best business interpretation of the response. Issuing banks will still approve the transaction even if the AVS or CVV are incorrect. If selling high-end pterodactyl hand bags, the merchant should opt for tighter controls; if selling low ticket carry out, maybe less restrictive. Where a N sends a clear red flag, a U does not necessarily mean the card is fraudulent, just that the system is unavailable.
Keep up the good work Fred and a hearty "yabba-dabby-doo" to you!
1 person found this helpful
Like • Show 1 Like1
Actions
- jbevington @ jbevington on Jul 16, 2017 7:03 PM
  Mark Correct
  Correct Answer
  MercuryPay - Manual Entry and Card-Not-Present Fraud Protection
  Like • Show 0 Likes0
  Actions

CVV and AVS Response Codes - inconsistent behavior

Outcomes

Related Content

Recommended Content