Skip navigation
All Places > Developer News and Updates > Blog > 2017 > April

I remember years back in economic class, learning the concept of the "Invisible Hand" influencing markets to find natural equilibrium. Around this same time I read a book called "Kiss, Bow, Or Shake Hands"* that emphasized the importance of customs and protocol's for doing business in other countries. For some reason the two seem very intertwined in my mind as critical to doing business right. On one hand there are forces impacting a business that we are not always aware of. While the other hand we may be doing business without knowing how we're blundering through and insulting those we hope to do business with. Two months back, I was assigned to work with our data science and product team to help bring to market Vantiv BizShield and Insights powered by Womply.


As many are aware, what we don't know or see can and usually does impact our business. For a merchant, this typically takes the form of our social media presence (or lack of presence). Most merchants don't have the time to keep up with social media sites. Vantiv BizShield is the first defense for merchants. BizShield alerts merchants when they get a review so that they can take action. So as the invisible hand of the social media world is constantly shifting, the merchant is kept aware of what's going on. The next level of defense is Insights. Insights allows the merchant to take action and improve their social marketing position. In some cases the merchant may not know their business name is unclaimed (and possibly getting negative reviews). Or in other cases the merchant is receiving positive and negative reviews that they need to act on to keep their name as positive as possible. As part of this engagement they are learning how to engage their customers. So as the invisible hand of social marketing is impacting a company, insights is helping to properly engage and resolve customer concerns as they happen.


Here are high level features of both solutions


Future Webinars


Past Webinars

(4/20/2017)- Coming soon



Q&A: Questions










  • BizShield

  • Insights


Learn More


Recent News



*Terri Morrison and Wayne A. Conaway

**Winning Them Over is The Key to Growth

As developers know, APIs come in all shapes and sizes.   In this article, I’ll look at how APIs are commonly used in payments and offer a framework for classifying some of Vantiv’s more popular payment APIs.


Webopedia defines an API as follows:


“An Application Programming Interface (API) is a set of routines, protocols and tools for building software applications.  An API specifies how software components should interact.” 


Obviously, this is a broad definition. It covers everything from opening an OS file to accessing hardware features on a graphics card.  In payments, we can frame APIs more narrowly.  Most payment applications are transactional, and involve sending and retrieving messages to and from remote systems across dedicated links or IP networks.  Examples include authorizing a payment, setting up a subscription, or initiating a bank transfer from a mobile app.


Because most payment transactions are message-oriented, protocols loom large in payments.  Below is a description of five types of APIs common in payment applications.


1. Message formats & protocols


The core protocol used in payments is the ISO 8583 standard.  Although it meets the definition of an API, it is better described as a protocol or message format.  ISO 8583 messages may travel from a merchant terminal or ATM, through to a merchant acquirer, through to card networks, and ultimately to card issuing banks.  The standard is quite detailed and coding ISO transactions requires a sophisticated understanding of how payment networks operate.


ISO 8583 format message are usually sent over TCP via socket connections, but it can operate over other transports as well including dial-up, direct links or X.25 networks.  Most developers probably won’t code ISO 8583 messages directly unless they are working at a large retailer, bank, payment processor or payment gateway.


Vantiv provides Enterprise retailers and high-volume merchants with the ability to code directly to our core payment systems using the ISO 8583 standard.  When ISO messages are sent across the wire they are very dense and look like a stream of characters with many bit-mapped or binary coded fields.  A parsed view of a partial ISO 8583 message is shown below.  These types of message provide developers with complete flexibility and access to all network features, but they are difficult to code to.  To make integrations easier, Vantiv also exposes more consumable APIs, message specs and SDKs to developers (discussed below) where we manage the translation to ISO 8583 behind the scenes.


partial ISO message.JPG


2. SOAP XML Web Services


SOAP refers to the Simple Object Access Protocol.  SOAP is a W3C XML based standard that allows organizations to publish interfaces such that they are discoverable and platform agnostic.  Interfaces are described using WSDL, the web-services description language.  SOAP Web Services are most commonly provided over HTTPS, however SOAP can run over other transports as well.  The protocol provides an envelope, a set of encoding rules for expressing application defined data types, and a convention for representing procedure calls and responses.  SOAP can be a little verbose, because it was designed to have a lot of functionality.  Several Vantiv platforms expose SOAP interfaces including Vantiv’s core platforms, Vantiv’s eCommerce platform, Vantiv’s Express Platform and the MercuryPay platform.


A nice property of a SOAP API is that it is self-documenting.  For example, visiting the endpoint of the MercuryPay SOAP API ( in a browser shows the available SOAP methods and documents how they are called.




While SOAP is widely accepted as an industry standard, for applications that don’t need all the functionality of SOAP, simpler HTTP POST APIs have become popular.  With these types of APIs, developers create their own HTTP requests and send messages directly to a network endpoint.  Although we refer to them as HTTP APIs, it is standard practice to send traffic over an SSL/TLS encrypted HTTPS connection.


HTTP POST APIs can take several forms – they can send and receive JSON, XML or simple key-value pairs.  Popular tools for interacting with HTTP endpoints include cURL and Postman.  Authentication can be performed in the HTTP header or credentials can be included in the message payload itself.  While POST APIs can support any type of payload, JSON is often preferred because it is lightweight, flexible, and easily parsed.


This is popular style of coding is also supported by multiple Vantiv APIs including Vantiv’s Express API, Vantiv’s eCommerce API, and various management APIs such as the Merchant Management API used by Payment Facilitators.  This style of API is also used by Apple Pay iOS Apps to simplify Apple Pay integrations.


A cURL example showing the use of Vantiv’s eProtect HTTPS POST API is shown here.


curl -H "Content-Type: application/x-www-form-urlencoded" -d \
"paypageId=a2y4o6m8k0&reportGroup=67890&orderId=cust_order&id=12345&accountNumber=5454545454545454&cvv=111" \


The endpoint accepts PCI sensitive data like card credentials or a token and responds with a JSON payload containing a low-value token that can be used in lieu of payment credentials:




The eProtect service can either be called directly (as above) or for eCommerce applications a JavaScript library loaded into your web-page and optionally served from Vantiv via an iFrame can call the service on your behalf to avoid exposing your application to PCI sensitive data.




REST stands for Representational State Transfer.  It is not an API unto itself, rather it is an architectural style for expressing an HTTP-based API.  APIs that adhere to this coding style are said to be RESTful.  Developers who understand how to code to HTTP POST APIs (above) will automatically understand RESTful APIs because the mechanics of interacting with them are the same.  The main difference is in how the API is organized.  A RESTful API borrows from object-oriented design principles and typically provides multiple URL endpoints that correspond to objects being manipulated.


For example, if I have a URL endpoint /Charge representing a charge to a credit or debit card, I might create or update a charge against the endpoint using a POST method or retrieve one or more charges using the GET method.  Manipulating a specific instance of a charge would involve using an end-point like /Charge/<Charge-id> in a well-designed REST API.  I might have other entities such as Customers, Disputes or Tokens that I interact with in the same way using common verbs like create, update, delete and list.


Additional JSON or XML can be sent with each HTTP request to provide more instruction to the endpoint at the discretion of the API designer.  There are often “shades of grey” between HTTP POST APIs and REST APIs depending on how fully the API designer has embraced REST design principles.


Vantiv exposes multiple RESTful APIs as well to various payment platforms.   Examples are the REST API to MercuryPay, and the triPOS cloud API below, both designed around REST principles.




5. SDKs


Software Development Kits are client-side libraries that abstract and simplify coding to the above interfaces.   SDK’s are usually programming language aligned.  For example a Microsoft developer building a point of sale application will appreciate a C#/.NET SDK easily consumable with Visual Studio.  eCommerce developers might prefer a PHP or Java SDK that makes it easier to formulate payment transactions from within a web application.  The SDKs are responsible for generating and parsing the various messages formats described above.  It’s important to understand that it is ultimately XML or JSON formatted messages (or in some cases ISO messages) that are sent across the wire regardless of whether a developer codes to an SDK or a protocol specification.


SDKs are useful, but they present a double-edged sword. They simplify coding, but also introduce a new source of complexity in the form of a client-side software component that their application depends on.  Also, some SDKs may not expose all the advanced capabilities offered by a payment platform, meaning that for some functions developers will need to code to the message specification.


Opinions vary, but some developers will prefer to code directly to a protocol specification (like an XML spec or RESTful API) to take unknowns out of the equation and avoid dependencies that could impact their release cycles.


Vantiv offers several SDKs including C#, PHP, JAVA, Ruby and Python SDKs for our eCommerce platform. A sample credit card authorization using Vantiv’s eCommerce Java SDK is shown below


import com.litle.sdk.*; 
import com.litle.sdk.generate.*; 

public class AuthExample { 
   public static void main(String[] args) { 
       Authorization auth = new Authorization(); 
       Contact billToAddress = new Contact(); 
       billToAddress.setName("John Smith"); 
       billToAddress.setAddressLine1("1 Main St."); 
       CardType card = new CardType(); 

       AuthorizationResponse response = new LitleOnline().authorize(auth); 
       //Display Results 
       System.out.println("Response: " + response.getResponse()); 
       System.out.println("Message: " + response.getMessage()); 
       System.out.println("Litle Transaction ID: " + response.getLitleTxnId()); 



The Bottom Line


When it comes to payments there are a great many APIs, but most fall into one of the categories described above.  Once you master the mechanics of coding to on API in a category, other APIs in the same family become accessible and easy to use.


For a summary of the various APIs and resources available to eCommerce developers, sign-up to Vantiv O.N.E. and visit our eCommerce Guides and Resources area.


Developers building In-store, Integrated point-of-sale platforms can visit a similar collection of API documentation in our Point-of-Sale documentation area.

In payments, strategies for identifying customers are often built around channel-specific tools, technologies, and terminology.  For instance, the term "card-on-file" refers to an eCommerce business' storage of its customer's payment card information, to avoid requiring customers to re-key their credentials when placing subsequent orders.


In the brave new world of OmniCommerce however, customers often interact with merchants through multiple channels.  A retailer might recognize a repeat customer by their payment card, whereas an eCommerce provider may rely on an e-mail address. A laundromat might use a phone number to bring up a customer's prior orders and starch preferences.  An attribute useful for identification in one channel, may be unavailable in another.  It’s time for a “re-think” of card-on-file and multi-channel payments, and developers have an important role to play.


How Did We Get Here?


At one time "In-store" was the only channel available. Over time, merchants devised other channels like mail-order, telephone order.  With the advent of the web, some merchants opened an on-line channel to interact with their customers.  With the proliferation of mobile devices now bringing the shopping experience to the wireless “great outdoors”, the variety of interactions between customers and merchants is increasing dramatically. In-app payments, tap-to-pay, mobile-wallets and beacon technologies are all indicators of this rapid pace of change.


The progression of payment options has led to often disconnected, parallel ecosystems of technology and middleware that interact with customers in separate, inconsistent ways. We’re fast approaching a point where growing expectations of customers require that the walls between payment ecosystems be broken down. While it is great to be a consumer in this brave new world, building for multi-channel commerce is clearly a challenge.


From “Card-on-File” to “Customer-on-File”


Ideally, mobile systems, eCommerce systems, and point-of-sale systems should share a common view of the customer.  All three should be able to recognize an existing customer, allow for the creation a new customer, and all should be able to read or write interaction events associated with a central customer record.


This all sounds logical, but creating a composite customer identity can be hard to do in practice.


  • Customers on mobile devices may not have the patience to key-in a lot of data, and merchants may be reluctant to ask lest they inhibit sales
  • In-store customers may not want to volunteer personal information like e-mail addresses and phone numbers
  • Customers often use throw away yahoo or gmail accounts for on-line interactions to avoid receiving nuisance e-mail on their primary e-mail accounts


Data veracity is an ongoing challenge. People move, phone numbers change, cards expire, devices get swapped out, and data entry errors are common.


Flexible, Extensible Schemas


A customer database that can serve multi-channel commerce needs to tolerate some level of “fuziness”.  It may not be possible to populate all customer attributes with just one or a few transactions.  It may take several interactions before identity can be “federated” and transactions previously viewed as discrete can be recognized as belonging to the same customer.


The database schema that underlies this type of “customer-on-file” functionality needs to be flexible and easily extensible.  Merchants will almost certainly have a need to capture and store additional attributes in future including new types of tokens, credentials from new authentication services, or digital signatures from devices not invented yet.

In an age where the cost of storage is plummeting, and the cost of data acquisition (for digital transactions at least) is approaching free, a good practice is to store everything you can just in case you need it in future.  This includes contact info, payment credentials (secured, of course), and customer device info; anything related to a customer that identifies them and how they interact with various touchpoints is of value.

How Customer-on-File Helps the Business


Creating a single, cross-channel customer identity provides value at several stages in the merchant – customer relationship.


Acquisition phase


The acquisition phase is where you need to build your customer database. All payment channels should access a common database to:


  1. Identify if a customer is new or existing
  2. Append to a customer's record with as many attributes as possible.


If a customer is in a retail shop, they could be incented to sign up for an email list by providing their email address, or providing their phone number and first/last name.  If a customer phones into a customer service center, they could provide their mailing address or phone number. If a customer browses your website, store as much as you can including browser information, the IP addresses, and any unique device ID.  The more information attached to the customer record, the better.




The conversion phase is where a centralized customer view starts to show value. When a customer is ready to buy, the merchant can demonstrate how attentive they’ve been during the acquisition stage.

Buy-online-pick-up-in-store is a powerful tool for retail and food service merchants, but requires online/offline systems to be able to quickly access customer details for efficient identification and fulfillment. Similar scenarios - buy-online-ship-from-store, buy-in-store-ship-from-warehouse, split shipments - all help to ensure successful conversion, but all depend on quick and easy access to a customer-centric system.


Developers should think about how to design systems that are flexible enough to “set the table” for the next interaction, but avoid introducing friction into the conversion process.  On the eCommerce channel a fraud service provider like Threatmetrix can pass your web-application additional “telemetry” and device signature information helping you more easily identify a device if it enters your ecosystem in the future.


Retention / Up-sell


The retention and upsell phase is where a customer-centric data strategy can really pay off for merchants.  Effective identification of an existing customer will increase loyalty and boost the lifetime value of the customer relationship.  Is the customer returning a website purchase to a retail location?  The store should be able to grab the payment credentials from the eCommerce system, process the refund, and e-mail a confirmation.  Is the customer buying a pair of shorts at an outlet store?  Your system should ideally present the customer’s cross-channel buying history, and identify cross-sell / up-sell opportunities.


How Do We Get There?


For developers, enabling these smart, customer-centric buying experiences starts with a common customer database.  The key is to build deliberately, and assume that there will always be new channels that your customers will use to reach you.  There will be specific idiosyncrasies to adapt to with each new channel, but a customer-on-file database remains central of them all.


Building a solution on a technology platform focused on a single channel runs the risk of creating a patchwork of services that will be difficult and costly to maintain and integrate.


To help facilitate this “customer-on-file” design principle, selecting payment providers that are channel agnostic will pay dividends in future.  It will make it easier and more cost effective to support new channels and technologies, and it will increase the value of your solution to the merchants you serve.


Did you like this post? Click "like" at the top to tell us to make more content like this.

There are 105 books listed on my 2017 edition of Roddy’s Recommended Reading, and one of the most highly regarded – by myself and millions of businesspeople – is The 7 Habits of Highly Effective People by Stephen R. Covey. Since it was first published in 1989, over 25 million copies of Covey’s classic have been sold.


Maybe you’re thinking right now, “But I don’t have time to read that book and work on myself and my business strategy. Look at the mountain of stuff that’s on my plate – I’m too busy!” If that sounds familiar, I have good news for you. First, one of Covey’s habits is “Put First Things First,” which means you need to prioritize so you are engaged in the most impactful activities, not just the most pressing.


Second, I can save you hours of time by sharing my book notes with you. Following are 35 of the most insightful quotes from The 7 Habits that apply to ISV organizations:


Habit 1: Be Proactive

  1. Between stimulus and response, man has the freedom to choose.
  2. Reactive people are often affected by their physical environment. If the weather is good, they feel good. If it isn’t, it affects their attitude and their performance. Proactive people can carry their own weather with them.
  3. Reactive people are driven by feelings, by circumstances, by conditions, by their environment. Proactive people are driven by values – carefully thought about, selected and internalize values.
  4. Any time we think the problem is “out there,” that thought is the problem.
  5. Consequences: “When we pick up one end of the stick, we pick up the other.”
  6. Chasing after the poisonous snake that bites us will only drive the poison through our entire system. It is far better to take measures immediately to get the poison out.


Habit 2: Begin with the End in Mind

  1. If the ladder is not leaning against the right wall, every step we take just gets us to the wrong place faster.
  2. All things are created twice. There’s a mental or first creation, and a physical or second creation, to all things.
  3. Management is a bottom line focus: How can I best accomplish certain things? Leadership deals with the top line: What are the things I want to accomplish?
  4. There is a real difference, all the difference in the world, in the effectiveness of a mission statement created by everyone involved in the organization and one written by a few top executives behind a mahogany wall.
  5. No involvement, no commitment.


Habit 3: Put First Things First

  1. “Things which matter most must never be at the mercy of things which matter least.” Goethe
  2. “The successful person has the habit of doing the things failures don’t like to do.” – E.M. Gray
  3. The essence of the best thinking in the area of time management can be captured in a single phrase: Organize and execute around priorities.
  4. I’ve tried to give 10 minutes of “quality time” to an employee to solve a problem, only to discover such “efficiency” creates new problems and seldom resolves the deepest concern.
  5. With immature people, you specify fewer desired results and more guidelines, identify more resources, conduct more frequent accountability interviews, and apply more immediate consequences.
  6. You can’t have the fruits without the roots. Self-mastery and self-discipline are the foundation of good relationships with others.


Habit 4: Think Win/Win

  1. Win/Win is a frame of mind and heart that constantly seeks mutual benefit in all human interactions. Win/Win means that agreements or solutions are mutually beneficial, mutually satisfying. All parties feel good about the decision and feel committed to the action plan.
  2. Win/Win is a belief in the Third Alternative. It’s not your way or my way; it’s a better way, a higher way.
  3. Partnership agreements shift the paradigm of productive interaction from hovering supervision to self-supervision.
  4. I am always amazed at the results that happen, both to individuals and to organizations, when responsible, proactive, self-directing individuals are turned loose on a task.
  5. Consequences become the natural or logical result of performance rather than a reward or punishment arbitrarily handed out by the person in charge.
  6. If you put good people in bad systems, you get bad results. You have to water the flowers you want to grow.


Habit 5: Seek First to Understand, Then to Be Understood

  1. We have such a tendency to rush in, to fix things up with good advice. But we often fail to take the time to diagnose, to really, deeply understand the problem first.
  2. Very few of us ever practice empathetic listening: listening with intent to understand. Empathetic listening gets inside another person’s frame of reference.
  3. Next to physical survival, the greatest need of a human being is psychological survival – to be understood, to be affirmed, to be validated, to be appreciated.
  4. The professional has to have the integrity to say, “My product or service will not meet that need” if it will not.
  5. When you can present your own ideas in the context of a deep understanding of other people’s paradigms and concerns, you significantly increase the credibility of your ideas.


Habit 6: Synergize

  1. Synergy is almost as if a group collectively agrees to subordinate old scripts and to write a new one.
  2. I felt that experiencing synergy was more powerful than talking about it, that producing something new was more meaningful than simply reading something old.
  3. Valuing the differences is the essence of synergy – the mental, the emotional, the psychological differences between people.
  4. The person who is truly effective has the humility and reverence to recognize his own perceptual limitations and to appreciate the rich resources available through interaction with other human beings.
  5. When we’re left or own experiences, we constantly suffer from a shortage of data.
  6. As a result, new goals, shared goals, are created, and the whole enterprise moves upward, often in ways that no one could have anticipated. The excitement contained within that movement creates a new culture.


Habit 7: Sharpen the Saw – Principles of Balanced Self-Renewal

  1. Habit 7 is taking time to sharpen the saw. It surrounds the other habits on the Seven Habits paradigm because it is the habit that makes all the others possible. Renew the four dimensions of your nature – physical, spiritual, mental, and social/emotional.



If you’d like to talk more about The 7 Habits or how to improve your ISV business, please reach out to me. My job as a Reseller & ISV Business Advisor for Vantiv’s PaymentsEdge Advisory Services is to work with Vantiv partners to help them with hiring right, developing staff professional development programs, improving customer service, and more. Just drop me a line at and we can set up a time to talk.



For more On the Edge content, please visit the Vantiv Partner Advantage website.


Jim Roddy is a Reseller & ISV Business Advisor for Vantiv’s PaymentsEdge Advisory Services. He has been active in the POS channel since 1998, including 11 years as the President of Business Solutions Magazine, six years as a Retail Solutions Providers Association (RSPA) board member, and one term as RSPA Chairman of the Board. Jim is regularly requested to speak at industry conferences and he is author of the book Hire Like You Just Beat Cancer.

Change isn’t always easy, and upgrading or investing in a new point-of-sale (POS) system is a big endeavor for most merchants. But doing so can open up doors to increased business as well as offer critical payment security features.

When a point-of-sale solution is paired with value added services such as integrated pay processing, it enhances a merchant’s ability to streamline daily operations. Payment integrations tend to be the most complex and time consuming piece of the process, but they don’t have to create strain on your business.


For any new integrated payments partnership, choosing the right processing company to meet your needs begins with asking potential partners a few simple questions: Can they work with your business model today? Do they support your platform, existing technology, etc.? Can they support the growth of your business?


Taking the time to research, compare and evaluate payment processing partners can make all the difference in the long run. Look for an integrated payment processing partner that offers powerful, secure solutions that are simple to integrate and backed by customer service built around integrated payments.


What to look for in a payment partner

The right payment partner possesses a balanced mix of passion, talent and technology to help you win. You can’t expect your credit card processor to know the intricacies of running your business, but you can expect them to know what types of payment solutions are best for your business. Some processors are large enough to have expertise in many different areas, from servicing large retail shops to healthcare providers, service industries, eCommerce merchants and more. Look for a partner that pioneered the channel focused approach to integrated payments because your best interests should be top of mind and their solutions should be tailored to your specific business type.


Are they a match for your technology?

Merchants increasingly do not see their business as composed of separate online and in-store channels, but rather as a continuous consumer experience bridging the web, mobile devices, and brick-and-mortar location. Many processors offer semi-integrated solutions to simplify one of your payment needs but do not offer in-store, online or offsite payments in a single integrated platform.


One of the most important things to keep in mind is that the “easiest” integrated payment processing companies often are “no frills.” This can be good in some instances, but in the world of payments today, it’s safe to say that frills can be very important. For example, if you are seeking an omni-commerce platform, consider whether it includes security solutions such as PCI validated point-to-point encryption.  Find out if the chip-enabled PIN pad options support multiple interfaces such as WiFi, Bluetooth or Ethernet. Does the integrated solution offering support many form factors including distributed code, mobile apps or in the cloud? If you are considering recurring payment services, find out if this is an option.


In many instances, these semi-integrated features are not managed by the payment solution but through separate integrations or third party service providers that require individual integration work for each. A robust technology workbench is a major consideration for any integrated payments partnership to work, and you should know if these services are available to you and at what cost.


What does the future hold?

Additionally, it’s important to find out if your potential payment partner offers the solutions your business needs today as well as those you will need in the future. There are many integrated payments options available, and different solutions solve for different needs. Look for a credit card processing company in which integrated payments are innate to their business model.


Also, the partnership shouldn’t stop at the integration. On-demand resources should be available to you throughout the partnership, such as a dedicated integration consultant with technical payments expertise, a business developer to get you started with a solid business strategy, and a relationship manager for continued market growth.


Customer service may be the last thing on your mind when choosing to integrate payments to your business application, but it’s important to find a reputable company with an experienced, knowledgeable and accessible support team for you and your merchants.


Vantiv Integrated Payments offers its own processing platform that delivers unmatched, market-ready, semi-integrated solutions in the cloud, on a PC, or via a mobile device with features such as P2P encryption, account updater, tokenization, gift processing, and a true gateway for merchant processor of choice.