Understanding the Vantiv APIs

[douglasbay]

As a platform evangelist, I've had the opportunity to write applications that interface with almost all of the Vantiv API's (Integrated Payments may be next). In addition I've gone through multiple attempts to normalize everything into one API. I've also certified partners using Vantiv Solution Builder (VSB), Payment Web Services (PWS) (ISO8583 and 610) and the eCommerce (Litle) platform. What I've learned is that all of the API's are essentially the same (ignoring the message spec) as the data is funneling to the same place. Because of this, how Vantiv certifies partners is also very similar. Here are my general steps that may benefit partners as they begin to work with Vantiv. Note that my comments are from a developers perspective. The steps below should be run in parallel to the software companies work on business agreements, PCI compliance, merchant boarding etc.

Step 1 Technical evaluation : What are we integrating? Industry(s), development language, hosted or distributed, simple scope for quick deployment or complex to cover all needs. Does the developer or partner have a good understanding of the industry or is this their first attempt?

Note: This first step is always a balance of near term needs versus long term goals. If you over scope your solution, you'll likely spend more time developing and certifying. Time that you could be making money with either your current merchant base or a market segment you intend to sell to. If you under scope your solution, you may not provide enough benefit to your customers to attract their business. My general rule is to follow an Agile approach whereby you first build out the minimally viable solution that meets all of your current customer base needs. I'd recommend you bring up this topic with your implementation consultant once you begin the next step.

Step 2 Meet your Implementation Consultant (IC) : Your IC is your sherpa or guide to implement your solution. Based on Step 1 they will provide testing credentials, documentation, test scripts (test scenarios), sample code, industry guidelines, compliance, interchange guidance and much more to help you write the best solution that meets your needs.

Step 3 Develop, test and certify. Your favorite person in this step will be your IC as well as the documentation. You may ask why do I need to certify my solution? Other companies like Stripe don't have this requirement. True, however we feel that consulting (in this case free consulting by your IC) will help to reduce issues like declined or failed transactions, improperly or poorly implemented code, paying more in interchange, charge backs, understanding reconciliation, reporting, merchant boarding along with many other items that are worth taking the time to understand before turning everything on.

Step 4 Deploy to production and monitor. In my experience, many companies feel step 3 is basically the end of their integration. For many partners this is true as we've considered and implemented all of the things we need to account for in production. I'd strongly recommend however, that software companies allocate time into their planning for at least 3 months post deploy of "first merchant" / "first live transaction" to track the following.

1. Merchant account boarding and setup.
2. Perform reconciliation. Good software, should have the ability to know exactly what was processed, what was paid for each transaction (fees including interchange, transaction, value added services etc.), what was settled to their Direct Deposit Account (DDA) account.
3. Chargeback rates.
4. Production processing patterns. Statistics on processing like average processing time, standard deviation, max/min. Additionally they should maintain logging of communication failures that includes the unique identifier of each transaction, time stamp, reference numbers, dollar amounts. Key being, make sure in your logging you do not log sensitive information like card number, track number, CV codes etc.. This information is extremely helpful when reaching out to production support to research failed transactions.
5. Work out an easy to understand escalation process. Vantiv will provide customer support information which usually includes a phone number, email along with engagement guidelines. Make sure your support team has access to this information. Too many times I see partners reaching out to the Implementation Consultant or Relationship Managers or sales to assist. The problem here is that arn't always setup to respond at all hours and do not have the tools necessary to diagnose and fix the issue in a production environment. In many cases, reaching out to the IC or RM simply adds time to resolution. The sooner your operations team builds a trusting relationship with the Vantiv customer support team the quicker you'll see resolution to production issues. When production incidents occur, the first step will be for your team to triage if it's your code or Vantiv. Monitoring tools along with logs mentioned above will be your most valuable resources. Generally the most useful piece of information is the unique identifier of the transaction. Express calls this the "TransactionId", PWS calls this the "RequestId", eCommerce calls this the "LitleTxnId".

Step 5 Repeat steps 1 - 4 as your solution evolves or Vantiv launches new offerings.

Best of luck with your solution and feel free to ask any questions you may have.