Reading Time: 2 minutes
We all know that e-commerce has been a rapidly growing phenomenon over the last 10 years. All things related to shopping have become easier: you no longer need to go to the supermarket to buy groceries or to a travel agent to book your holiday tickets. All these things are made possible through the ease of online payment transactions.
But do you know how exactly e-commerce handles your sensitive credit card data? Now I’m going to explain the different approaches websites use for receiving credit card information and when they should be implemented.
This type of payment process is the more traditional flow. In this instance, the web server will personally process the credit card transaction. The process begins when the customer submits their credit card using a form on an e-commerce website and hits the submit button. The website connects and sends the credit card data to the web server. This hosted web server then connects to the payment gateway, where the actual financial transaction takes place. The payment gateway returns the results (success or failure) to the web server and then back to you on your website.
Because credit card data is being passed through the web server, you will need to ensure this is a secure server that supports PCI-DSS (Payment Card Industry – Data Security Standard) at a minimum. We don’t recommend this method for most clients. There are severe security risks when hosting your own e-commerce web server which deals with credit card data directly, even if that server does support PCI-DSS. This type of approach is still can be utilised, but more secure practices exist.
Client Side Encryption
This method works similarly to the Server-to-Server method but with better security. This is because it works by encrypting credit card data on your browser. When the customer submits their card info (generally a 12 digit credit card number and 3 digit CVV number) the browser replaces this raw information with a long, encrypted, alphanumeric character before ever being sent to the web server.
This type of data is nearly impossible to decrypt and abuse. This has an advantage that if the web server is ever compromised and hackers do manage to steal the credit card data, it is almost impossible to misuse. An encryption system should be used for clients who have the ability to manage the security of the system themselves, typically larger clients with a complex checkout process or with a high volume of transactions.
This is the most powerful and secure method, the simplest to implement and the method we typically suggest clients use. In this instance, the user’s credit card details are never sent to your web server and are instead handled by a third party. Instead of communicating with your web server, your customer’s credit card details are communicated directly to the payment gateway, and the payment gateway returns with a token key that you can use to complete the purchase. So instead of encrypting your customer’s credit card, this method replaces all the data with a token key.
So which one should you choose? That all depends on how complex your purchase flow is. If you plan to have a complex form, like sign up with payment information on one page, and you need to access different data from your web server, we suggest you use Client Side Encryption because of its flexibility with custom validation. Join me next time to see an example of these systems at work.