DataWedge October 2009 Newsletter

This month just as we were dabbling around with the inital newsletter topic this month, an issue pops up in the "bottom of the ninth" that in itself is worth dedicating an entire newsletter to.

Seems that one of our RDS's got to be unfortunate recipient of a series of orders using stolen a credit card... and in the process unwittingly uncovered one of the credit card industries "dirty little secrets".

First, a review:

When you process a credit card, the credit card processor determines a rate for EACH AUTHORIZATION. Everyone knows that there is no one "magic formula" for this... it has to do with everything from the TYPE of credit card used (Signature, Corporate, Check-Card) as well as the "risk assesement" of the authorization itself (CVV2 match, Zip code Match, etc).

It's no secret that the merchants are the one paying for the additional loyalty or rewards points when a customer opts to use of these credit card.

But what IS a dirty little secret is that the credit card processor IS assigning a higher authorization charge (risk assessement) for credit cards that are approved... even though they themselves are not 'responsible' for a chargeback in the event of a stolen card.

Translation: the credit card processors are charging the MERCHANTS an additional fee for "non-matches" on address and CVV2... but then pocketing the difference when it comes time to pay out in the case of a chargeback for a stolen card.

In addition... no credit card processor issues a DECLINE in the case of an Address or a CVV2 code not matching... they just charge a higher rate for approving the card.

Normally, chargebacks are of the "few and far between" variety, and the costs of the chargebacks have normally been chalked up to the costs/risks associated with doing business.

In DMS, the data obtained in regards to Address Verification and CVV2 was more closely associated with obtaining the best rate when getting an approval, and thus the response data was thus left to be seen as part of the batch reports in order to correct it for the LONG term....

Now it seems that we have hit a scenario where this data might have helped before beginning the order.

Restaurant Delivery Service X stumbled across a series of chargebacks across a VERY short period of time... totaling in the neighborhood of $1000. Seems some thief got ahold of a stolen credit card number, and began using it to get as much food as they could delivered to them.

When the chargebacks started arriving, and it was found that the credit card was stolen, the credit card processor said that they were not responsible for the chargeback, as both the address and the security code were found to be a non-match.

DMS (as part of the integration with Elavon) DOES record the results of the approval of the Address verification (AVS) and the Security Code verification (CVV2) code during the time of authorization. But upon looking at the data, the "approvals" are across the board. The vast majority of the time, a credit card approval comes back with either the AVS and the CVV2 approvals coming back as a non-match.

This puts an RDS into a little bit of a dilemma: if the credit card processor is only responsible for the amount of the chargeback if the entire transaction comes back with a PERFECT approval, then to what degree does an RDS react to any portion of credit card approval coming back as less than favorable?

What we would guess, is that there is no single easy answer to this issue.. and that every RDS operation will have to come up with some sort of a rule summary in their operations to accomodate for local demographics and customer types. (For example, perhaps if a single RDS happens to do a bunch of hotel orders, they may employ a tighter scrutiny on credit cards approvals... or first-time customers).

Also keep in mind that this information is for ELAVON CUSTOMERS ONLY! For the few ICVerify stragglers that are still left in the DMS universe, your approval codes may be (and probably are) in a completely different format, and more certainly the letter codes mean something COMPLETELY DIFFERENT. For ICVerify folks, DO NOT RELY ON THESE CODES.

The new approval code DMS now displays in versions 7.1.1.4 and above is now an 8-character string broken down into three

parts:

(One Character AVS RESPONSE) (6 character APPROVAL CODE) (1 character CVV2 RESPONSE)

The AVS Response codes are:

A = Address (street) matches, Zip code does not.
E = AVS ERROR (system not available, this is an Elavon fault)
N = No match on Address OR Zip Code
R = AVS Unavailable (this an Elavon Fault)
S = Service not supported by issuer (this would come into play for a Visa/MC that came from out of the country… someone

visiting the US)
U = Address information is unavailable (issuer bank fault)
W = 9 digit zip matches, address (street) does not)
X = Exact Match on both Address (street) and zip code
Y = Address (Street) and 5 digit zip code match
Z = 5 Digit Zip matches, Address (street) does not
BLANK =ADDRESS INFO NOT SUBMITTED OR RECOGNIZED WITH TRANSACTION, AVS NOT CHECKED

