IP Commerce provides an “open commerce network” that supports several types of payment transactions: credit card, debit card, stored value cards (gift/loyalty cards), and eCheck/ACH. It took me a while to figure it out, but when they say “open network” they mean a network that any payment service provider can hook into to provide services using a single API. This is pretty cool, since it abstracts out the payment provider APIs and allows you to use multiple payment providers, or switch between them with ease. This is a far cry from building one-off integrations, which most of us have done only to have to re-write them when we switch providers.
In my opinion, this network isn’t for small websites looking to process credit card transactions. If you are a small ecommerce site, connect directly to PayPal or Authorize.NET and be done with it. It’s not terribly complicated and re-writing the 50 lines of integration code is not going to kill you if you have to switch later on (or better yet, buy .netCharge, which abstracts the providers out using code instead of a network).
However, the major value here is for anything larger than a single website processing credit card transactions. If you’re building POS software, or you want to support eChecks, gift cards, and credit and debit cards, then you should take a look at this.
I visited Commerce Lab, which is their portal for payment application developers looking to build apps on their platform (currently geared towards .NET developers). The site is straightforward, with a quick tutorial available, and most links leading you to download their Commerce Toolkit for Applications, which includes a .NET Sample Application that performs credit card, gift card, and eCheck transactions, and several PDF docs for developers getting started with the platform.
C# Source code is included, which makes it a slam dunk for wiring up the basic functionality they cover in the the sample application. I could go from nothing to processing credit cards in about 10 minutes (not including the API credential setup) given the code they’ve provided. Performing more advanced functionality not covered in the sample application would obviously take some additional digging.
Speaking of digging, I give the help docs a 5 out of 10 – they do list every class and method of the API, but the descriptions for many of them are empty, and with the number of classes required for a complex system like this, having detailed documentation is a must. They also provide online support via a knowledge base and ticket system, and distribute info via their developer blog (although only 7 posts so far).
An interesting note is that the API does not use web services. Call me a lazy .NET developer (no really, call me that), but working with sockets is not something I enjoy. But having worked in the credit card industry for 2-1/2 years I know that the performance difference between sockets and web services is insane. Pretty much all of the big payment service companies still use sockets due to the sheer volume of transactions they need to support. When I contacted IP Commerce with this questions, they indicated they chose sockets for performance, but if there is enough demand in the future they would consider a web service-based interface.