Issuing banks consider manually entered (keyed) credit card information to have a higher risk of fraud. Two common fraud prevention options merchants can use to help reduce this risk are AVS (Address Verification Service) and/or CVV (Card Verification Data) when accepting card-not-present transactions, or when accepting manually-entered (keyed) input in card-present merchant locations. The use of these options also enable merchants to qualify for better processing rates.
Address Verification Service (AVS)
One mechanism for reducing the risk of fraudulent credit-card transactions is to obtain the cardholder’s address along with the credit-card data. The supplied address is checked through the issuing bank, and a result code is returned in the transaction response along with the card issuer authorization. This is known as Address Verification Service (AVS). Using AVS also enables merchants to qualify for better processing rates. Not submitting AVS on keyed transactions affects processing cost in all merchant categories (SIC codes) and may increase the risk of losing chargebacks for merchants.
- For better rates with Visa and MasterCard, submit AVS with at least the zip code.
- For better rates with Discover and Amex, submit AVS with street address and zip code.
Address Verification (AVS) results codes are determined by the card’s billing five or nine-digit postal code/ZIP and Street Address.
<AVS> <Address>4 Corporate Square</Address> <Zip>30329</Zip> </AVS>
Format:
Address: Alphanumeric. Length: min 1 max 20
Zip: for the U.S: numeric, for Canada: alphanumeric. Length: min 5 max 9
AVS Response Codes
Exact match (i.e., positive match) AVSResult codes of both Address and ZIP vary by card brand and whether a five or nine digit postal code/ZIP is used:
A = Discover (5 digit ZIP)
X = Discover and MasterCard (9 digit ZIP)
Y = American Express (5 digit ZIP), MasterCard (5 digit ZIP), Visa (5 and 9 digit ZIP)
Code |
Definition |
Explanation |
Recommended Actions | |
If submitted with Saleor PreAuth |
If submitted with ZeroAuth | |||
A |
Exact match |
(Discover) 5 digit Zip Code and address match |
Complete transaction |
Complete transaction |
Partial Match |
Street address matches, but ZIP Code does not match |
Evaluate, then Reverse/Void and retry with updated information or complete transaction |
Evaluate and retry with updated information, or complete transaction | |
*B |
Partial Match |
Street address matches; ZIP Code is in an incompatible format |
Evaluate, then Reverse/Void and process a 2nd authorization if updated information is provided |
|
*C |
Non-Compatible |
Street address and ZIP Code are in an incompatible format |
Evaluate, then Reverse/Void and process a 2nd authorization if updated information is provided |
Evaluate and retry with updated information, orcomplete transaction |
N |
No Match |
Street address and ZIP Code do not match |
Reverse/Void and process a 2nd authorization with updated information |
Evaluate and retry with updated information, orcomplete transaction |
R |
Retry |
Retry / system unavailable |
Reverse/Void the transaction and then Retry |
Retry orcomplete transaction |
S |
Unavailable |
AVS not supported (Discover, MasterCard and AmEx ONLY) |
Evaluate, Reverse/Void and ask for another form of payment orComplete transaction |
Evaluate, ask for another form of payment, orcomplete transaction |
U |
Unavailable |
Street and ZIP Code information unavailable |
Evaluate, Reverse/Void and ask for another form of payment orComplete transaction |
Evaluate, ask for another form of payment, orcomplete transaction |
W |
Partial Match |
No data from issuer or verification system |
Evaluate, Reverse/Void and ask for another form of payment orComplete transaction |
Evaluate, ask for another form of payment, orcomplete transaction |
X |
Exact Match |
Street address and Nine (9) digit ZIP Code match (MasterCard, DISC) |
Complete transaction |
Complete transaction |
Y |
Exact Match |
Street address and ZIP Code match |
Complete transaction |
Complete transaction |
Partial Match |
(Discover) address match, zip does not match |
Evaluate, then Reverse/Void and retry with updated information orcomplete transaction |
Evaluate and retry with updated information, orcomplete transaction | |
Z |
Partial Match |
ZIP Code matches, but Street address does not match |
Evaluate, then Reverse/Void and retry with updated information orcomplete transaction |
Evaluate and retry with updated information, orcomplete transaction |
IMPORTANT NOTE: Card Issuing banks may APPROVE a transaction and at the same time respond with an AVS “No Match” response. A transaction will NEVER decline based on an AVS mismatch. Regardless of the approval, if the AVS result indicates a no-match or is otherwise questionable (which could potentially result in a fraudulent transaction), payment applications should communicate the result along with the authorization response AND any applicable corrective measures.
In all cases of questionable or partial AVS results where the transaction is APPROVED by the issuing bank, your POS application should provide configurable merchant settings to:
- Display the mismatch to the end user,
- allow the option to reject the transaction immediately by running a Reversal-VoidSale,
- allow the option to both process a Reversal-VoidSale and to allow for re-entry of the mis-matched data; or
- allow the option to accept the transaction authorization “as-is” and by doing so, accepting the risk of the potential fraudulent transaction.
Card Verification Data (CVV)
Card verification data is referred to by several different acronyms: CVV2/CVC2 (Cardholder Verification Value)/CID (Amex and Discover). It is a three- or four-digit code found on the back of a credit card (for Amex it is on the front of the card) that is used when card information needs to be manually entered Mail Order/Telephone Order (MOTO) and eCommerce transactions, to determine that the card is physically with the customer who is placing the order, since the code can only be found on the card itself.
The CVV request data element is: <CVVData>123</CVVData>
Format: Numeric only. Length: Min 3 Max 4
For all manually entered transactions where Card Security Codes (CVV/CVV2/CID) data is supplied in the request, issuing bank result codes are returned in the transaction response along with the card issuer authorization:
CVV Code |
Definition |
Explanation |
Recommended Action | |
If sent with Saleor PreAuth |
If sent with ZeroAuth | |||
M |
Match |
The card security code supplied matches the value on the card. |
Complete transaction |
Complete transaction |
N |
No Match |
The card security code supplied does not match the value on the card. |
Evaluate, then Reverse/Void and retry with updated information (NOTE that Visa will DECLINE for CV2 FAILURE so no need to Reverse). |
Evaluate and retry with updated information. (Note: Visa will DECLINE for CV2 failure) |
*S |
Should be Present |
The security code should be present but the cardholder has reported that it is not. *This requires the CVV indicator be submitted. Mercury currently does not allow this to be configurable at the merchant level. |
Evaluate, then Reverse/Void and ask for another form of payment
or
Complete transaction |
Evaluate and ask for another form of payment
or
Complete transaction |
IMPORTANT NOTE: Card Issuing banks may APPROVE a transaction but at the same time respond with a CVV “No Match” response. Regardless of the approval, if the CVV result indicates a no-match or is otherwise questionable (possibly resulting in a fraudulent transaction), payment applications should communicate the result along with the authorization response AND any applicable corrective measures.
In all cases of questionable or partial CVV results where the transaction is APPROVED by the issuing bank, your POS application should build in configurable merchant settings to:
- prompt the mis-match to the end user,
- allow for the option to reject the transaction immediately by running a Reversal-VoidSale,
- allow the option to both process a Reversal-VoidSale and to allow for re-entry of the mis-matched data
- allow the option to accept the transaction authorization as is and by doing so, accepting the risk of the potential fraudulent transaction.
- avoid phishing threats for CVV data it is recommended to allow no more than three attempts that return a non-matching response.
ZeroAuth (Zero Authorization)
The ZeroAuth transaction enables merchants to validate a credit card without charging an amount to the cardholder’s account. It can also be used to request a token if you are using Mercury’s MToken solution in your POS. Example:
Request
<?xml version="1.0"?> <TStream> <Transaction> <MerchantID>118725340908147</MerchantID> <LaneID>02</LaneID> <!--for environments with multiple input devices--> <TranType>Credit</TranType> <TranCode>ZeroAuth</TranCode> <InvoiceNo>12345</InvoiceNo> <Frequency>OneTime</Frequency><!--Token Request--> <RecordNo>RecordNumberRequested</RecordNo> <Account><!--for swiped use Track2--> <AcctNo>4005550000000480> <ExpDate>12/15</ExpDate> </Account> <CVVData>123</CVVData<><!--CVV and AVS for fraud protection. CVV does not need to be sent with a swiped entry--> <AVS> <Address>4 Corporate Square</Address> <Zip>30329</Zip> </AVS> <Memo>MPS Example V1.0</Memo> <Amount> <Purchase>0.00</Purchase> Amount> </Transaction> </TStream>
Response
<?xml version="1.0"?> <RStream> <CmdResponse> <ResponseOrigin>Processor</ResponseOrigin> <DSIXReturnCode>000000</DSIXReturnCode> <CmdStatus>Approved</CmdStatus> <TextResponse>AP</TextResponse> <UserTraceData></UserTraceData> </CmdResponse> <TranResponse> <MerchantID>118725340908147</MerchantID> <AcctNo>XXXXXXXXXXXX0480</AcctNo> <ExpDate>XXXX</ExpDate> <CardType>VISA</CardType> <TranCode>ZeroAuth</TranCode> <AuthCode>VI0000</AuthCode> <InvoiceNo>12345</InvoiceNo> <AVSResult>Y</AVSResult> <CVVResult>M</CVVResult> <Memo>MPS Example V1.0</Memo> <Amount> <Purchase>0.00</Purchase> <Authorize>0.00</Authorize> <Gratuity>0.00</Gratuity> </Amount> <AcqRefData>KaNb014349100008543cRBCDd5e85fJlA m000005</AcqRefData> <RecordNo>BoPRWAadfR3cgsjazKpj+y/9CfSK2dzHmMYEt+QJ7MEiEgUQCSIQDmzC</RecordNo> <ProcessData>|38|210100700000</ProcessData> </TranResponse> </RStream>