The CVV2 Response codes are:

M = CVV2 Match
N = CVV2 DOES NOT MATCH
P or BLANK = CVV2 INFO NOT SUBMITTED OR RECOGNIZED WITH TRANSACTION, CVV2 NOT CHECKED

An additional items of note:

Notice that a BLANK at the beginning or the END of the 6-character approval code can be just as significant as a character.

In the case of Restaurant Delivery Service X, it was discovered that the transactions that ran through had BLANK responsesfor BOTH the AVS and CVV2 auths... and we suspect that (somehow) the customer convinced the CSR to just run the card through without any address or security code data on the credit card.

Now that DMS has been altered to include this data as part of the authorization, we feel we have to add additional caution: use your new weaponry WISELY. We all know, for example, that an address won't always match... and that CVV2 numbers can easily be rubbed off or misread from the card.

Tune your operations to use some common sense when interpreting the approval data.

Did you know?

You have the ability to attach a sticky note to a fax order, in DMS. This is done through the View Order function. Open view order, make sure the page you want to place the sticky note is in view. Click the 'attach sticky note' button, then drag the sticky note to a place on the page you want it to print. Fill out the sticky note, check the 'show on fax' radio button, close the view order window, and fax the order to the restaurant. have it accompany a fax to a restaurant.

This is the image you see when attaching a sticky note to a fax

DataWedge Services

Web Services...

The process of caring and feeding your own web server on your local network can be an expensive and daunting task. Not many companies have the financial resources to purchase and maintain the hardware necessary to run a web server out of their office, in addition to the technical savvy necessary to keep it secure from hackers on the internet.

DataWedge created an On-Line Ordering engine to help solve some of these problems. Your restaurant and menu data is uploaded and hosted securely on a DataWedge professionally hosted internet server, away from your office internet connection - giving hackers no place to scratch away at your network.

DataWedge Sample Site.
The DataWedge system is a "pay-for-what-you-use" system. This means for as little as $30 per month, you can have a professional web presence available on the internet including restaurant information, menus, and on-line ordering. Use of our templates and get on the internet in a matter of days! For an example of a template site, you can click here, or click here.

Do you have an existing web site, but just want to include on-line ordering functionality? No problem... our On-Line Web engine has the ability to be wrapped inside a frame. Measuring only 720 pixels wide, you can easily integrate your own web site around an instance of an ordering engine, and have the ability to push DMS data out to the internet, and have orders push directly into your system. To see examples of companies that have integrated their own web sites with our ordering engines, you can click here, or you can click here.

If you would like more information on our on-line ordering engine, please don't hesitate to contact us (208) 874-4185 .

Meal Monger...

FoodGetters.com represents our new aggregated web site, aimed at being firmly planted as a national on-line food ordering portal.

Because DataWedge utilizes a "pay-for-what-you-use" billing system, it's in our best interest to drive as many transactions as we can towards your service.

FoodGetters.com currently is in beta with our brand new web engine, and hopes to go live in January of 2010 with as many RDS's that wish to join. At this time we are not accepting any new members for our BETA period.

If you would like more information on being a part of FoodGetters after the BETA period, please contact us (208) 874-4185.

Credit Card Processing...

DataWedge has teamed with Nova - the nation's second-largest credit card processing system - to provide a seamless charge authorization system that accepts a full range of bank and T&E cards. The DataWedge/Nova partnership offers a number of advantages over other card processing alternatives:

Low transaction/discount charges resulting from the purchasing power of one master contract for DMS clients
Elimination of ICVerify as a card processing gateway. DMS is certified with the NOVA system for direct data transmission to their system.
The ease and efficiency of a "seamless" process from order entry to authorization to funds transfer into your account

If you would like to know how much you can save over your existing credit card services, please click here and fill out our request form