The word e-commerce is generally used to refer to the entire spectrum of business or commerce using electronic mechanisms. It is often understood more specifically to refer to selling goods and services on the Internet.
One specific part of the e-commerce process is the transaction where money and goods change hands. The transaction has two parts. The goods are sent from the seller to the buyer, and the payment is sent from the buyer to the seller. I will refer to the payment part of the transaction as the payment-transaction.
The goods generally are divided into two groups, hardgoods (goods of a physical nature such as books, CDs) and softgoods (electronic or non tangible goods such as subscriptions, software, electronic documents, shares). Hardgoods require something to be shipped, while softgoods can be transferred via the Internet.
Because the sale of softgoods is an entirely electronic process, it can occur entirely in ‘real-time’, i.e. the entire transaction can happen within seconds. This real-time transaction requires several events to occur at once and I will explain this process below.
With the sale of hardgoods, the entire transaction cannot occur in real time, however, the payment-transaction part at least, can be a real time transaction. The buyer can receive ‘instant’ confirmation and approval of the payment. The seller will also receive ‘instant’ confirmation and approval and can ship goods immediately. This is of course the preferred situation as both parties can have confidence in the transaction.
I will also refer to a merchant often. In this document a merchant refers to a person, company or entity that has the capacity to accept credit cards as a method of payment. This entity is said to have ‘merchant status’. Acquiring merchant status requires entering into a contract with a bank. This is a relatively complicated process. I will provide some detail on this later in the document.
These days, banks are starting to differentiate between ‘Internet Enabled Merchants’ and ‘Offline Merchants’. Some banks will grant a different status to entities that can accept credit cards via the Internet from those who can only accept credit cards via conventional methods such as the ‘cheese slicer’ or EFTPOS machine.
Lastly, I will often refer to a ‘secure connection’ between two points on the Internet. This may be two servers or a buyer and a server, or even an email between two people. By secure I mean that the connection is encrypted so that the messages sent over that connection cannot be intercepted and read. Today the most common form of encryption is SSL (secure sockets layer) encryption. I will not go into any detail on how this works, but it can be accepted that this is adequate and safe.
Non-real-time payment-transactions
While this can include cash, cheques and money orders, I will be referring only to credit card payments.
If a merchant wishes to sell goods online and accept credit card payments there are several ways to achieve this. The following are some simple non-real-time systems.
1) Credit card via email
Simple email form
This is the most non-secure and dangerous way to do the transaction (unfortunately still very common). The buyer sends the credit card details to the merchant either in an email or through a web form that emails the details to the merchant. The merchant then handles the payment as if it were a phone order. This is a very simple system to setup and often the merchant can get away without informing their bank that the transaction is occurring via the Internet (thereby avoiding the upgrade to Internet Enabled Merchant status)
Email form with SSL encryption
This is a variation on the email solution; it looks more secure, but is in fact just as dangerous. The website offers the buyer a secure SSL form to pass the credit information to the webserver, but then the webserver emails the details from the webserver to the merchant without security.
The diagram below (Figure 1) shows how the buyer could be looking at a secure web page – and think that the transaction is secure. They would fill out a form on the website and submit credit card details which would travel to the webserver over a secure connection. The server then sends the credit card details via a non-secure email to the merchant. A large number of shopping cart systems still use this method.
A simple variation of the system can improve the security. The next diagram (Figure 2) shows how the webserver can send a simple email message notifying the merchant of the transaction (without credit card details) and then the merchant connects to the server via a secure connection to retrieve the credit card details. This is a better system, but it still has one point of weakness. The credit card details are stored on the webserver for a period of time. It would be fair to say that most small websites are not hosted on machines that offer adequate security for holding credit card information. This is potentially even more disastrous, because a hacker can get hold of many credit cards at once by breaking into the one machine.
Once again the merchant handles the final payment as if it were a phone transaction using conventional methods.
In both the above methods the payment does not occur when the buyer submits the credit card information, but later when the merchant handles it. The buyer must wait a period of time before acceptance and confirmation of the payment.
2) Credit card via full SSL
It is possible to set-up a system that transfers the credit card information all the way to the Merchant via SSL security. In this case the merchant must have a server behind a firewall (reasonable protection against attack), capable of handling SSL communications. This option is usually only for large corporations who can afford the infrastructure costs.
In this case the information can be passed securely from the buyer to the merchant. The merchant then handles the transaction via conventional methods. Once again this is not real-time and the buyer must wait for a confirmation, but it can be quite secure.
Real-time payment-transactions
Real-time payment-transactions require the addition of a third entity for clearing the payment. In almost all cases this is the bank which the seller has the merchant arrangement. The following diagrams show how the three parties can communicate.
There are several variations of this process. I will describe two of the most common.
1) Website-bank Gateway
The setup shown above (Figure 3) is one of the most common ways a real-time payment-transaction occurs. In this case the webserver uses a ‘payment gateway’ to the merchant’s bank to verify the credit card details and to handle the actual transfer of funds. This payment gateway is a secure connection over the Internet between the merchant’s website and the bank. It should also be noted that systems using the above setup allow the credit card details to be stored on the webserver. Again, as I mentioned before, unless the webserver is behind a good firewall this can be a security risk.
There are many different payment gateways available now. Some of the best-known gateways are provided by Cybercash, ECX, QSI, and Netbanx. In many cases banks also choose to develop their own proprietary payment gateways. Not all banks accept all payment gateways so the merchant has to choose a gateway that their bank accepts and then develop a website or use a shopping-cart system that has that gateway integrated. It is also the case that some banks accept no payment gateway and therefore cannot approve credit cards real-time over the Internet.
2) Buyer-bank Gateway
The next diagram (Figure 4) shows one of the most secure systems that can be established. Only a few payment gateways can handle this type of configuration. QSI is one of those that do, and with this system the merchant never sees the credit card information at all. It is not stored on the webserver and is therefore very secure.
In this case the payment-transaction is handled by communication directly between the bank and the buyer. The buyer is actually seeing web-pages from the bank’s payment gateway that, in most cases, are branded to look like part of the merchant’s site. If setup well, the buyer may not know that they have moved to another server.
Setting up a payment-transaction system
Of course if you do not sell anything online or only a small volume then you will not need to worry about online payment-transactions. You could also devise a purchase order system for known clients and handle the payments offline. However if you want to use the Internet to handle these transactions then you will need to establish a system similar to one of those described above.
You will have to make some choices about which way you go. If you are mostly handling hardgoods, then real-time payment-transactions is not so important – a 24-hour delay may be acceptable. If you are handling large numbers of transactions, or selling softgoods then real-time payment-transactions will be important to you.
Because the choice of bank, merchant status, payment gateway and website are all connected, it is not a simple exercise choosing a complete system. You need to consider the interaction of all these components. The list below is probably the best method to use when making these decisions.
1. First consider the bank and merchant status. In most cases the bank will determine the merchant fees, and choice of gateway, it will also determine the currency you can accept and which credit cards. So the first thing to do is to contact your existing bank and ask a few questions:
- 1. Do you allow merchants to accept credit cards via the Internet?
- 2. What currencies and what credit cards can be accepted?
- 3. What Payment Gateway(s) do you use?
- 4. What are your fees? (This is often the deciding factor – banks will often levy Internet transactions up to 3% in addition to the credit card fees. This is supposed to cover their risk)
2. If you get satisfactory answers from you bank then you can proceed from there. If not – consider changing banks. In these early days, the success of a bank will be determined by its willingness to accept new technology. If your bank is not thinking forward, don’t stick around – move on.
3. Once you have decided on a bank you will then have a fixed option for payment gateways. In most cases you will only have one or two options available to you. You now need to decide how you will link your website into this gateway. If it is a proprietary gateway then, in most cases, your only choice will be to engage a web developer to build a custom solution for you. Expect this to cost from US$2,000 to US$10,000 and take 6 to 8 weeks. Some banks may provide tools for this, but many are still not well setup.
4. If the gateway is more generic such as Cybercash, ECX or QSI, then you will have a better range of options. The best solution is to make use of a ‘shopping-cart’** system that is compatible with the gateway.
5. Once you have decided on the bank, the gateway and the shopping cart, it is then a matter of linking the three together. Still this is not the simplest thing to do. That is why most merchants still need a web developer or solution provider like IS to help them through.
** A shopping-cart system is a piece of software that automates the set-up of your online shop. It allows you to add, edit and manage your products, their prices and descriptions. It also assists the buyer buy guiding them through the purchasing process. A well developed shopping-cart system will allow you to customize it’s features, track orders, and manage your inventory, from your own computer – with no need to engage a web developer. Choice of the shopping-cart can be a whole new topic of discussion, although it is simple enough to say that Ezystore.com offers all these features.
Some exiting solutions
QSI (www.qsipaytech.com)
Queensland Systems Integration, based in Brisbane has developed one of the best solutions available today. This system offers one of the highest levels of security at a reasonable price. Presently the QSI system is offered by, Commonwealth Bank of Australia, Royal Bank of Scotland (pilot test at present), and HSBC (Hong Kong).
Cybercash (www.cybercash.com)
Cybercash is one of the most accepted systems. Cybercash makes use of several gateways (First Data Corporation, Paymentech, NDCeCommerce, Vital, Checkfree, Wells, NOVA, NPC and Sligos (European)) to gain access to over 95% of all acquiring banks in the US and some in Europe.
ECX (www.ecx.com)
E-Commerce Exchange offers a similar solution to Cybercash. They are linked to many of the major US banks and have a range of gateway solutions.
Netbanx (www.netbanx.co.uk)
Netbanx is a UK based payment system accepted by most of the major UK banks.
eGate (www.anz.com.au/australia/egate)
eGate is a proprietary system of the ANZ bank of Australia.
Banks and the Internet
Generally speaking the banks do not understand the Internet and at this point in time they have not fully grasped the situation. This is reflected in they way they implement gateways and the fees they charge.
Banks will often attempt to develop a proprietary gateway, thinking this is going to offer them a more secure solution and control over their merchants. The downside of this is that you have to modify your website to be compatible with a unique gateway. This is costly and difficult for the merchant. Most ‘off the shelf’ shopping-cart systems are not compatible with the proprietary systems that these banks offer so you need to develop custom solutions.
Banks often charge outrageous fees to cover their perceived risk. However this fee is completely unrelated to the gateway you choose. If you spend extra money and setup a very secure system (such as in Figure 4) the bank will not reward you for this. They will continue to charge you fees proportional to that of high-risk merchants. Of course the risk is really a combination of many things. Your record as a merchant, the size of transactions, and the type of goods are all part of this assessment. The Internet payment gateway is only a small part of this risk, but banks seem to place disproportionately high value on the gateway.
I firmly believe that an Internet Gateway such as that outlined in Figure 4 is more secure than any offline system used today. Presently merchants accept cards via phone calls, and fax and in all cases the merchant sees the card number (and could potentially abuse it). The banks have still not accepted the truth that a proper online payment-gateway is far more secure than present offline system. Until they do the merchant will continue to be charged to cover the bank’s unfounded fear.
Responsibility
So if something goes wrong, who is to blame? Where do the responsibilities lie? The answer in most cases is that the responsibility of ensuring secure safe transactions lies with the merchant. Before I say anymore I would clarify that this is not legal opinion and in any case the situation varies from country to country (even state to state). You must make sure you read the merchant contracts carefully before you proceed.
Lets say a buyer finds out that they purchased something (online or offline) and that the card number was stolen and then someone else illegally used their card to make purchases. The buyer would contact the bank and notify them that they did not make the purchases. The process is something like this:
- The bank will, in most cases, ask the buyer for a statutory declaration saying that they did not use the credit card for those purchases.
- The bank will then ask the merchant to prove that the correct cardholder made the purchase. This is usually by way of correct signature.
- If the merchant cannot prove the authorisation was valid then the bank will refund the money to the buyer immediately. The bank does not send the payment to the merchant. In this way the buyer is well protected.
- The bank then needs to find out where the fraud occurred. In most cases they then pursue the merchant first. It is the merchant’s responsibility to prove that they handled the card-transaction properly and that they were not responsible for the theft of the card. If the merchant can prove that they had adequate security (this is usually defined by legislation and bank contracts) then the merchant is free and the bank continues investigation in other ways.
- If they cannot prove that they used adequate precautions then the merchant faces legal action from the bank.
The message here is that, in most countries, the merchant must be very careful to use reasonable efforts to ensure security of transactions. Buyers, in most cases, are well protected. So when you decide to accept credit cards online choose carefully, and work with your bank closely to ensure they approve your setup.