Enabling Fraud Prevention on MercuryPay

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)

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:

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>