Five API Characteristics to Look For When Selecting a Processor

Blog Post created by tboumil on Aug 30, 2017

Recently, I was at a cookout and talking with an old friend I hadn’t seen in several years. After going over family info, we moved on to careers, and when I told him I worked for Vantiv (and explained what we did), he perked-up and said he was about to expand his business (he owns several small stores selling souvenirs and collectables) to the Internet and wanted to pick my brain about how to select a good processor for eCommerce transactions. He was mostly concerned with the fact that his nephew, a recent Boston University graduate, was going to set up his site and do all the coding to send transactions to whatever processor he selected. While I had some suggestions, not being a coder myself I couldn’t answer all his questions. When I returned to work on Monday, I asked several Vantiv eComm developers to put themselves in a merchant’s shoes and let me know what they would want in an API. This is their list.


1. Good documentation, including usable and re-usable examples
I have to admit, being the Leader of the Technical Publications group at Vantiv, this item--and the fact that it was the first one several of the engineers mentioned--gives me great pleasure. They stated that having complete, well-defined documentation makes any code development much easier, while incomplete or inaccurate documentation can make code development a nightmare. Augmenting the documentation with usable code examples also makes everything progress more smoothly.

2. Consistency across the API

Most processors have large development teams working on different parts of their APIs. Some teams might be working on new features, while others work on updates to meet mandated card network changes. All teams should be uniform in their treatment of the API. The development groups need to have well-defined standards, conventions, and object naming and they need to adhere to these items. The end result for the merchant’s developer is an API that is readable, consistent, understandable, and ultimately, does what a programmer expects it to do.


3. Regular maintenance of the API
Is the API updated regularly? What is the cadence of changes? Is backward compatibility maintained? These are all questions you should investigate. If an API isn’t updated regularly, especially in the eCommerce world, it rapidly becomes stale and outdated. The card brands have a regular cadence of updates and requirement changes twice per year in April and October (though they also do some in between). A failure to update the API also indicates a lack of new feature development. You may not always have interest in a particular new feature, but you want your processor to be engaged in constant improvement. As for backward compatibility, you never want new development to force you into an unnecessary and expensive update.


4. A robust test environment

When you code to the API, you want to test everything. If your application/checkout page fails, the result is lost sales and an unsatisfied customer. You want a test environment that allows you to either do complete end-to-end testing or at least has the capacity to simulate end-to-end testing. You also want contact with a support group to assist you with resolving any difficulties during your testing and certification process. Most developers won’t need their hands held, but want someone responding to questions when they need help.


Finally, the test environment must support regression testing. Over time, your needs and code will change. When it does, you will want to test the API completely before deploying for customer use.


5. Popularity/Active developer community
You don’t want to go with an API that no one else uses, unless you are getting a great deal from a start-up and are willing to take your chances. Look for established processors with many users. Also, look on sites such as GitHub and see how many stars the API has from other developers. Last, but certainly not least, look for an active developer community. Other developers who have already worked with the API are a great source of knowledge and their comments are often the best measure of a good or bad API.