I've done a little (mind you, i do say little ) research on building E-Commerce sites. So, i have a few questions.
#1, is to Jason. I understand you have a VirtualCredit program. How secure is this script, and how well does it interact with bank transactions?
I honestly don't know how to develop such a program, so I would be interested in purchasing this from ya, but just need to know a bit more about it..
#2. How much does each transaction cost ? In other words, when a user purchases something, how much are you charged for that transaction, how long does it usually take to process, and what is the maximum limitations? Or is all this things I need to ask my Bank about?
#3. SSL is the prefered method of doing such transactions I understand. However, where Can i find information about integrating SSL, Session, and MD5 encryption on each transaction to ensure more security? Or will this combination of encryption not work?
and #4. How much would you charge to build these 2 types of sites :
a) on-line categlog in which the user just views what you have in inventory and on-site for purchasing.
b) online purchasing site in which you can purchase items online and have them sent next day.
Before I get flamed, let me reitterate all this. I am NOT going to build this site tonight, tomorrow, or next month. I plan on doing some serious development and testing/hacking til I'm comfortable and sure that the site I build is secure. I am merely trying to collect the data I need in order to make this sort of thing possible.
Any input would be great. Thanks again.
E-Commerce and PHP
Moderator: General Moderators
Re: E-Commerce and PHP
myVirtualCard i am guessing is a third party payment program like PayPal or NOCHEX and not written by Jason.
Do you definately need to write the whole tansactions scipts yourself, cos it is far easier, and people trust you more if you use someone like VeriSign.
Mark
Do you definately need to write the whole tansactions scipts yourself, cos it is far easier, and people trust you more if you use someone like VeriSign.
Mark
- greenhorn666
- Forum Commoner
- Posts: 87
- Joined: Thu Aug 14, 2003 7:14 am
- Location: Brussels, Belgium
I must admit that I don't get your whole point here...
First what needs to be secure?
Second SSL is used to tunnel HTTP so that the data is encrypted, this makes the communication secure not the data (in memory, on disk,... on either side, while your side, the server is what you need to handle).
And you think about interacting with the bank yourself?
Where are you, cause here in europe you just DON'T do that.
As Bech100 Said, you go over a service provider that handles the CC transaction for you (different possibilities to 'hide' this from the end user)...
First what needs to be secure?
Second SSL is used to tunnel HTTP so that the data is encrypted, this makes the communication secure not the data (in memory, on disk,... on either side, while your side, the server is what you need to handle).
And you think about interacting with the bank yourself?
Where are you, cause here in europe you just DON'T do that.
As Bech100 Said, you go over a service provider that handles the CC transaction for you (different possibilities to 'hide' this from the end user)...
1. myVirtualCard is written by me. =) As far as security goes, it's very much secure (in fact, a little to secure and too paranoid in a few areas, and these I need to address). It uses phone authentication to verify the location of the user, and we use this along with a bunch of other information to deter fraudulent transactions. A user enters his phone number into the system, and during signup, our system will actually automatically call the user. And yes, this even works if the user is on dial-up. (We get that question often enough).
2. As far as costs goes, right now we have only have high-risk rates, as we are pretty much only catering to the highrisk (read Adult) industry). However, we are finishing a deal to offer mainstream merchants there own merchant account that includes Verified by Visa, and the rates will be much lower. You will then be able to either connect directly to the bank yourself, or you can run the system through MVC, thus unavoiding the need to handle Credit Cards, etc. If you are wanting to get details on costs, email sales@myvirtualcard.com, and one of my guys will be able to better answer your questions, as I really just deal with the technical end (or try to).
3. Yes, SSL is necessary. Before you even think of accepting credit cards, you need SSL. Obviously, if you are not accepting credit cards, the need for SSL is greatly decreased. One of the benefits of going with a third party processor like MVC is because we take care of the security aspect of it. SSL and managing and storing credit cards. If you run it yourself, you will be storing this information yourself, or you will have to handle this information, and that creates liability for you. However, this is not to say you shouldn't. Many companies can, and do. It's a trade off, and just something people forget about.
As far as trusting Verisign is concerned, I dont' think so. People don't know to look for HTTPS. Oh, they see the little Verisign lock, and think "Oh, they have an emblem saying they are secure, so they must be!"
Your average user doesn't know anything about underlying security. 128 bit SSL doesn't mean anything to the average user. They know it must be good, because we are saying it.
What our users like is the fact that they can actually call up for customer support, or if they email, we actually get back to them relatively quickly (at most within 6 hours, most of the time within 2 hours).
Credit card processing is also getting more and more interesting these days, with many new rules and regulations on all sides of the border. For example, Verified by Visa (and the Mastercard equiv.) is going to become more and more popular. To implement that, it will take much more work.
Of course, take this all with a grain of salt. I am, after all, an owner of MVC. =)
2. As far as costs goes, right now we have only have high-risk rates, as we are pretty much only catering to the highrisk (read Adult) industry). However, we are finishing a deal to offer mainstream merchants there own merchant account that includes Verified by Visa, and the rates will be much lower. You will then be able to either connect directly to the bank yourself, or you can run the system through MVC, thus unavoiding the need to handle Credit Cards, etc. If you are wanting to get details on costs, email sales@myvirtualcard.com, and one of my guys will be able to better answer your questions, as I really just deal with the technical end (or try to).
3. Yes, SSL is necessary. Before you even think of accepting credit cards, you need SSL. Obviously, if you are not accepting credit cards, the need for SSL is greatly decreased. One of the benefits of going with a third party processor like MVC is because we take care of the security aspect of it. SSL and managing and storing credit cards. If you run it yourself, you will be storing this information yourself, or you will have to handle this information, and that creates liability for you. However, this is not to say you shouldn't. Many companies can, and do. It's a trade off, and just something people forget about.
As far as trusting Verisign is concerned, I dont' think so. People don't know to look for HTTPS. Oh, they see the little Verisign lock, and think "Oh, they have an emblem saying they are secure, so they must be!"
Your average user doesn't know anything about underlying security. 128 bit SSL doesn't mean anything to the average user. They know it must be good, because we are saying it.
What our users like is the fact that they can actually call up for customer support, or if they email, we actually get back to them relatively quickly (at most within 6 hours, most of the time within 2 hours).
Credit card processing is also getting more and more interesting these days, with many new rules and regulations on all sides of the border. For example, Verified by Visa (and the Mastercard equiv.) is going to become more and more popular. To implement that, it will take much more work.
Of course, take this all with a grain of salt. I am, after all, an owner of MVC. =)
greenhorn666 : i'm in the US. In order to process online payment methods, you have to do 2 things : 1, get the user to pay using some sort of credit/bank card #, and 2, deposit their money into your banking account. thought i explained that.. also, yes, i understand what SSL is.. I was wondering about adding MORE encryption along with it you see... so instead of relying only on ssl's encryption, i was wondering about adding even more encryptions...
Jason, sounds good to me man. As I said before, I'm just trying to build this first before I even attempt to sale my final product to some of my clients. The biggest issue, was trying to understand the concepts of both security and the cost of transactions ( which you answered for me ). Cudo's and thanks again man, you'll be having me as a customer soon. I'll contact you all in the next few days with some information ( may call, dunno yet ) and we'll see where we are gonna go from there. Thanks again man
Jason, sounds good to me man. As I said before, I'm just trying to build this first before I even attempt to sale my final product to some of my clients. The biggest issue, was trying to understand the concepts of both security and the cost of transactions ( which you answered for me ). Cudo's and thanks again man, you'll be having me as a customer soon. I'll contact you all in the next few days with some information ( may call, dunno yet ) and we'll see where we are gonna go from there. Thanks again man