Since the mid 1990s the web has been used as a display case for all manner of endeavours. That the web is an interactive medium was quickly realised and utilised for buying and selling and so arose the need for security in a new medium where the customers and vendors were unfamiliar with the workings of the web. Attitudes to security ranged from unfounded reticence to unfounded trust. The internet was founded (in 1969) on trust and developed on that assumption till soon after the web was brought to public prominence (in 1994) and to all the aspects and behaviours of society thereafter.

The more anonymous a transaction the greater the security risk, and the web facilitated anonymity. Consequently schemes for security arose quickly, some were restrictive banks making unenforceable “rules” soon were also swept up in the social avalanche of the web and developed services such as electronic banking and BPay. Firms arose that sold large prime numbers, the algorithms known as Secure Socket Layers (SSL) evidenced in warnings, logos and padlocks displayed for some web pages and the https:// rather than http:// prefix to web addresses. Companies arose and fell as the technology they bet on such as providing e-commerce solutions became public domain and largely free for the taking. Much pricing was in perception rather than fact, many executives being unfamiliar and incredulous to the view that what was perceived as high value could be achieved at low cost. Credit card companies quickly saw the benefit and the risk of the web and intermediary services such as PayPal for trusted payments where the customer would set up an account continue to evolve.

From a vendor’s view, making selection and transaction (and of course delivery) simple, flexible and secure are necessary but also at some tension with each other. Coming to a reasonable balance, implementing it and maintaining it requires experience and expertise. An example of an often unrealised pitfall is the “secured” transaction process quite common for small businesses. They have a secure site through which a customer orders an item. The interchange between the vendor’s server and the customer’s web browser is secured by prime number magic and cannot, in any practical sense, be intercepted and read by a third party. What happens next is often not secure. Quite commonly the customer’s order along with the credit card details are emailed to the vendor. That email is not secured in the same way in transit, it is plain to view on the vendor’s computer and worse still may be printed onto paper and/or distributed about the vendor’s staff to fulfil the order as well as process the payment, it may go through many hands or just lie about. Given that this is a preferred business process for many vendors we developed a method to reduce the risk. That process to encode the credit card number of within the plain text email, so the order can be processed but the card number briefly decoded for processing the payment, at no stage need the card number be stored in plain text. The decoder can be held secured and can be pass word protected. We have used this system for over a decade for a multitude of clients whose business process requires emailed orders: we call our method “iorder”. It provides visual security where there is a lack of digital security

Many people knowingly send their card details by email or give them over the phone, but that is a risk known and accepted by each party. The banks and card providers have a clear interest in reducing the risk of ad hoc transactions, and the services they have implemented can also be used by on line vendors as well. These services include Bank portals which can be integrated into web sites so that the vendor never gets the card details, simply a verification of the transaction. This integration is often a skilled job especially if the vendor wants to maintain the “user experience” of their site as well as the simplicity and flexibility. As each bank’s portal is different, it is an expert custom task each time. Banks provide batch processing facilities, a vendor can create a text file from stored transactions and upload them to their bank. Such a method works well enough and is used by many large companies but there are implicit security risks given that such files are not encrypted and are of necessity stored somewhere on disk. Managing this process to reduce risk is also a custom expert task. Bpay, bank portal and batch transaction service usually cost the vendor more than they wish to pay on top of fees for eftpos facilities which they must use at a physical front of house. The iorder system allows vendors to process card payments through their eftpos facility or using one at a time bank portal payments and can be extended to the batch file production. Another option for vendors is to give a code and their bank account numbers to a client for a direct deposit. This is becoming more accepted as banks improve their security systems and the public realise that bank account numbers are not synonymous with bank logon details.

To maintain a balance simplicity, flexibility and security on your e-commerce site is a task with which we can assist.