May 14th, 2008 . by Elan
This week Ifbyphone is exhibiting at ISPCON, where we announced the launch of a new API solution called Verify-Me-Now. Basically, Verify-Me-Now enables ISPs and any e-commerce or SAAS site to slash fraud rates by combining the power of the Web with the telephone. More specifically, here is how Verify-Me-Now can reduce credit card fraud:
1. ISPs incorporate the hosted Verify-Me-Now application into their existing process that customers use to sign up for a Web hosting account or any other service.
2. A telephone number is collected as part of each registration or purchase transaction.
3. A PIN of up to ten digits is displayed on the customer’s screen.
4. The Verify-Me-Now service is then invoked, either transparently or via a user-pressed button, with an easy-to-use API that is compatible with most Web-programming environments.
5. The Ifbyphone server instantly places a call to the customer at the number entered in step one and then asks the customer to enter the previously displayed PIN using their telephone keypad. (The Ifbyphone server also can be configured to request and record the recipient name during this step.)
6. Depending on whether the PIN entered matches the one provided in step two, the API returns a success or failure message.
To read a review of the service, visit Smith On Voip.
You can read more about Verify-Me-Now by clicking here, and if you’d like to incorporate Verify-Me-Now into you website or service offering click to call the Ifbyphone team here.
Posted in Security, Shopping cart, Verify-Me-Now |
30 Comments »
January 8th, 2008 . by Moshe Yudkowsky
Here’s a story from a local institution that had a budget problem. One department found that they always overspent their budget but no one could ever find out why. Eventually a new person joined the staff and decided to solve the mystery, and discovered that the money was leaking out of the department because a completely different department was using it to pay for their office supplies. And how was that possible? It seems that the institution assigned budget numbers in numerical order. A simple clerical error, getting one digit in the account number wrong, allowed one department to drain money — for years — from the budget of a different department.
Now imagine the same thing happening at your company before you introduce automated account information. Someone speaks to their customer service representative (or to you) and you have a conversation. If they give you the wrong account number, it’ll be clear fairly rapidly what the problem is. And if someone calls and tries to get information about a competitor’s account, you’ll figure that one out pretty quickly as well.
After you introduce automation, what prevents a caller from calling in and trying account numbers in sequence until they hit one that works? What if the caller is attempting fraud, or is attempting to access competitive information (about you or your customers)? And what if they make an honest mistake?
As a best practice, whether you have automation or not, the account numbers you assign should not be simply sequential. The most secure method is to assign a random number to each account. If that’s too complex, you might consider adding a single random number to the end (or the beginning, or the middle) of sequential account numbers. Or you can use one or more random digits and add one or two additional “checksum” digits, which is the method used by credit card companies to prevent people from guessing or confusing credit card numbers.
Is this a big change? Yes, it is. Is it necessary? Good question. Unless my company had a history of making accounting errors based on incorrect customer numbers, I wouldn’t bother switching old numbers for new ones, but I would start assigning new numbers with a little more care. If my company does experience problems — fraud, errors, and the like — than of course it pays to make corrections. And if my company safeguards important information for customers, such as medical records, I would be very cautious. I can’t speak to the legal requirements, but if an inexpensive change (and this change might be very expensive in some cases) can help protect against privacy violations, that’s what I would choose.
Posted in Hosted IVR, Security, Strategies |
No Comments »