Practical Ecommerce

Programming Notes: Linking To Payment Gateways

Payment gateways can be intimidating for many web developers. I have always found a certain amount of anxiety associated with them, particularly because of security requirements and presumed liability issues that could arise from insecure transactions. However, the actual integration with a payment gateway reveals that it is not much different than interacting with any other application programming interface (API).

The Process

So, to link an ecommerce application to a payment gateway, you must first select a gateway and then obtain an API username and password from it. This information will be included with all requests made to the payment gateway API, and provides your application with a way to identify itself and gain access. There are subtle API differences between the various gateway companies, so make sure you understand them if you are working with more than one.

Second, you will need to collect the information to send to the payment gateway, such as a customer’s credit card number. In order to be PCI compliant, developers need to ensure that this information is always encrypted when it is transmitted. Also, be aware of what information you will need to collect, as there can be multiple verification methods, depending on your gateway.

Once the information you need has been collected, payment requests can be made to the gateway. Typically, a gateway will send a series of responses to the application, allowing developers to troubleshoot and make decisions based on whether the transaction was approved or not. Developers have a precarious balancing act at this point. They need to save enough transaction information for accurate and usable records, such as payment number and card name. However, this data must meet PCI compliance standards, which means the information needs to be encoded and access to that data must be limited and controlled.

Interacting with a payment gateway is more intimidating than difficult. Because gateways offer robust APIs, the actual payment process is made simple for developers in most cases. However, take the extra time to ensure that the application is secure and otherwise meets PCI standards.

Brian Getting

Brian Getting

Bio   •   RSS Feed


email-news-env

Sign up for our email newsletter

Comments ( 4 )

  1. Legacy User January 29, 2008 Reply

    Not all gateways are "robust". For example, Google Checkout is extremely limited in flexibility (though it is technically a cart-provider rather than a payment gateway). I.e. you can't identify a URL to return to once the checkout process is complete (user must click a 'return to' link). Also, limited information is returned which will require vendors to "fudge" on their other Terms Of Service with their shipping carriers (I.e. no ship to phone number is returned so merchant must use the buyer's phone number for their shipping).

    Other gateways such as PayPal add extra hurdles to the process to get a merchant's customers to sign up with their service.

    The the line between a payment gateway and a cart-provider is getting thinner all the time.

    Best approach is to manage cart information within a merchant's site (and the checkout process) and then simply use a payment gateway such as Authorize.net for the actual credit transaction.

    tony
    ez-order-manager.com

    — *Tony Birnseth*

  2. Legacy User January 29, 2008 Reply

    The easiest gateways to integrate with are going to be the ones with the most support and current use. Authorize.net is probably the easiest, as there is a lot of documentation and ready-made scripts for it. The more robust a gateway's API is, the less usable it is for the majority of programmers and uses. Watch a do-it-yourself'er try to integrate a SOAP or Google checkout API into their website. It's just not going to be pretty, if it happens at all. Paypal while also not a payment gateway by definition offers advanced features but can be scaled down for a simpler integration that works in many cases where an advanced API is overkill.

    When you get into SOAP API's and advanced XML API's, it's overkill for much of the required use of a payment gateway. A payment gateway's API doesn't need to be super complicated for it to be PCI compliant and very usable.

    When in doubt, go with Authorize.net.

    — *Jestep*

  3. Legacy User May 9, 2008 Reply

    I've been using a payment gateway service called Cardstream Payment Gateway. Cardstream is a global payment gateway which enables merchants to process, authorise, settle and manage card transactions 24/7. Card transactions can be processed online, by telephone or via laptop, PDA and mobile devices. Amongst the many online payment services I found cardstream very efficient and I highly recommend them to anyone looking for a payment gateway.

    — *Chris*

  4. David Durick October 25, 2008 Reply

    I couldn’t agree more having worked with many developers on coding for payments. That’s why we just released a (non-programming), well almost non-programming method for any shopping cart or ecommerce merchant to add payments through our gateway. Our standard API, similiar to Authorize.net to any of the other ones out there requires a lot of coding and testing. We realized it was time for someone to create a simple method to send customers (with customer data if you want to) to our payment page and no coding to the complicated POST and GET etc. Specs had to be done. Also, since we capture the customer’s name, adress, and other contact information in our payment page, the ability for the merchant to pull up the customer by more than a phone number or Authorization number makes it great for research, especially if you have a lot of transactions.