We have built modules to connect customers’ web portals to online payment gateways operated by most of the Indian banks and financial institutions. There are tricky parameters which need to be fine-tuned for reliable integration with payment gateways, and our experience in supporting our existing customers has given us depth in this area. We do not have any open source codebase for payment gateway integration; we have our own reusable modules.
We have worked with payment gateways of various agencies, many Indian, some foreign. We have not developed a payment gateway ourselves; we have integrated business applications with payment gateways to allow our customers to charge their customers through these payment systems.
The first time we saw a payment gateway was in the mid-nineties, when some of us were working in a different assignment and had to integrate credit card payment systems into our e-commerce application. We used the services of a company called Cybercash, and integrated our code with their Perl libraries. In this approach, we displayed Web forms to accept credit card information, then pumped this data out through the Cybercash libraries to the Cybercash servers and registered the credit card transaction. This was done in real time, and mostly worked, except for bugs in the Cybercash libraries. It exposed our server to the liability of knowing and possibly leaking the customer’s credit card data. The Internet was the Wild West at that time.
Modern e-commerce sites do not need to ask their users for credit card information, other than some of the largest sites which have the confidence and expertise to handle this data themselves. Most sites today redirect the customer to a third-party payment gateway site and this site is the only server which accepts and records the credit card details. The merchant site thus has reduced liability regarding protection of the credit card information.
Modern payment gateways have become complex multi-tier structures themselves. It is now quite common to have the merchant bounce the customer to a payment gateway, which then bounces the customer to a second gateway operated by the card-issuing bank. After the customer authenticates himself on the issuing bank’s server, he is bounced back to the merchant’s payment gateway, which then carries out the transaction and bounces the customer back to the merchant’s site. This multi-bounce structure allows the issuing bank to implement its own two-factor or other sophisticated authentication and reduces credit card fraud — at least, that’s the idea.
For one customer, we created a payment gateway integration layer which abstracted away all details of the real payment gateways. One may say we added an (invisible) additional bounce to the multi-bounce structure of payment gateways. Since this was not visible to the customer, no feathers were ruffled or customers disturbed in the process. It worked in the following way.
We implemented a payment gateway integration service listening on a specific URL. Whenever any online business application needs to charge a customer’s credit card, it makes an HTTP request to this service, giving an SKU code and payment gateway ID. Our service maintains an internal mapping of all SKU codes supported, and maps each SKU to a money amount. It then relays the request to the specified payment gateway using the protocol, URL, etc. required by it. When this relay happens, the customer’s browser is redirected to the payment gateway page as is customary, and the customer jumps through the required hoops to complete the transaction. At the end, the control returns to our integration service, which logs the status with full details and returns a response to the business application.
The integration service therefore completely hides the details of individual payment gateways from the online e-commerce application. It also keeps a central repository of all SKUs being sold and a central transaction log of all transaction attempts. This has a positive spin-off; there is now a central place to do bank reconciliation with all the participating payment gateways. Each payment gateway operating agency offers a plain text or XML file once a month for reconciliation with merchant accounts. The integration service provides an interface through which such files may be uploaded and an automatic reconciliation happens, throwing up unmatched transactions. If the integration service did not offer this feature, each business application would have to build this anew.
Our customer is very satisfied with this centralisation of payment gateway interaction. They can now add and remove payment gateways with minimal business impact on their e-commerce applications, and can implement policies of spreading their transactions across multiple payment gateways in specific ratios. A single integration layer has the ability to hide failures of single payment gateways from the customer — if one gateway is down; the integration service simply diverts all subsequent transactions to another gateway. This improves service availability.