Tuesday, August 14, 2012


Taking Credit Card Payments Online: What’s Involved?


If you’re looking to integrate a credit card payment solution onto your website, the following steps are a guide to applying for, enabling and taking payments online. At first glance, the prospect of integrating a payment solution on a website can seem unwieldy, what with the vast array of payment options and technical acronyms. This article breaks down the entire process into bite-sized pieces, helping you understand the process much better.

Apply For An IMA

When taking any kind of credit card payments connected to a bank account, you must apply for a merchant account with a bank. If the payments will be taken online, you’ll specifically need an Internet Merchant Account (IMA). In addition to banks, in many locations there are dedicated merchant account providers you can use.
Even if you currently take “card-not-present” payments (such as for mail orders) or use in-store payment terminals (such as chip-and-pin), you still have to speak with your bank about taking payments via your website (ask your bank for an additional IMA ID).
As a broad overview, your bank acts as the “acquirer,” which confirms available funds, authorizes transactions and exchanges funds with the issuing bank of the credit card (e.g. Visa, MasterCard), i.e. the card holder’s bank. The funds are then transferred to your account (the merchant), minus the applicable fees. The issuing bank’s charges are called interchange fees, and your bank’s fees are the acquirer’s fees. As the merchant, you should be informed of any fees prior to signing the merchant services agreement with your bank and payment service provider (more about this further down).
Your acquiring bank will expect your website to operate within a strict set of rules in order for them to comply with their own security procedures and government legislation (more on that later, too). Some credit card providers have developed the technology to allow card holders to authenticate themselves online. MasterCard’s is called MasterCard SecureCode, and Visa’s is called Verified by Visa.
It’s worth noting that it is possible to process Internet payments manually, using your regular point of sale system. This isn’t recommended, though, partly due to security reasons, and partly because it can quickly become too much work to manually process payments taken through your website (do you really want to have to key in a thousand individual cards if you suddenly have a huge uptick in sales?). Also, some merchant agreements may specifically prohibit this type of payment processing. Even if you do decide to process payments manually, you’ll still need an Internet Merchant Account, because it’s where the transaction is initiated that counts, not where it’s eventually processed.

Select A PSP

In addition to an IMA, you will need to use the services of a payment service provider (PSP). Commonly, PSPs handle the pages on a website where customers submit their payment details. PSPs provide a “virtual” cashier, or point-of-sale terminal, that collects card details, screens for fraud and securely passes the details to your acquiring bank for processing. PSPs are sometimes referred to as payment gateways.
The PSPs offer various packages and rates to suit the requirements of different merchants. The main difference between packages comes down to whether you want to host the secure payment pages on the PSP’s servers or on your own server. Some PSPs also provide tailored solutions.
It’s worth noting that some PSPs also provide IMAs, and some acquiring banks provide PSP services.

Payment-Processing Companies

As is often the case, there are alternatives to the approach outlined above, especially if you want to avoid the challenge of technically implementing one of these solutions. One alternative is to use the services of a payment-processing company. This option eliminates the need to apply for an IMA and PSP separately. The application process of a payment processing service is usually a lot less stringent than that for an IMA, which results in a faster set-up, especially if you have little or no trading history.
The disadvantage is that your customers will be sent to the processing company’s website in order to make their payment. Also, settlement periods can take much longer (up to 60 days), and your overall cost may be slightly higher than if you had gone with an IMA and PSP.
Not all payment-processing companies operate like this, though. Some companies, including PayPal and Google Checkout, remit payment immediately in most cases, directly into your account. In other words, as soon as the payment is made by your customer, the money is deposited into your merchant account.

A Sample Checkout Process

Here’s a step-by-step example of a common credit card payment process for any website:

STEP 1: THE BASKET

Your customer has added a product to their basket and is ready to proceed to checkout. The basket page on your website should be SSL encrypted to bolster the customer’s confidence (but that’s for another article).

STEP 2: THE CHECKOUT

The customer proceeds to the next page of your website: the checkout page. You can have various options here: account log-in page, shipping options, etc. But for the purpose of this example, let’s assume the first stage of checkout is simply a page that requires the customer to submit some personal details, such as contact info and a billing and shipping address.
Once the required fields are submitted and validated, the details are first securely sent to your back-end database, then wrapped up and securely passed to your PSP’s website. The customer is also redirected to the PSP’s website.
Let’s pause for a second and look at what’s happening here. Your customer’s data should be encrypted when sent to the PSP, not stored in plain text. So, you make a function call to your PSP’s API, requesting the transfer of data. The API’s function will usually require a set of parameters that include the merchant’s ID, a unique order reference, the transaction’s total charge and currency, and all of the billing and shipping mentioned above.
The function will then either return an encrypted version of your data, ready to be posted to the PSP’s payment pages, or hold onto the data and return a secure key in receipt that verifies that particular set of data against the transaction. You would store this key along with the order details and then redirect the customer to the PSP’s payment pages.

STEP 3: PAYMENT

Your customer arrives on the PSP’s secure payment pages. Technically, keeping the customer on your website at this stage is possible (if the PSP has this option), but let’s keep this simple. If the PSP’s pages duplicate some of the fields on your own checkout page (like the billing and shipping address), then these fields can be pre-populated.
Once all of the card holder’s data has been submitted and payment has been made, your customer is seamlessly returned to your website.
OK, some stuff is also going on in the background here, too. First, the card holder’s details are authenticated by the PSP using a variety of security procedures. Next, the card holder’s total charge must be authorized and the funds allocated to the merchant. Technically, the merchant should not take payment directly, but rather take a deferred payment until the goods have actually shipped (see the regulations on distance selling below).
Your PSP would then send the status of the transaction’s outcome to your website, along with the unique order reference (to identify the order) and any other pertinent data, including security-related confirmations such as CV2 and postal code checks.
You should make sure that your e-commerce store follows the PCI complance guidelines for storing, accessing and managing sensitive credit card data. This Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that all companies that process, store or transmit credit card information maintain a secure environment.
It applies to all organizations or merchants, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data. So, if any customer of that organization ever pays the merchant directly using a credit card or debit card, then the PCI DSS requirements apply. This server security standard is required by almost all major credit card providers, or you risk the potential for steep daily fines. (Thanks to Brian and Rebecca in the comments for pointing it out!)

STEP 4: ORDER CONFIRMATION

On returning to your website, the customer is presented with a confirmation page indicating whether the payment has been authorized or declined.
The PSP passes variable data (such as an order reference) back to your website, which you use to look up the order data on your database and present the appropriate content.
For more contact us at info@synergyforit.com
Thank you

No comments: