The only experience I have in programming is with Java, and I am somewhat experienced in that. However, I have only just touched the surface of javascript by implementing google maps into a page of mine.

My question is in regards to what I should keep in mind when creating a secure online form with javascript. I don't know what the code to create a form would look like, but I am relatively certain I will be able to figure that out. What I am concerned about is how exactly to go about making a secure connection to transfer the data entered in the form. I'm assuming this requires SSL, which my webhost provides without me having to mess around with certificates.
But once the user enters his information and clicks the submit button, what are my options as far as transferring the data to me?
I would imagine having the data emailed to me would be an option, but I think this defeats the purpose of security.

Any general help that could point me in the right direction would be greatly appreciated.

"Secure" and "JavaScript" can't exist together.

Anyone can read your JavaScript text by downloading the page. Thus, they can know how to access the secure connection.

Oh then I suppose I mis-interpreted what was used to create this page. What exactly would I be looking at to create something similar? I suppose asking such a question would show that to implement something like this would be out of my scope, but I would like to learn anyway. More specifically, I would like to know how the credit card information is "securely" transferred to the motel staff? Is it written to a file on their server? Is it sent to them via email? Is it somehow directly transfered to a staff computer?
As you may notice, my knowledge of the various scripting languages is very limited and I have a lot to learn, but I think if I know what techniques are involved for a particular situation, then I can take a more focused approach.
Thanks for your help; any further help is appreciated.

Creating a secure form has got nothing to do with Javascript. The javascript used under normal scenarios for enhancing the user experience and is client side only. In order to create a form whose data would be sent over a secure connection, you need to look into a protocol named as SSL (Secure Socket Layer).

For the sake of clarity, let me start out with a couple of examples. If you were to navigate to:
http://www.somesite.com?name=John
the browser contacts that server and sends data without encrypting it(cookies, url parameters, etc). On the other hand if you

navigate to:
https://www.somesite.com?name=John
the browser will encrypt the data sent to the server. Notice the "s" (as in "Secure") in "https".

Thus, you must make sure the html pages or scripts are submitting data via https.

Potential security pitfall: Let's assume that you set up a form at www.somesite.com/page1.htm
and its code is as follows:
If from the home page of the site you provide a link to it as follows:
https://www.somesite.com/page1.html
when the user clicks on it and submits the form, the browser will ultimately submit the form to:
https://www.somesite.com/page1.php

which is a secure form. Since in the "action" attribute you did not specify a protocol nor domain, the browser will "fill in the blank" with whatever is in the browser's address bar at the time. In this case, the form would "inherit" the "https" protocol and the "www.somesite.com" domain.

However, once the user is at https://www.somesite.com/page1.html, there is nothing preventing him/her to edit the protocol to http. Doing so would effectively cause the browser to ultimately send the form to:
http://www.somesite.com/page1.php

which is not a secure protocol. Another common mistake is to hardcode an insecure absolute uri on the action attribute of the form as shown below:
<form action="http://www.somesite.com/page1.php">

Since in this case the protocol and domain are provided, the browser does not "fill in the blank" for you. Instead it sends it to the exact location you specified using that specified protocol. Ideally you should use
<form action="https://www.somesite.com/page1.php">

Regardless of what protocol the browser used to send the info to the server, on your server script you would be able to process the information, but it is bad practice to process sensitive information via an unsecure medium. With all this in mind, here is what you need to be aware of:
Client Side:
-Must support https (all major browsers do)
-Data must be sent to a secure connection(this is where you must send the data via https)

Server Side:
-Must support SSL (If you are the admin, you must have an SSL certificate installed. If there is no SSL certificate installed on the server, the browser will not be able to interact with the server (via https) because they wouldn't understand each other. Think of some one(browser) speaking both, French(https) and German(http) but choosing to communicate in French with someone else (server) who understands only German!)
-processing script must make sure the protocol used was https. Will need to look into Environment Variables to determine if HTTP was used. Typically I make sure I serve the form via https.

Hope this helps.

Thanks Hielo, and S.O.S. Those replys threw a lot of light onto the situation. I'm afraid I have one more question regarding the next step. Once the information is delivered to a server side script, I would imagine that both ASP and PHP would be capable of writing this information to a file on the server.
I would also imagine it would be a normal practice to encrypt this file? Then after that, the staff would either request the information from a server side script which decrypts the file and sends it, or the staff would download the encrypted file and decrypt it client side? Or is the data never stored on the server in the first place?

I suppose I'm asking what the typical practice is for those two steps: storage and retrieval.

Typically the data is stored in a password protected medium. Most of the times it is onto a database and whether all the data is encrypted or not is entirely up to you. For example a nickname may not be as "top secret" as a password or a credit card number, so you may choose not to encrypt it. Thus, you may choose some of the fields on database table, but not necessarily all of them. Of course, if you choose to encrypt everything, your system will be quite secure, but you pay performance price since it takes time to encrypt the data, although on a low volume server you may not notice the impact.

Alright Hielo, that's enough information for me to know what I'm aiming for, so I'll now take a shot.
Thanks for taking your time to answer my questions.