Table of Contents

Overview

The purpose of this page is to introduce and begin to address some of the issues of dealing with secure online transactions. The basic process of an online transaction is explained, and some of the specific technologies that relate to ecommerce are explained as well. A good starting point for those interested in developing or opening an online store.

Online Credit Card Transactions

To fully automate online ordering a store must have an SSL certificate and webspace set up to use it, a Payment Gateway, an Internet Merchant Account and shopping cart software that lets all these work together. The basic flow of an online transaction is as follows:

Website Front-End

The first thing required in an online transaction is that the end user must be able to, well... shop. This is where many of the technologies we've learned in this course come into play. Usually a store has a server database back end that holds all of the products for sale, and JSP, ASP, ColdFusion, PHP, or some other web development language is used to create the HTML and StyleSheet formatted storefront. If the inventory is small and static it's possible to do this without a database back end but rarely would this be a good idea in the long run.

Shopping Cart

Here as well the same technologies we've learned can be put to use to create a shopping cart. This is what the user uses while shopping to keep track of what they want to buy. There are many different ways of implementing this and the complexity of a well built Cart can become great. For this reason many companies offer pre-made carts you can install on your website and customize. Some you have to buy, but many (PHP) carts are free and come with most hosting plans (even ones that don't have enough features to use the cart). These are usually set up so that you can easily interface the cart with whichever Payment Gateway you are using.

Payment Gateway

This is the online credit card processor or transaction handler which is capable of hooking into credit card accounts belonging to the online shopper and the merchant's internet merchant account. It handles and approves the transaction.

Internet Merchant Account

This is a separate bank account for the merchant that is approved and capable of receiving credit card payments from credit card providers. Internet merchant accounts typically do not hold funds for an extended period of time such as your typical bank account but usually transfer payments to another bank account designated by the internet merchant on a daily basis

Of course many companies offer a bundle of the last two services, often at a discount. One stop solutions like this can be convenient as well.

Cost Breakdown

There are 3 primary components to the standard merchant account fee structure:

  1. One time fees (Set-up $100.00)
  2. Recurring monthly fees (Monthly Statement Fee $9.95)
  3. Transaction related fees
    • per transaction (set fee such as 30 cents)
    • per order totals (percentage fee such as 2.35%)

These same items apply to the payment gateway fee structure:

  1. One time fees (Set-up $49.00)
  2. Recurring monthly fees (Monthly Gateway Fee $10.00)
  3. Transaction fees ($ - ?)

Back to Top

The Technology Behind It

Web Development Technologies

One last time, this is the JSP, ASP, Perl, PHP, or whatever your language of choice is. With these you allow the user to select items and place an order. These technologies are what send the information to the Payment Gateway, store things on the server, etc. It's mostly server side, so if your server is secure then the transaction is secure and no one gets ripped off, right? Well... the date has to get from the user to the server. There are all kinds of things on the internet just waiting to intercept personal information like credit card information. So how does this information make the journey safely?

SSL

SSL stands for Secure Socket Layer. The basic idea of it is simple:

  1. The client makes the initial connection with the server and requests that an SSL connection be made.
  2. If the server is properly configured, the server will send to the client its certificate and public key.
  3. The client uses that public key to encrypt a session key and sends the session key to the server. If the server asks for the client's certificate in Step 2, the client must send it at this point.
  4. If the server is set up to receive certificates, it compares the certificate it received with those listed in its trusted authorities database and either accepts or rejects the connection.
 SSL Diagram

Once the handshake has been made, the server and the client's web browser talk back and forth via the HTTPS protocol, using the master key they agreed upon to encrypt and decrypt all of the data being exchanged. This is when you see the little Lock in the bottom corner of your web browser.

For servers to understand and handle SSL they usually need to be set up a bit differently. You can buy SSL server extensions and the like but there are open source ones as well including Apache-SSL, a specific fork of Apache for this purpose.

Now, how do you know, as a customer, that the certificate is worth anything? There are a few companies that serve the purpose of verifying a company's legitimacy. Some of the main ones are (you've heard of them I'm sure) Verisign, Thawte, Entrust, Geotrust... there are others. In exchange for a fee, they will vouch for your business and provide and SSL certificate the client can look at before making an SSL connection. Most browsers automatically handle Verisign and other certificates, but if it's from an unknown company your browser should alert you so you can read and investigate.

An SSL Certificate is directly tied to a domain name, which in turn is tied via nameservers to and IP address. Thus, to get an SSL certificate, you need a static IP server. Bad things happen when more than one SSL certificate are set up on the same IP. This rules out the cheap shared hosting plans then.

There is the option of a shared Certificate though. This is kind of clever trick using subdomains. For instance maps.google.com versus www.google.com. Google.com can have one SSL, but if it's a Wildcard Certificate it will allow handshakes on all of the subdomains. This is often cheaper, but not quite as trustworthy as having your own Certificate.

Encryption

In a SSL server-client transaction, the data can be encrypted by a number of different techniques:

The encrypts and decrypts of an HTTPS call take up processor cycles, and lengthen the load times on pages, but until you are dealing with a huge site it's not noticable. For this reason I have not investigated speed issues with SSL. Though obviously 128-Bit encryption, or Triple DES will take longer (but be more secure).

This short information sheet is not on encryption, the one-way or the two-way variety, so I don't address it in any more detail than this. The point is that this is where it happens, in the SSL.

Information Storage

There is ongoing debate about the retainment of sensitve information on servers, becuase it can get stolen off of servers. Happens all the time. The safest thing to do seems to be to discard the card information after each transaction. If it must be stored, I read various solutions like keeping half of the number in one database, and the other half in another... I don't know. If you encrypt the information and store it in a secure database on a secure server, you SHOULD be fine, but if information theft occurs... it's your fault.

Back to Top

Alternatives

P2P

Here, P2P stands for Person to Person, instead of Peer to Peer. The quintessential example of a P2P service is PayPal. Once the merchant or customer has set up their bank account information PayPal can handle all of the rest, a direct payment from the customer into the bank account of the merchant. The idea is that it's almost like two people simply exchanging money.

3rd Party

A quick and easy way to start doing online transactions is through a 3rd party service. After a point it becomes cheaper for your store to do all of it's own credit card handling, get a merchant account and the like, but for speed and ease of set up this takes the cake. A simple rundown of how it works:

  1. The internet merchant signs up with 3rd Party. There is an initial setup fee of $45.00 (at the time of this writing).
  2. The merchant uses 3rd Party programs to enter product information.
  3. The merchant adds html code to his/her web site (code is generated by the above step) which creates the purchasing button/link.
  4. Customers goes to the merchant's web site and clicks on the link to buy the product.
  5. Customer is taken to a secure page at 3rd Party to make the purchase.
  6. 3rd Party handles the payment processing
  7. 3rd Party notifies the merchant of the order details
  8. The merchant processes the delivery of goods or services for the order
  9. 3rd Party pays the merchant periodically (twice a month) for the orders, less a transaction fee of $0.45 and commission of 5.5%.

Basically, the 3rd party handles all of the transactions, they are the "seller", and they pay the actual merchant who becomes almost like a supplier.

Traditional Methods

More as a side note, it's possible to only accept orders via mail or phone (which is actually how the government classifies online business for legal purposes - MOTO: Mail Order and Telephone Order). No matter what service you are using, credit card fraud can still occur.

Back to Top

Evan Johnson

Valid HTML 4.01!