Let’s begin this section by stating that there are several caveats to consider when embarking on the journey to credit card payment bliss! The main one is that it can be quite a pain in the proverbial back end of your application getting an Internet Merchant Account. This is because Internet transactions are considered to be at a high risk from fraud, and one result is that transaction fees are often higher too. There is not really much help that this book can offer you in terms of obtaining a merchant account—this is between you and your bank or merchant account provider.
For more information on obtaining merchant accounts, visit the service providers of your choice, who will have plenty of information about how to use them and how to find your way around the system in general. For example, all the following sites will furnish you with plenty of relevant information to help you make your choice:
Secondly, you need to make absolutely certain that you are not providing a platform for hackers to gain access to customer’s credit information by not implementing proper security over the entire site. If we were to accept credit card details with the site in its current form, we would certainly be deserving of the term negligent in our responsibility to protect client’s information, because there is no secure method of information exchange between the clients, us, and the financial institutions that we need to interact with.
Note
While we are setting up payments using credit cards here, you should not consider the job complete until you have implemented security for the payments, which is discussed in the following chapter.
Cheer up, though; it’s not all doom and gloom. Apart from what has just been mentioned, the process of getting set up is much the same as it was for PayPal. Before we go any further it might be worthwhile to lay out all the players in the credit card transaction world so that you have a fair idea of what you need to do to get things working:
- Merchant Account: Anyone who wants to process credit card payments themselves (as opposed to letting PayPal handle it) will need a merchant account. Further, if you want to provide online payment facilities, you will need an Internet merchant account, and not your run-of-the-mill account. For some businesses it is particularly difficult to obtain a merchant account—however, so long as you stick to retailing fairly tangible goods you should be safe in this respect. Anything that leaves a verifiable trail comes in handy as proof should the question of fraud arise.
- Acquirers: Any institutions that issue merchant accounts, often banks, are known as acquirers. For example, HSBC and Barclays are two well known acquiring banks.
- Payment Service Provider: These companies, among other things, have as their main focus the task of facilitating payment transactions for merchants (such as yourself) via a payment gateway.
You might find that depending on whom you work with, your acquirer offers full support for your payments transactions, in which case you may not need a payment service provider. Of course, most of the payment modules available are for use by payment service providers, and not the banks directly.
Note
Having set up PayPal facilities, customers are already able to pay with their credit cards or bank accounts. Adding credit card facilities here is really an exercise in making non‑PayPal customers’ lives easier.
So, the process is still the same as it was for PayPal:
- Sign up with the relevant corporations to obtain a merchant account or a payment gateway.
- Install the relevant module.
- Test, test, and test again.
- Rake in the cash.
Accordingly, there isn’t too much to discuss by way of anything new here other than to show a couple of examples in action. We will begin with the Credit Card module and also demonstrate the PsiGate payment module.
You can make use of the Credit Card module to process payments manually if you have a merchant account. Basically, the details that are provided on the site by the customer are simply stored in the database, ready for you to process them accordingly. On the surface of things, this seems like a really nice and easy way to do things, but don’t be fooled, you can get yourself into a lot of trouble doing things this way. Let’s look at how everything works so that it is clearer.
Head on over to your admin tool, and click on install for the Credit Card module and enable the module by setting the first option to True so that your page looks like this:
Update that, and head on to the site and make a purchase. When you get to the checkout-payment page, you should now have the option to receive credit card payments; enter the dummy credit card value and add a date later than the current one as the expiry time, like so:
Carry on with the purchase until you receive the checkout success page, and then go to the Orders section of the admin tool and take a look at the information given for this latest purchase. You should have something that looks a lot like this:
A sight like this will generally have your average security expert in tears because not only are we storing the customer’s credit card information in our database, but we are also allowing access to that information bundled up and presented in a nice report format. If anyone ever gained access to the admin tool, they would be able to read off client credit card information from here. Even worse, if a hacker ever gained access to the database, they would now be able to read off all the credit card information directly from the database.
"Sure, but this will all eventually be password protected, and we will be adding security later" I hear you say. Well, actually this very module comes with a bit more security, so let’s try that out. Go back to the payment module’s edit page and add in an email address to which you would like half of the credit information sent. Save that and repeat the process and notice that this time the order page looks like this:
Well, that’s slightly better because now if someone gained access to the site, he or she would only be able to get their hands on half of credit card info; the other half is not held on the site. Instead, it has been sent via email to the address you specified:
Now you can simply match the middle numbers to the outer numbers via the order number, which is common to both records, and are thereby able to retain the complete details without running the risk of holding all the information in one place. While this is much better, it is still exceptionally poor in terms of the type of security you should be hoping to implement, because that email has been sent to you in a non-secure manner.
Assuming someone knows that this is going on, they could intercept the unencrypted message and match the numbers up. This might all seem like quite a reasonable risk to take, but bear in mind what is at stake your livelihood. If customers find out that your site, and therefore their private financial data, has been compromised (and they will because they will notice fraudulent transactions on their accounts), then as a business, your reputation is more or less irrevocably destroyed.
While you could always take the information and encrypt it before emailing it to yourself, you will still have to work with this information, and somewhere along the line there will be a chink in the armor. Rather don’t take the risk at all, and let someone else handle it—there are plenty of reputable businesses who plow far more resources than you or I could into making their services secure, so that you can use them. It may hurt to fork out for the service, but it’s nothing compared to the trouble you could land yourself in.
Having seen how the Credit Card module works, let’s move on to look at how one of the service‑provider modules functions.
It’s important to bear in mind before we test this module that each gateway service might have a slightly different methodology for processing credit card payments. For example, those of you who try SECPay will notice that at no time does the customer enter credit card details onto the merchant’s site—instead, the browser is redirected to a secure payment page on the SECPay server, before being returned to the merchant site once the payment details have been entered.
Note
Whatever module you choose to use, or even if you choose to write your own application code to handle payments, setting everything up is really all about learning how your gateway service operates and using that knowledge to integrate its service into your application.
PsiGate makes it easy for us to test our application because we can run test values off it without having to register with it first. Consequently, pretty much the only thing you need to do is install the module in the Payments section as you have seen in previous examples, navigate to the payments page on your site, and run through the payment process as normal.
The astute observer will notice a slight difference in the processing of payments once the PsiGate option has been checked. Let’s run through that quickly because it will also illustrate the generic process followed by all the other gateway services (more or less). Suppose you have entered the relevant test info into your site, so that your page looks like this:
Click on Continue to get to the order confirmation page. This is where things change a bit behind the scenes. Once the customer confirms his or her details are all correct and clicks on Continue, that information is sent to a secure PsiGate server instead of simply being held on your site. You can view the status bar in your browser immediately after clicking on Continue to confirm this, and can also see a quick notice from the actual PsiGate site before it redirects the customer back to your store, like so:
Notice from this screenshot that we are actually executing the Process.asp page on the https://order.psigate.com/ URL, and the target URL, shown in the Status bar at the bottom of the screen is the checkout_process.php page back on the store’s server. As well as this, the session is preserved because the target also includes the session ID parameter (not quite visible).
So, what has happened here is that your store’s server has sent information to the PsiGate secure server, which has processed the information and returned its results. If the transaction has been successful, the customer sees the usual Your Order has been Processed message on the checkout success page (or whatever your equivalent of this is). If the order is not successful, then the error is collected by the payment module and outputted to the customer’s screen.
So what type of options do we have to work with? Well, as we showed for the PayPal section, here is a table representing all the options and their values and meanings:
|
Property |
Setting | |
|---|---|---|
|
Enable PSiGate Module Do you want to accept PSiGate payments? |
Obviously this is set to True if you want customers to be able to use this form of payment. | |
|
Merchant ID Merchant ID used for the PSiGate service |
This ID will be assigned to you once you have an internet merchant account. Please see the PsiGate site for more info on this: http://www.psigate.com/faq.asp. | |
|
Transaction Mode Transaction mode to use for the PSiGate service |
The first value, Production, should be enabled once you decide to go live. The three that follow are used for testing purposes to ensure your system is behaving correctly. For example, select Always Good to test for successful transactions while testing. | |
|
Transaction Type Transaction type to use for the PSiGate service |
Setting this to Sale means that PsiGate will treat this as a normal transaction and transfer funds appropriately—use this only if the product reaches the client immediately (in other words, the product is downloadable). PreAuth will ensure the funds are available (reserved), but will not perform the transaction—this is left for you to do manually from your PsiGate Admin section once you have delivered the product. Use PostAuth if you want to settle a PreAuth transaction which reserves funds. You must have the PreAuth order ID and the correct amount to do this—for more info see the PsiGate docs at www.psigate.com/java.pdf. | |
|
Credit Card Collection Should the credit card details be collected locally or remotely at PSiGate? |
You can choose whether customers will enter their credit card information onto your site or onto PsiGate’s site. If in doubt, take the responsibility off your hands and pass the buck to PsiGate. | |
|
Transaction Currency The currency to use for credit card transactions |
The only two options for this module are Canadian dollars and US dollars since PsiGate only deals with these two currencies. | |
|
Payment Zone If a zone is selected, only enable this payment method for that zone. |
Once again, you should select the zones you wish this module to be enabled for. For example, you may prefer to use PsiGate in North America, but SECPay in Europe. | |
|
Set Order Status Set the value for the status of orders made with this payment module |
You can set this to whatever value option you like; however, remember to be consistent in your choice of status because you may wish to programmatically implement features based on the Status of payments at some stage. For example Preparing [PayPal IPN] is not a bright choice because this has nothing to do with PsiGate. | |
|
Sort order of display. Sort order of display. Lowest is displayed first. |
As usual, you can select the order of appearance using this option. |
There are, of course, many other modules that you may opt to use depending on your business’s needs and setup. The exact manner in which the module implements the payments is really dependent on the gateway that you are using, but what you have seen here is a good outline of what is expected once you have an internet merchant account against which to run e-commerce transactions.
One final thought before we move on. If you are concerned about the safety of your business and wish to know more about how to prevent or reduce fraud, then visit your payment service provider or acquirer online and look over their fraud-detection software or other such products. With that out of the way, we should briefly look at a few more methods of payment, which might come in handy somewhere along the line.