Enabling Fraud Prevention on MercuryPay

Document created by chadb on May 10, 2016Last modified by Chris Jennings on Jun 1, 2016
Version 5Show Document
  • View in full screen mode

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> 

Attachments

    Outcomes