Using a Payment Gateway on your Web Site

This page contains general information on using third party payment gateways with a web site hosted on Alentus web servers. This is a general purpose guide intended for the programmer or web site designer, and discusses various issues involved in integrating an e-commerce payment gateway with your web site.

A payment gateway is a service that can be used to process credit card transactions when accepting online orders from your customers. Payment gateways are provided by banks and other dedicated Payment Processors, and you are required to establish an account with a Payment Processor before you can use their services. The requirements for an account vary from service to service, with specific requirements described on the web sites of most gateway providers.

Note that Alentus Corporation is not a Payment Processor, and we do not operate payment gateway servers. While our servers are general purpose web and database hosting servers, payment processing is handled by servers operated by the payment gateway service provider. Our servers do host many sites that are successfully using third party payment services to manage payment processing.

Payment Gateway Service Providers

Payment gateway service providers are companies that provide the payment processing servers and associated merchant credit accounts used to accept credit card transactions and other forms of payments over the Internet. The service provider may be a bank or other company associated with the major credit card vendors. Payment Processors offer a variety of specific services associated with e-commerce transactions and charge rates and fees for providing such services.

Generally, there is a fixed monthly fee and/or per-transaction fee that you must pay the gateway provider for transactions performed on your account. You may also be required to put down a deposit on your account and there may be other financial or legal obligations you must meet prior to activating your account.

In a typical electronic transaction scenario, the Payment Processor's web site will handle the actual payment transaction with the online consumer, and the Processor's back-end system will manage the collection process with the credit card vendor. In short, the Processor will collect the payments from your customers, deduct any fees, and transfer the remaining funds to your bank account. The actual rates and features depend on the service level provided for by the Payment Processor.

Since there are many Payment Processors operating on the Internet today, we cannot recommend any specific vendors. Many customers use the following Payment Processor gateways on Alentus servers such as:

1. LinkPoint (www.linkpoint.com)
2. PayPal (www.paypal.com)
3. Verisign PayFlow Lite
4. Verisign PayFlow Pro
5. Authorize.NET (www.authorize.net)
6. Moneris
7. CCNow (www.ccnow.com)
8. PlanetPayment (www.planetpayment.com)
9. CyberCash
10. Echo COM
11. Payment Tech
12. PSIGate
13. WorldPay
14. Cybersource
15. HSBC/ClearCommerce

The choice of Payment Processor is affected by many variables, we recommend you investigate a few providers before you submit an application to any particular gateway service.

Payment Gateway Software

Most sites using a payment gateway on Alentus servers are coded in ASP (Active Server Pages), and contain a large degree of customization specific to the particular business or the goods and services being offered. Tight integration of the shopping cart with the rest of the site is usually a requirement, and the actual cart itself does not usually need to be very complex.

To create a reliable, robust interface to the gateway, you will need medium to advanced programming skills and should have experience with HTML forms, ASP scripting and managing data in a web application.

An alternative to a custom application is an off-the-shelf shopping cart application. Off-the-shelf applications have the advantage of being pre-coded and are generally well tested and most of the bugs have already been worked out of them. This can significantly lower your development time and cost.

However, an off-the-shelf application may not integrate well into your existing site or may not provide the exact functionality you are looking for. You should carefully evaluate several applications before settling on any one for your site. There are now many such applications on the market, and most of the ASP-based shopping carts will work on our servers. If you have a specific shopping cart application in mind, let us know and we can tell you if we can support it.

Integrating the Gateway with your Web site

Web sites hosted on our servers can integrate to nearly every payment gateway provider. Most gateways will provide you with a web URL you use for transferring control from your site to theirs to handle secure transactions. Once your site transfers the customer to the providers gateway, all further processing is completely handled on the gateway server and does not even occur on your web site. You do not need SSL on your site (as it's available on the payment processor's servers), nor do you need secure data facilities for storing credit card numbers.

