Fraud prevention and protection are getting out of hand.
How can that statement be true when $9 billion was lost to actual payment card fraud in 2014? Well, that same year merchants lost $118 billion to false positives (i.e. the legitimate customers turned away). Today, the false positive decline rate is 3 times the rate of existing card fraud.
Merchants can no longer chalk up these losses to the costs of fraud. These are legitimate missed revenue opportunities caused by overly-strict front-end solutions. Protection on the front-end needs to be sufficient enough to protect retailers from large-scale attacks, but not so strict to the point where false positives run rampant.
To accomplish this, Visa recommends four front-end fraud prevention solutions for ecommerce merchants to secure and validate payment applications: Verified by Visa, Address Verification Service (AVS), Card Verification Value 2 (CVV2), and CyberSource.
1. Verified by Visa
Verified by Visa relies on the 3D Secure Protocol to make ecommerce transactions more secure. 3D Secure serves as the mechanism to ensure payments are made by the valid owner of the Visa account at the time of an online purchase. Implementing Verified by Visa not only helps build consumer confidence in shopping online, but also helps merchants by providing an additional level of security prior to authorization.
Merchants utilizing Verified by Visa can even see a decrease in chargebacks. First and foremost, fraudulent chargebacks and associated losses are prevented. Secondly, for qualified transactions, liability shifts from the merchant or acquirer to the issuer. Either way, Verified by Visa is a great way to prevent fraud-related customer disputes. At the end of the day, Verified by Visa improves payment security and reduces friction. Which means positive impacts on consumer confidence and merchant profitability.
2. Address Verification Service (AVS)
The second fraud prevention tool recommended by Visa is Address Verification Service (AVS), where the billing address is validated with the issuer at the time of authorization. AVS is incredibly helpful in determining if the person using the card is actually the cardholder.
AVS can only confirm addresses in the United States and Canada. Merchants need to include the cardholder’s street address and or zip or postal code in AVS requests. The AVS request itself can be transmitted in two different ways: included in the authorization request or by itself. If transmitted by itself, an AVS request returns a result code to merchants indicating whether or not the address given matches the address on file at the issuer for the cardholder.
Once a result code is received, merchants should evaluate the response and take appropriate action based on transaction characteristics as well as other verification information included in the authorization. Remember, an authorization response should always take precedence over AVS. Transactions that are declined should not be accepted even if the AVS response indicates a match.
AVS Result Codes
The issuer’s response to a merchant’s AVS request comes in the form of an AVS result code. Some acquirers may modify the single-character alpha AVS codes provided by Visa to make them more self-explanatory. For example, instead of providing a “Y” response, the acquirer may show “exact match” or “full match.”
|AVS Result Codes|
|Code||Definition||Code Applies to|
|A||Street address matches, but the ZIP code does not. Acquirer rights not implied.||✓||✓|
|B||Street addresses match. Postal code not verified due to incompatible formats. (Acquirer sent both street address and postal code.)||✓||✓|
|C||Street address and postal code not verified due to incompatible formats. (Acquirer sent both street address and postal code.)||✓|
|D||Street addresses and postal codes match.||✓|
|F||Street address and postal code match. (Applies to U.K. only).||✓|
|G||Address information not verified for international transaction. Issuer is not an AVS participant, or AVS data was present in the request, but issuer did not return an AVS result, or Visa performs AVS on behalf of the issuer and there was no address record on file for the account.||✓|
|I||Address information not verified.||✓|
|M||Street address and postal code match.||✓|
|N||No match. Acquirer sent postal/ZIP code only, or street address only, or both postal code and street address. Also used when acquirer requests AVS, but sends no AVS data in field 123.||✓||✓|
|P||Postal code match. Acquirer sent both postal code and street address, but street address not verified due to incompatible formats.||✓||✓|
|R||Retry. System unavailable or timed out. Issuer ordinarily performs AVS, but was unavailable. The code R is used in V.I.P. when issuers are unavailable. Issuers should refrain from using this code.||✓|
|S||Not applicable. If present, replaced with “U” (for domestic) or “G” (for international) by V.I.P. Available for U.S. issuers only.||✓|
|U||Address not verified for domestic transaction, issuer is not an AVS participant, or AVS data was present in the request, but issuer did not return an AVS result, or Visa performs AVS on behalf of the issuer and there was no
address record on file for this account.
|W||Not applicable. If present, replaced with “Z” by V.I.P. Available for U.S. issuers only.||✓|
|X||Not applicable. If present, replaced with “Y” by V.I.P. Available for U.S. issuers only.||✓|
|Y||Street address and postal code match.||✓|
|Z||Postal/ZIP code matches, street addresses does not match or street address not included in request.||✓||✓|
3. Card Verification Value 2 (CVV2)
The third fraud-prevention tool Visa recommends is to submit Card Verification Value 2 (CVV2) alongside other transactional data for electronic authorization. CVV2 is simply the three-digit security number printed on all Visa card’s signature panels. It helps to validate that the customer is in possession of the card at the time of purchase.
Ecommerce merchants can properly process CVV2 submission by asking customers for the last three numbers in or beside the signature panel on the back of their Visa card. If a CVV2 is provided, submit it along with the expiration date, account number, etc., for authorization. Along with the CVV2 itself, merchants should include the applicable CVV2 presence indicator, even if CVV2 is not included.
|CVV2 Presence Indicators|
|If||Send this Indicator to the Card Issuer|
|You have chosen not to submit CVV2.||0|
|You included CVV2 in the authorization request.||1|
|Cardholder has stated CVV2 is illegible.||2|
|Cardholder has stated CVV2 is not on the card.||9|
CVV2 Result Codes
The issuer will include a CVV2 result code in its response to a merchant’s authorization request. As with an AVS result code, the merchant should evaluate the CVV2 result code alongside the transactions other characteristics, particularly authorization response, and then take appropriate action.
|CVV2 Result Codes|
|M – Match||Complete the transaction (taking into account all transaction characteristics and any questionable data).|
|N – No Match||View the “No-Match” as a sign of potential fraud and take it into account along with the authorization response and any other questionable data. Potentially hold the order for further verification.|
|P – Not Processed||View the “Not Processed” as a technical problem or the request did not contain all the information needed to verify the CVV2 code. Resubmit the authorization request.|
|S – CVV2 should be on the card||Consider following up with your customer to verify that he or she checked the correct card location for CVV2. All valid cards are required to have CVV2 printed either in the signature panel or in a white box to the right of the signature panel.|
|U – Card issuer does not participate in the CVV2 service||Evaluate all available information and decide whether to proceed with the transaction or investigate further.|
For merchants utilizing CVV2, it’s critical to remember that storing a cardholder’s CVV2 is strictly prohibited subsequent to authorization.
Finally, Visa recommends choosing CyberSource (a Visa company) to facilitate online payments. CyberSource is a payment processor allowing merchants to securely accept payments across mobile, web, call center, and even POS sales channels, on a global scale. Whether the merchant uses one-time, recurring, or installment payments, CyberSource can make it happen.
An important feature in the CyberSource solution is payment tokenization. Tokenization allows merchants to process payments and refunds without handling or storing payment data. Removing this payment data from a merchant’s network is the best way to keep it safe. Sensitive payment information is replaced with a unique identifier (aka token), while the actual payment data is stored in CyberSource’s Visa-operated data centers.
These are the best Visa fraud prevention tools that will help merchants avoid significant losses for online purchases. If merchants have physical locations in addition to an online presence, Visa also promote better card security through chip technology and chip-activated terminals.
Front-end fraud solutions shouldn’t turn away hoards of legitimate customers. Instead, stick to the core fraud prevention tools recommended by Visa and a robust post-transaction fraud management solution.
Other Fraud Prevention Tips
In addition to the fraud prevention tools listed above, here are some useful fraud prevention tips that can help protect merchants, improve security, and defend against fraud.
A BIN check is where the merchant checks the first six numbers of a card (the Bank Identification Number) and looks to see if the cardholder and the bank that issued the card are in the same country. A BIN check is quick and can usually serve as an early red flag for possible fraud.
Negative Historical File
All merchants should keep an extensive server database they can reference that outlines in detail all of the chargeback records, fraud attempts, problematic customers, and patrons who have received refunds. The information kept within this database should include credit card numbers, shipping/billing and IP addresses, names, phone numbers, and any additional comments from the merchant. With the data stored in this way, merchants should be able to reduce the number of repeat incidents. This negative historical file can even be shared with other merchants. The more data on hand from multiple parties, the more adept merchants will be at stopping repeated fraud attempts so future suspicious orders can be denied.
Fraud Pattern Detection
At the same time, data can be checked to discern patterns that may indicate fraud. For example, if numerous orders are going to the same address, but different cards are used for each order, that may indicate something shady. Another possible pattern of fraud could be if multiple credit card numbers used for orders being sent to the same address differ by a few digits. Patterns like these could indicate fraud, though they should still be treated only as a possible sign. Merchants can always investigate further once they have permission.