|Ecommerce without an online processor?|
Is it possible to do ecommerce with an online processor?
I am new to WebmasterWorld but really like what I see so far. I have a question as an ecommerce novice (at least as far as the technology is concerned).
I have a client who wants to implement an ecommerce system on their website, but for the moment, the bulk of their commerce has to do with registrations for commerce. They already have a merchant account.
If possible, they would like to bypass the stage of having credit cards approved by an online processor. What they would like to do is have an online shopping cart but then receive the details of the order either via email or through a secure website and then process the orders manually.
I have a few questions in regard to this:
1. Is it possible?
2. Is it advisable?
3. If it is possible and not ill-advised, what would be involved in setting this up? Do most shopping cart systems have options/features which would handle such an approach (I'm thinking of using the solution at oscommerce.com, primarily because my client is a non-profit and wants to minimize costs).
4. Anything else I should be thinking about?
Thanks in advance for any help anyone can offer - I really appreciate it.
Frank N. Johnson
1. Is it possible?
2. Is it advisable?
No. If you do not tell your merchant account that you are processing internet orders your account will be closed so quick, you won't have time to blink when they find out. (If you do tell them, the prices will be put up because of the higher levels of fraud online. If you don't you may be putting through a lot of fraud and this will alert them to check you out. You don't want the account closing - you can become credit blacklisted)
>> 1. Is it possible?
>> 2. Is it advisable?
"yes" and "maybe" respectively. Most ecomm systems I am familiar with will only collect c/c details by default (although adding the online authorisation step is getting easier), and the usual method is to use an exising PDQ machine or similar to handle authorisation off-line
Once you've collected c/c details (securely, of course) you don't really want to be emailing them. Having a system where you log on to a secure order collection area to is usually a good solution. Email notification of orders to LET YOU KNOW TO CHECK IT would be fine also, maybe include a few details of the order also, ie date/time placed, total value etc, to help you guage when you need to go and check it too perhaps
>> 4. Anything else I should be thinking about?
The real biggie is "How easy is my ordering system to use?". Nothing irritates a potential buyer more than having to fill in 20 pages of forms for the priviliege of paying you £10 for a pile of mouldy old socks. For large ticket items, people may expect to have to provide more detail, or for highly customisable goods, but for straightforward transactions, you need straightforward order processes. IMO, that is the absolute key to sales conversion %ages
We've had some spirited discussions about osCommerce here, and the emrging consensus seems to be that its a superb tool, if you have access to the necessary skills to modify it to your needs
Re-reading your post, it seems you may also be trying to ask about ecomm systems that permit you to log on as a registered user, with a credit account facility. There are plenty of these packages around, but they tend to be proprietory to a particular accounts software house. Certainly in the UK, most of the major non-specialist accounts systems have one or more ecommerce packages available that integrate with them (although the true degree of integration varies wildly). In that instance, rather than collecting orders manually, there is often a mechanism for passing orders by an authorised customer straight through to the live accounts, into the Sales Order Processing system. No payment would then be asked for (unless you get into orders that exceed existing credit limits etc, etc. Again, how different packages handle that scenario can vary wildly)
Welcome to WebmasterWorld [webmasterworld.com] Frank. :)
TallTroll: "usual method is to use an exising PDQ machine"
Which is illegal in Visa and Mastercards opinions, unless you tell the merchant that you are taking credir card details over the net. They will shut your account unless you tell them.
>> Which is illegal in Visa and Mastercards opinions
True. Sorry, I should have been clearer. I automatically assume that operations collecting c/c details over the net will have an Internet Merchant Account, so I failed to specify it. I have been assuming that Frank was asking whether it was technically possible to collect number without authorising them online, rather than proposing to scam his clients bank ;)
Thanks much for all of the quick responses - I really appreciate it.
One clarification - in rereading my original post, I should have said that my client wants to use an ecommerce system for registrations for _conferences_. Ooops!
Neither my client or myself has any desire to scam the bank! <grin> But I really appreciate the heads-up gsx because I might not have thought about it in advance. It occurs to me as well that it might be advisable for my client to obtain a second merchant account, only for internet orders so as to keep costs down (don't know if that's possible, though).
To summarize what I think I'm hearing from you, I should be able to use osCommerce to set up an online shopping cart for my client, have it not go through an online credit card processor but allow my client to be notified of the existence of new orders by email and to access those orders through a secure website, and then process the orders manually.
Without having looked at osCommerce extensively, my guess is that I might have the necessary skills to implement it at my client's site. In a previous job, I took a proprietary shopping cart written in vb script and customized it to a couple of new websites. Most of the editing I did was with regard to the look and feel, but I made some edits to the vb script and was successful at that.
Thanks again. I really appreciate the help.
>> don't know if that's possible, though
A second biz account (set up as an internet merchant account) specifically for the purpose of handling web orders should not present a problem for your bank. If it does, I would look at getting another bank
>> access those orders through a secure website, and then process the orders manually.
I can't lay claim to any specific osCommerce experience, so I can't be sure, but I would be surprised if it didn't let you do this, or something very similar.
If you want more background on osCommerce, a site search [searchengineworld.com] for osCommerce [oscommerce.com] will provide a lot of information. The osCommerce site has access to their own specific support forums too, if you have technical issues to raise about the software
My set up works as follows.
The customer places the order, and I am notified via email that an order has been placed. I log into my secure server, review the order and process the credit card offline using software provided by my bank. Once the order is processed, the credit card details are deleted from the server.
I set this up because I thought it would be a cheaper way to go, and I believe it is.
The biggest drawback is that it's becoming time consuming to manually process the cards. If you are only getting a couple of orders a day, it's no big deal, but it can become a hassle once the volume increases.
This really depends on a few things, including contracts that you have signed with banks, ect.
I. I have clients that sell some product online, but most of their revenue is derived from phone sales. In this case, I dont see any problems with the following:
a) If you process less than 101 orders a week - then I don't see why you wouldn't just do that by hand.
b) If you process more than 100 orders a week - then get automated, online processing. You'll probabaly also save in the long run since you don't have to pay an automated system like you would an employee.
II. However, if my clients are running an Internet-based business or service, I usually don't even give them the choice. Online processing is the way to go.
If you promise a Secure Transaction to your customers, go SSL on the secure pages, and then hand process the order - you are actually breaking the promise of a secure transaction.
As soon as human hands process a request - it ceases to be "secure" on many levels.
On the other hand, if you go totally automated, with SSL protected pages, it can be even safer than paying for dinner with your credit card.
1. Is it possible?
2. Is it advisable?
If your volume is low, the manual processing will not be a big factor.
3. If it is possible and not ill-advised, what would be involved in setting this up?
Free solution is Mal's eCommerce. Their free version allows you to store CC details on a server which you can log into later. You take the CC details and process through your offline processor (with prior approval from the bank) or use a service like ProPay.com. IMO, osCommerce will be overkill.
Since Mal's shopping cart engine is remote hosted, it can also be used on any type of web site like your ISP account or even GeoCities. osCommerce requires PHP and mySQL which adds a small monthly cost for hosting (~$5-$10 per month?)
Thanks for the suggestion of Mal's eCommerce. It's the part about it being hosted by them that is an issue for me. I don't like the idea of a user being sent to a different url for commerce, although I understand the look and feel can be customized. I'm not sure how many people would be turned off by realizing they are leaving my client's site (and I know they would probably have to be a savvy user to notice that), but it's a concern of mine.
Of course, I could launch the shopping cart in a popup window and for conference registrations, that might not be a bad idea.
Something to think about anyway.
Yes, that it is a concern. But for low-cost solutions that is a difficult to get around. Unless you want to buy a domain, an annual SSL certificate, and use an onsite shopping cart -- you will have to utilize another domain in some form. Perhaps a message on your web site explaining they will taken to another site will be sufficient.
I've been doing just what you say for several years. Works fine. We have a range of different products and shipping options and there was just no way I could boil it down so a shopping cart could spit out the price online. If I was starting again I'd probably go with a gateway and online processing, but at the time it was prohibitively expensive for a small operation like mine.
The other thing I like about it, is using a simple formmail order form which comes via a shared secure server I was able to keep the ordering process down to one page - none of this signing up and constantly reviewing and re-reviewing what you filled in on the last page nonsense. A lot of shopping carts are just to tedious for words, with dozens of dumb unecessary boxes you have to fill or click, and endless back and forth until you get them all.
When I signed up for my merchant account I told them what I was doing, and they had no problems with it. I even called up the providers security dept to ask them if they had any rules of advice about sending cards over the net and they laughed and told me the most dangerous moment in a CCs life is when you hand it to a waiter.
<<No. If you do not tell your merchant account that you are processing internet orders your account will be closed so quick, you won't have time to blink when they find out. (If you do tell them, the prices will be put up because of the higher levels of fraud online. If you don't you may be putting through a lot of fraud and this will alert them to check you out. You don't want the account closing - you can become credit blacklisted)
osCommerce has a kutzy way of handling orders, in my opinion, where most of the CC# is sent to you and you go to your secure server to download the missing part, then reconsitute them. To much damn fiddle work for my taste (though as I undestand it osC is infinately customizable, for those with the skill and patience).
I always wonder about Mal's and similar ops though. All these folks who are so paranoid about sending CC#s by email will cheerfully store them on a free shopping cart host. My CC company's security people told me most CC#s are stolen by employees of the company that is making the charge rather than being intercepted.
There was a defunct cart that had an solution for crude lowtech security for off line orders, it would email the CC#s to you with several extra digits added so packet sniffers looking for 16/4 digit combos would be fooled, and even if someone did intercept them it would be hard (though far from impossible) for them to figure which were the extraneous numbers. You then set up the database or whatever you were using to process the orders to remove the extra digits.
We, too, handle all our credit card transactions offline. Our products take a while to manufacture and we frequently have a slight backlog. Since (as I understand it) it's illegal to charge someone's credit card if you're not able to ship within seven days, real-time credit card processing is of no interest to us. Plus, it's much cheaper, even after figuring the cost of the credit card software.
We avoid hand-entering customer data by using a script that creates a text file that can be imported into our credit-card processing software. We create a similar file that can be imported into our customer database. I wish there was a way we could import the data into UPS' Internet Shipping service so we wouldn't have to enter shipping information by hand, too.
We may never recoup the time spent setting this up compared to what we would spend hand-entering all our orders. But, it reduces frustration when you're in a hurry to send out an order and eliminates potential typing errors as well. It's also been a great way to be forced to learn PHP. :)
We're currently handling security by splitting the credit card number up so part of it is stored in the order file and the rest is emailed to us, similar to the way it sounds like OSCommerce does it. I can store the whole credit card number securely in an encryped database, but I haven't yet devised a way to securely transmit the file to our computer.
I'm not new around here, but since I hardly post, I always get my account deleted...
I have a friend that runs an online store, and he's been getting credit card details through email for years! It's weird: everything is SSL and the last step is a plain email.
No matter what I tell him, he believes there's no risk at all, because the customer will cancel any suspicious transaction and the bank will protect him. No problems so far. I also think it's very rare that somebody will intercept an email, but I know it's technically feasible.
I've been searching for some "official" security recommendations but can't find anything really specific.
What do you think of his approach?
|All these folks who are so paranoid about sending CC#s by email will cheerfully store them on a free shopping cart host. |
I don't understand why free gets a bad rap. If we follow your logic, then one might conclude that Linux is not secure because it is free? Does that mean Windows has better security than Linux because it costs money?
Free + well maintained is good *but* Free + badly maintained is less good bordering on dangerous (See [webmasterworld.com...] for an example of badly maintained code in an ecomm environment)
Free software is great if you either understand the software or you have nothing at risk.
Let's take an example - I use lots of free software to assist with debugging network and web stuff, if it doesn't work then I'm a little annoyed but I can always fall back to another method or tool.
However if you said to me try this free e-com solution I'd probably have a hard time taking you seriously - commercially you can't afford to take risks like that, even with the massive user-base of the products mentioned so far.
My debugging tools stop working then I might struggle a little but I'd keep going, if my online payment system stops working unexpectedly or suddenly I get reports that it was hacked and all the CC numbers have been stolen then life is going to be hectic to put it mildly.
If you are your own boss then you only have to mop up the left-overs, deal with people asking you awkward questions and the like, eventually it blows over and hopefully you learn from the experience.
If you have a boss you then have to explain why your "free" solution did what it did and why you didn't anticipate this... Finally you have to explain why there is no-one left to take to court to recover damages from - I'd wager that unless you are a real favourite with the powers-that-be you'd be looking for a new job at this point.
That's not to say that it's a bad idea but unless you have nothing at risk or you understand the system as a developer or at least trust them (while leaving yourself no legal comeback) with everything you are prepared to risk.
There are a number of problems/costs associated with trying to "roll-your-own" credit card processing.
Yes, there is free software to let you accept cc orders by email (assuming you have your own merchant account). Many problems with this. First, customers are more savvy regarding SSL/secure connections. You would need to make sure that any form you put up to collect this info is secured via SSL. Second, you're never going to be able to scale your web site if you have to manually enter orders received by email. Third, fraud. Even though you can filter out invalid cc numbers, what about stolen numbers? You need to worry about this because if your chargebacks go up, in many cases to between 1 and 2% of your gross sales, you stand a good chance of losing your merchant account. Unless you maintain your own data base of stolen credit cards or have access to a network, you are vulnerable.
There is also legal risk involved with handling the information. Are you willing to take that on? Can you guarantee the security of your server if you store someone's cc info on-line? There is much to consider here and many successful lawsuits against merchants who failed to protect personal cardholder information.
If you have your own merchant account, then let's look at merchant account fees--transaction fees (usually $.20-.50 depending on who does your processing), bank interchange fees (additional fees for accepting MasterCard, Amex, Discover, etc.) and monthly fees (statement processing, minimums, etc. which usually run $35-$100 depending on who you go with). Are you an adult business? Most banks won't even give you a merchant account under those circumstances. If you have one and are running charges through your account illegally, then you can be blacklisted by Visa and never get another merchant account again under your name.
I won't even go into the integration issues with shopping cart, SSL certs, etc., to get your secure ordering environment setup.
There are (fee-based) tools and services that make it easy, safe and affordable to accept credit cards for goods and subscriptions. These third party services have a place and are a good place to start to get revenue through your site. Many of these services are NOT subject to the new Visa/Mastercard guidelines which require a $700 registration fee and $350 annual fee, background check, etc.
Many of these services don't require monthly minimums, have low ($.10-$.15) transaction fees and take a small percentage. CCBill and IBill's take ranges from 15%-20%, which in my opinion is steep given that they are subject to the additional Visa/MasterCard registration costs. Other vendors who are not subject to these costs charge less and are just as good. These services have become more of a commodity offering and costs have dropped as a result. I know of some recommendations if anyone is interested.
As the former Director of E-Commerce for HP and CTO for an E-Commerce company, I'm well aware of the issues out there and would gladly field any of your questions (or as many as I can). Looks like some good discussions going on here and I look forward to participating.
Tony, all the scenarios you mention can happen to any eCommerce solution, free or pay. What's your point? Find one that you can sue later if necessary?
I consider e-mailing credit card details without encryption to be inexcusably iresponsible. If I ever find out that a company I am doing business with does that, not only will I never do business with them again, I will make sure I warn everyone I know not to do so, either, and consider reporting them to any applicable chamber of commerce or better business bureau.
Now, if they are propperly encrypting the credit card details before sending the e-mail, I have no problem with it whatsoever.
Hey we are ALL CEOs of ecommerce companies on this list.
Don't get your point about fraud and maintaining one's own database of stolen cards. Soon or later, regardless of the exact method, the card is going to go through a merchant account or its equivilent, and they will be doing the screening for stolen #s etc. Or do you think offline processing means shipping the goods before they process the cards? Don't think anyone is dumb enough to do that.
Oh wait. I do, sometimes.
But anyhow, for everyone else, the fraud issues remain the same regardless of which route one, offline or online.
The merchant account costs you cite seem way out of line too. If it wasn't that advertising isn't allowed on this forum, after that buildup, I'd suspect you were going to try and sell me something.
<As the former Director of E-Commerce for HP and CTO for an E-Commerce company, I'm well aware of the issues out there and would gladly field any of your questions (or as many as I can).
|I consider e-mailing credit card details without encryption to be inexcusably iresponsible |
So do I, but to go back to my question: is there any place on the net where I can find some documentation with recommendations and explanations so I can convince my friend? Are there any rules imposed by the credit card companies that I can find somewhere?
I full understand that email _can_ be snooped, and that's a good enough reason for me, but I need more facts.
To follow on, my only comment would be that the fraud issue is multi-faceted, with numerous holes in the current processing schemes that banks and processors use. I'm certainly not an expert on all of the issues, but I have a lot of battle scars from dealing with the issues and have had to supplement the existing fraud prevention processes used in the industry with homegrown ones.
By the time a customer reports a credit card as being stolen, there have usually been many charges run up and the merchant has to eat those. I believe I read somewhere that the life of a stolen credit card is only three days. We started using a processor that had the foresight to work with other merchants to capture their own data base of stolen card numbers. This data base is always checked first before the charge is submitted to the bank. The problem is even more acute for digital goods purchases where you don't have the benefit of having a tracking number for the goods you ship out.
Also, we have discovered regions in the world where we will refuse to accept cards due to our own history of fraudulent charges. Last year, we have over $20,000 in fraudulent charges come through in a two day period from the Philippines. We were able to block the IP address and ISP to prevent further abuses. This group however was smart and simply moved to other ISPs in the area to continue their scam. It was a cat and mouse game for two weeks until finally, they gave up because we would always catch them. Thank goodness they didn't jump to another provider in the US like AOL, although, we would have more legal recourse there.
Bottomline is that if you can find a processor or service that employs some of the additional safeguards you are better off than trying to address the fraud issue on your own.
Regarding the comment to the fees being out of line, these are standard fees that Wells Fargo charges and other services. They seem to be in-line with other banks we've looked at. Most people don't really know what the end-to-end cost of a credit card transaction is. Our CFO has spent a lot of time analyzing these numbers so I think we have a good handle on it. Was just trying to pass on some of our findings.
>>I also think it's very rare that somebody will intercept
>>an email, but I know it's technically feasible.
criminals don't go to the trouble of "intercepting" emails as they move from one machine to another, they simply pop the mailbox or the server open to view the card details in plain text. most people use very simple passwords on their mailboxes or FTP - something they can remember very easily. they never worry about what happens with card numbers once they've arrived on the server.
it's becoming increasingly cheaper to rent a web server and set up your own web hosting business. thousands of individuals are setting up their own hosting companies without any knowledge of server maintenance and security. thousands of web servers around the world are wide open for the whole world to poke around in. criminals can and do set up .forward files in mailboxes to collect customer and card details. whenever they need a new card, they can SSH or telnet into a server and pick up todays newly collected card numbers. they can do this for months without anyone knowing.
any combination of newbie or lazy web host and SSL based e-commerce site is at fairly high risk.
>>Can you guarantee the security of your server if you
>>store someone's cc info on-line? There is much to
>>consider here and many successful lawsuits against
>>merchants who failed to protect personal cardholder
i'd certainly like to know more about any lawsuits like this. if you have any information / links etc that you could share (maybe by sticky mail) i'd appreciate it. sometimes it feels like i'm on a one man mission to alert people to fraud issues and show them that it really does happen and that there are ways to avoid most of it.
|i'd certainly like to know more about any lawsuits like this. if you have any information / links etc that you could share (maybe by sticky mail) i'd appreciate it. sometimes it feels like i'm on a one man mission to alert people to fraud issues and show them that it really does happen and that there are ways to avoid most of it. |
Unfortunately, most settlements like this never go public and many are settled out of court. Rarely do you actually see reports of this unless someone reports on a large company like the recent Authorize.net hack. The information I have is anecdotal from our attorneys but I do have some links somewhere to the big reports of service providers, like Authorize.net and others that have been hacked.
Also, we've been advised that providing we employ industry-accepted means for protecting information, such as SSL, encrypting credit card data stored on your server, etc., that, if we were taken to court, we would stand a better chance of winning. I would hate to face a judgement where someone's identity or cc info was stolen because of lack of security. It just doesn't make sense to take that risk when there are so many simple things companies can do to protect this information.
VISA has been working to develop industry-accepted practices for requiring all VISA merchants to follow if they accept the card. They have info on their web site about it. Other card companies will no doubt follow suit.