https and ssl

[BarbBayne]

Hi,

Eventually I would like to set up a website that I can sell one item - a windows application - I have VS2005 and have been learning ASP.NET, HTML, javascript, C# ... etc etc. I beleive I can do all of the programming for this website. I am already paying a monthly fee for a website that I have from a hosting provider ( re-invent technologies )- it includes an sql database.

The big mystery is concerning https- what are the steps in setting this up - Does it depend on what payment processer I choose? Do I need to get my hosting provider involved?

There just seems to be so many setup fees and monthly fees involved to get to where I would like to be. It is going to be a while before there are any revenues but I would like to get everything in place so I can develop and test in the correct environment.

Thanks for any info

[Corey Bryant]

You will need an SSL cert. To get an SSL, you need a CSR (Certificate Signing Request). On IIS, this is very simple to do. An SSL Cert is usually purchased yearly. No monthly fees unless you are using a shared SSL cert. Usually the hosting provider needs to generate the CSR to be given to the SSL provider.

You also need your own IP address since the it will use port 443 (https). If you can generate your own CSR, you can buy your SSL cert from any company, like GeoTrust, Verisign, Godaddy, etc.

If you are going to be testing it locally, etc you can get a free SSL from www.cacert.org

[BarbBayne]

Thanks for the info Corey,

But I still have some some confusion,

How does this SSL certificate make a page become https?

Then the intent is to transmit sensitive data to some sort of payment processor. Can you tell me if the following assumptions that I am making are correct or where I am going wrong.

1) I need to ask my host provider to set me up with https. If this assumption is true then how do I make only certain pages https and others just http?

2) I need to have my host provider install a CSR and my purchased certificate.

3) Many of these shopping cart demos that I look at have sensitive info being collected on http pages not https - This would lead me to believe that this is insecure.

4) An https page protects info from the users browser to the server that is hosting the page. If this is true what about tramsmitting the info to the Payment Processing server and receiving the results back.

5) In order to do any eccomerce I need to get set up with a merchant account which involves substantial fees - ( anything over 10 dollars is substantial to me ). I am assuming that this merchant account must be issued by the Payment processor. Does this involve me setting up some sort of merchant account at a bank?

6) From what I am seeing, even if I try to do most of the programming myself, I am still facing many monthly fees and setup fees.

a) setup and monthly fees to have https

b) merchant account setup and monthly fees

c) SSL cert fee

d) fees to install CSR and SSL cert

e) fees to get set up with a payment processor ( ie Authorize.net )

I think that this is all becoming too much for me since I am a long way from making any sales. I just wanted to get an evironment set up so that I can test anything that I come up with.

[Corey Bryant]

Thanks for the info Corey,

But I still have some some confusion,

How does this SSL certificate make a page become https?
It does not really make it https - you point to https in your URL so that you call the page in a secure manner. The cert establishes a secure connection between the server and the browser and encrypts the transfer

1) I need to ask my host provider to set me up with https. If this assumption is true then how do I make only certain pages https and others just http?
You need an SSL cert. To get an SSL cert from Geotrust, etc - you need to have a CSR. I do not think that if you are on a Windows platform you can generate your own CSR, you can ask your hosting company to generate one for you.
2) I need to have my host provider install a CSR and my purchased certificate.
The hosting provider will generate the CSR and then give that to the SSL provider (Geotrust, Verisign) and then the SSL provider will generate an SSL cert based on that CSR
3) Many of these shopping cart demos that I look at have sensitive info being collected on http pages not https - This would lead me to believe that this is insecure.
That is a correct assumption. If it does not have the secure icon lock in the lower right hand corner (on IE) then the page is not secure.
4) An https page protects info from the users browser to the server that is hosting the page. If this is true what about tramsmitting the info to the Payment Processing server and receiving the results back.
Everything should be transmitted using HTTPS. You will post information to the electronic payment gateway (LinkPoint, Verisign's Payflow, Authorizenet.com) and they will post information to the transaction processor (First Data / Nova) and they will either authorize the transaction or post to the issuing bank and then give you the answer back if the transaction was approved or not.
5) In order to do any eccomerce I need to get set up with a merchant account which involves substantial fees - ( anything over 10 dollars is substantial to me ). I am assuming that this merchant account must be issued by the Payment processor. Does this involve me setting up some sort of merchant account at a bank?
You need a merchant account and if you are in the United States there are usually no set up fees involved for a merchant account. For an electronic payment gateway - there might be a set up fee involved. And then there are usually discount rates and transaction rates. LinkPoint does not have a transaction rate while Verisign's payflow gives you 1,000 free transactions and Authorizenet.com usually charges about $.10
6) From what I am seeing, even if I try to do most of the programming myself, I am still facing many monthly fees and setup fees.