A typical e-commerce application usually involves browsing a searchable catalog and adding items to a virtual shopping cart. At some point, the cart software will collect details from the customer - such as name and shipping address - and then proceed to the payment details stage. For the sites hosted on our servers, this is all usually done through HTML forms and ASP scripts. When the shopping session proceeds to the point where the customer is ready to make the payment, most sites will usually present a final page displaying the customer data, order details and a "Confirm Order" button.

On this final confirmation page, you will normally find an HTML form with all necessary information loaded into hidden data fields. “The action button on the form is a link to the remote gateway where the payment information will be handled. Usually the action button is labeled "Proceed to Payment", "Confirm Order" or something similar. Depending on whether your shopping cart (A) performs all interaction with the payment gateway in the background, or (B) if your customer is directed to the payment gateways site to collection payment information, will determine if you require an SSL Certificate for your website. For A, you will require an SSL Certificate which can be conveniently ordered through Alentus.

For (B) if the customer clicks on the confirmation button, they will be sent to the payment gateway server (via a secure HTTPS URL). The gateway will securely handle all collection and processing of credit card information. Since this is all done at the gateway, there is no need for your web site on Alentus' server to collect the card numbers and you do not need to use SSL. If the transaction is successful, the gateway will return control to your site by calling a "Thank you" script or, in the case of a transaction failure, control will be passed to a "Sorry transaction declined" script on your site.

Note: It is usually a good idea to generate a unique Order ID and save the entire order to a database before passing control to the gateway. If the user spends too much time at the payment gateway, the open session on your web site will time out and any session variables will be lost. Most gateways can send the Order ID back to the 'thankyou' and 'sorry' scripts which can then query the database and reload the order. This is most useful if the transaction fails so your customer can try the gateway again without having to go back to the shopping screens and reload their cart. Cookies can also be used to reference a customer's order information.

Alternatives to using a Web-based Gateways

Other alternatives to a web based gateway is to use COM components from the gateway provider, or an API library if they offer one. To make these work, you will need to obtain specific documentation from the gateway provider and write or buy an application that directly interfaces to either their COM component or API library.

We generally recommend against specific COM components or custom API applications, as they are usually more difficult and expensive to write and can end up being less reliable than the simpler web-based approach. In addition, COM components and API's often require registry entries, executables or other components loaded on the web server. There may also be additional setup fees involved, licensing fees or other issues that make this approach less attractive than the simple web gateway. The advantage of using COM or API based applications are that they may perform better, or may have greater functionality than a basic HTML/ASP-based application as described above.

Writing ASP scripts that use a payment processing COM component is usually simpler and faster to code than writing a compiled C or Visual Basic application. COM components usually have properties that you set with the data gathered from your forms. When you are ready to perform the transaction, you typically call a method of the component, which instruct it to transfer your data to the remote gateway.

Writing a full executable application usually requires one or more professional C/VB programmers with significant experience writing complex based web applications. Depending on your requirements, this can end up being very expensive, time consuming and is only recommended for organizations with the necessary capital and professional programming resources available.

A script will generally perform more slowly than a compiled application, but we have found that the performance difference is not actually noticeable on most sites.

The cases where a compiled executable application is recommended is for true high-volume online ordering systems. If you realistically expect thousands of orders per hour, a custom component written in Visual Basic or C offers significant improvements in performance and much lower resource requirements per transaction as compared to ASP scripts.

If you want us to host a site that requires specialized COM components or uses a compiled executable program, please let us know your exact requirements before you invest significant resources developing or purchasing such a system. There are some limitations to what we can do in a shared hosting environment, and we may not be able to support some configurations.

Bandwidth, Transaction Volumes and other Considerations

If your site has high traffic requirements and you expect to process large volumes of transactions, you may require a dedicated server. You may also need dedicated bandwidth for your site to ensure that all customers can reach it during peak periods. Sites with extremely high volume usually require multiple dedicated web and database servers and multiple redundant data lines.

When attempting to determine your required level of service, a good rule of thumb is the overall traffic to your site. If your site generates 20GB per month or more in traffic, you should be looking at dedicated services. Many ISP's (including ourselves) will not allow extremely high traffic sites on shared servers, as they degrade the performance of the other sites on the server and can also contribute to premature failure of the hardware components, particularly the hard disks.