a) setup and monthly fees to have https

b) merchant account setup and monthly fees

c) SSL cert fee

d) fees to install CSR and SSL cert

e) fees to get set up with a payment processor ( ie Authorize.net )

Yes definitely fees of some type since they are in business to sell you these services.

[BarbBayne]

thanks for your answers Corey

My hosting provider ( re-invent technologies ) does have a plan to set up https and a CSR - So does that mean I first have to get the hosting company( re-invent ) to somehow give the SSL certificate provider the CSR or do I have access to this CSR?

So if my hosting company sets me up with https, how do I get some pages to be https and others not? - I am still confused about this.

I have been in contact with authorize.net and they provided me with a developers key and login - this I assume I can use to test out transmition of payment transactions - I am assuming that this kind of handles the need to set up a merchant account as far as testing goes using their API.

Unfortunately I am in Canada and they only support US merchant accounts with their API. I so far have not been able to find something in Canada that is similar but I am not going to worry about that for now. I just want to clear up the technical details first.


So as far as all these shopping carts go - how come I do not see very much info about integrating the merchant account with them or info on making the pages dealing with sensitve issues secure? They give the impression that there is basically no setup involved - I find that hard to believe - There seems to me to have to be some sort of integration with your merchant account and the payment processor. Also do these shopping cart pages reside on their server or do you have to install them on your own host provider?

I seem to be really stuck on something that I have not been able to find too much info on. I don't know how other people are dealing with these issues but from the lack of info I can find, it does not seem to be a problem for them. Why me?

Thanks

-Barb

[Corey Bryant]

thanks for your answers Corey

My hosting provider ( re-invent technologies ) does have a plan to set up https and a CSR - So does that mean I first have to get the hosting company( re-invent ) to somehow give the SSL certificate provider the CSR or do I have access to this CSR? A CSR is used to get the SSL Cert. If you can get the CSR yourself then you can go out and buy any SSL Cert that you want.
So if my hosting company sets me up with https, how do I get some pages to be https and others not? - I am still confused about this.You just change the hyperlink to http://www.example.com/order.asp to https://www.example.com/order.asp. It is really that simple, no rpcket science here.

If you can use ASP, you can place this code at the top of the ASP to force https:
<%
dim servPro
servPro = Request.ServerVariables("HTTPS")

if servPro = "off" then
' response.redirect "https://www.example.com/order.asp"
' response.end
end if
%>Here is an example: http://www.loudcommerce.com/merchant_account/internet_application.asp - if you click on that link you will see that I am not calling https but if you look at the URL you will see https and a secure lock. We added the code above to make sure there would be a secure connection between the server and the browser. This encrypts the data between the two and does not transmit in plain text.

I have been in contact with authorize.net and they provided me with a developers key and login - this I assume I can use to test out transmition of payment transactions - I am assuming that this kind of handles the need to set up a merchant account as far as testing goes using their API.No - you need a merchant account and an electronic payment gateway - remember? There are two parts to this when accepting credit cards.
Unfortunately I am in Canada and they only support US merchant accounts with their API. I so far have not been able to find something in Canada that is similar but I am not going to worry about that for now. I just want to clear up the technical details first.Being in Canada, chances are very slim that you can use the electronic payment gateway Authorizenet.com. Authorizenet.com is compatible with United States merchant account providers (MAPS).

To get a merchant account in the United States and you are not a citizen - you need at least a United States bank account, United States address, and United States phone number. And even then, only a very few MAPs will support you and the discount rate will be higher than what people who live in the United States.

You might check out Beanstream, Paymentech, PSIgate for starters since you are in Canada.

So as far as all these shopping carts go - how come I do not see very much info about integrating the merchant account with them or info on making the pages dealing with sensitve issues secure? They give the impression that there is basically no setup involved - I find that hard to believe - There seems to me to have to be some sort of integration with your merchant account and the payment processor. Also do these shopping cart pages reside on their server or do you have to install them on your own host provider?
You do not integrate the cart with a merchant account. It is integrated with a an electronic payment gateway.

You might check out How Does a Credit Card Transaction Get Processed? (http://www.blogmerchantaccount.com/blog/permalink.asp?id=99) and How Does a Credit Card Transaction Get Processed? (http://www.blogmerchantaccount.com/blog/permalink.asp?id=96) to see if those help.

As far as the shoping carts - most people have the code on their own server. Some people use a shared SLL on another domain. Some people also use the gateway's secure payment page as well. it all depends on what you want.
I seem to be really stuck on something that I have not been able to find too much info on. I don't know how other people are dealing with these issues but from the lack of info I can find, it does not seem to be a problem for them. Why me?I think you are just trying to make it more difficult. :) Some of this is very complicated while other parts are not.

[BarbBayne]

Thanks once again Corey,

I believe the mystery about https is cleared up for the most part now but the mystery about merchant accounts deepens.

If I have a merchant account, how and where does it integrated with the payment processing - I have this testing API from Authorize.net - but do I need a merchant account to be able to go any further. Is there such a thing as a test merchant account? Where does this merchant account go?

I have found a Canadian site Merchant-Accounts.ca that seems to offer the things that I may need including a testing API -

Perhaps in a decade or so I will get to where I want to be.

Thanks

-Barb

[Corey Bryant]

Thanks once again Corey,If I have a merchant account, how and where does it integrated with the payment processing - I have this testing API from Authorize.net - but do I need a merchant account to be able to go any further. Is there such a thing as a test merchant account? Where does this merchant account go?
No - you need a merchant account and an electronic payment gateway
The merchant account does not "go" anywhere. First - do you have
at least a United States bank account, United States address, and United States phone number.
Otherwise Authorizenet.com is not going to be able to help you. The merchant account allows you to accept credit cards. Did you check out How Does a Credit Card Transaction Get Processed? (http://www.blogmerchantaccount.com/blog/permalink.asp?id=99)?

The MAP basically moves from the money from the issuing bank to the acquiring bank to your bank account.

You do not need a test merchant account. There is no such thing as "test money". The integration is the electronic payment gateway. Once you have that set up & tested and you are ready to sell, you get a merchant account.

I have found a Canadian site Merchant-Accounts.ca that seems to offer the things that I may need including a testing API -

Perhaps in a decade or so I will get to where I want to be. Yes you will need a merchant account that supports your country.

[BarbBayne]

Thanks Corey

Perhaps I am not explaining myself correctly about merchant accounts

for testing, the interaction I was using with authorize.net was the following

1) build an HTTP request object using

https://test.authorize.net/gateway/transact.dll

and

x_login=cnpdev9999&x_tran_key=Sjeb2h9Q9BfNEYKk&x_method=CC&x_type=AUTH_CAPTURE&x_amount=1.00&x_delim_data=TRUE&x_delim_char=|&x_relay_response=FALSE&x_card_num=4111111111111111&x_exp_date=052009&x_test_request=TRUE&x_version=3.1

then return an HTTP Response using this request - for example it would return

"1"|"1"|"1"|"(TESTMODE) This transaction has been approved."|"000000"|"P"|"0"|""|""|"1.00"|"CC"|"auth_capture"|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|"

The assumption that I am making is somehow the x_login or x_trankey is somehow tied to the merchant account. Is this correct?

thanks

-Barb

[Corey Bryant]

The assumption that I am making is somehow the x_login or x_trankey is somehow tied to the merchant account. Is this correct?It will be when you are ready for to sell your products / services. I did not think you were ready to sell. You only need the merchant account when you are ready to sell your products / services.

But you are wasting your time with authorizenet.com if you do not have at least a United States bank account, United States address, and United States phone number. They are only supported by United States MAPs.

[BarbBayne]

Thank you so much for your help Corey.

You are right, I am not ready to sell anything yet, I just wanted to get the understanding first so I don't run into any roadblocks. I think I have it now.

I have found www.merchant-accounts.ca that seem to be able to help me here in Canada.

They have a page on their site that you re-direct the customer to ( that you can customize ) that collects customer, payment and credit card info then another page on their site that will return the result of the transaction that you can also customize and link back to your site. When you redirect the customer to this first page, you can also have some of the fields pre-filled with customer data that you may have collected on your site.
Now they did not mention anything about https - even though it is not credit card info but probably just name and address - should this be sent securely?
I was thinking that rather than get set up with the extra expense of having https, that I would try this type of solution, I think it would probably be cheaper. The only thing that bothers me is the transmition of data between my site and their site. Is this common? Do many other people do it this way? Do I have to worry?

thanks

-Barb

[Corey Bryant]

They have a page on their site that you re-direct the customer to ( that you can customize ) that collects customer, payment and credit card info then another page on their site that will return the result of the transaction that you can also customize and link back to your site. When you redirect the customer to this first page, you can also have some of the fields pre-filled with customer data that you may have collected on your site.
Now they did not mention anything about https - even though it is not credit card info but probably just name and address - should this be sent securely? If it is just name / address, that is dependent on what you want. It does not need to be but it cannot help. SSL wil slow your site down some because of the encryption but it should not be noticeable.
I was thinking that rather than get set up with the extra expense of having https, that I would try this type of solution, I think it would probably be cheaper. The only thing that bothers me is the transmition of data between my site and their site. Is this common? Do many other people do it this way? Do I have to worry?
Everything should be transmitted using HTTPS. You will post information to the electronic payment gateway (LinkPoint, Verisign's Payflow, Authorizenet.com) and they will post information to the transaction processor (First Data / Nova) and they will either authorize the transaction or post to the issuing bank and then give you the answer back if the transaction was approved or not.The credit card data is what needs to be entered on an SSL page and posted to an SSL page. The other information, some consumers have a problem understanding the difference since a lot of them have been taught to look for the secure icon. If they do not see it - run away. And some people might do that once that start the check out process and do not see the secure icon. Will having the SSL site on your website hurt? Probably not. Will not having it hurt? Probably.

There is no right or wrong answer to these question entirely - some people prefer SSL on the entire check out process to protect the consumer and some do not. What do you as the merchant want to do / protect?

[BarbBayne]

Thanks again Corey,

It is also possible with this payment processing system to send the customer to the payment processing site where all of the customer details are entered of there secure pages, once all of the payment processing is complete, the customer details can be returned to my site using http parameters. The customer then only sees that they are entering personal info on a secure site. They would not be aware that my site would be receiving the details back ( except for credit card info ).

So in this case should there still be any concerns? I kind of like the idea of not dealing or having any knowledge of credit card info so that if the customer does ever experience a problem with their credit card they do not falsely blame me. But what about other info, they would not be aware that it is being returned in a non secure way but could this ever be a problem?

thanks

-Barb

without the customer being aware that any info

[Corey Bryant]

So in this case should there still be any concerns? I kind of like the idea of not dealing or having any knowledge of credit card info so that if the customer does ever experience a problem with their credit card they do not falsely blame me. But what about other info, they would not be aware that it is being returned in a non secure way but could this ever be a problem?It does not matter because it is not you, but the SSL issuer that is securing the transmission. Even though it might be another site, how did they get to that site? Could you be sued - more than likely yes. Consult your attorney.

The other information would be the name, address, etc that it is up to you as far as do you want them to enter it securely?

[BarbBayne]

Fair enough, I think that resolves all of my concerns.

Thank you so much for taking the time to help.

Have a nice day.

-Barb