How One Integrated Payments Platform Enriches The Merchant POS

Datacap CEO Terry Zeigler says that enabling integrated payments for merchants through one platform isn’t just about giving developers access to SDKs and APIs – it’s about creating an ecosystem. Ziegler and team have been working to create an ecosystem where ISVs and merchants can access a broad set of technology and business tools to help them solve some of the key business challenges they face – that payments also touches.  MPD CEO Karen Webster caught up with Ziegler to get the inside story on the role that Datacap’s dynamic platform and services play in achieving that mission.

KW: Let’s talk about the role of Datacap and your platform to enable the channel and the ecosystem around integrated payments, taking advantage of your services and solutions. First, how prepared is Datacap to help ISVs that are part of your distribution channel navigate the challenges associated with the host of things that are all about security – the migration to EMV, tokenization, encryption and so forth?

TZ: We’ve been at this for a long time, so we’ve taken a transitional strategic approach to the evolving security concerns. We started with EMV development in Canada probably five or so years ago and have had pretty good success there. We developed a one-to-many interface for integrators to get to the processors that now have probably more than 75 ISVs that are engaged with four different processor platforms, supporting many thousands of merchants. So we have a lot of experience for that process in the U.S.

That experience helped us develop our out-of-scope solutions for the U.S. market. In that case, we control all of the payment peripherals just like we do in Canada. So we added a bunch of encryption technologies protecting card data from the reader throughout the processes that currently support over 40 devices including readers, PIN pads, contactless devices, all-in-one POS systems, and more.

We also added processor specific end-to-end encryption technology such as Voltage. We’ve really seen small uptake on that because they’re charging for that technology and a lot of small merchants just don’t want to pay transaction fees. In addition, we’ve added single-use tokens for transaction adjustments and merchant specific multi-use tokens for recurring payments. We’ve had that data available for quite a long time.

That strategy has been really transitional in providing platforms for our ISV partners. They not only get that one integration with many processor interfaces, but if they have either our Canadian EMV or out-of-scope interfaces, they then only have a couple of hours of development to drop EMV into place.

It’s pretty clean – if they commit to our platforms, we’re able to guide them through that security maze with either no or very little integration changes on their end.

KW: Is the scope of what you do just providing them with access to your SDK or API, or does it also come with a set of solutions, services and people that help make that transition easier for those ISVs?

TZ: We provide a whole set of not only technology but also business tools to those integration partners. So when you think about our technology, the big issue for us is that we’re providing one integration to reach many processors. So if they talk to us one time through the command interface, they can get to all of the processors. In addition to our technology tools for integration options, tokenization, encryption, EMV, and more, we also provide some clever ideas like hardware devices that actually mimic those interfaces that we have so that the ISV can separate the entire payment process from the POS system without changing the software. That’s getting a lot of interest at the ISV level and at the merchant level, since it reduces the merchant’s PCI footprint.

We also have Web accessible product management tools where an ISV can come on board and order products, manage the products, and more – 24/7. On the business side, we have put together a bunch of programs that make it easier for them to place their products. We can offer SaaS models to the ISVs directly, or we have a wide variety of relationships with various acquirers in the industry. If the ISVs sign onto those deals, they can get a recurring income for referring accounts to that process.

We do standardized data collection formats. When you think about Datacap Systems, where does that name come from? In the payments industry, we were originally a data capture business with cash register technology, collecting data and then pouring out through systems for what is now called Big Data. So we have formats in our transactional command interfaces that allow ISVs to send that data anywhere they want it to go.

KW: Do those who know what you do come to you with a particular request that is currently part of your platform, or do they come to you, look around, and say, “I thought I needed this, but I really need that.” What’s been the experience of those who take advantage of your developer ecosystem capabilities?

TZ: All of the above. With the long-term integrators, we get an enormous amount of custom requests. That might be very specialized gift card programs or loyalty programs, or something to do with how they interface to a particular system, requested by a merchant. There are situations where the merchant will ask to be completely out of scope, and doesn’t want the data anywhere near their POS system, but wants to be fully integrated. So we’ll take pieces of our product platform and start matching them up to what they’re trying to accomplish. We might use a hardware dongle off their POS system and that will drive the peripherals so all the data is collected on that device, and then sent along a separate IP backbone to a server that drives the transaction through whatever processor is involved.

We also have a lot of newer developers come in that are new to payments and the POS industry. We try to figure out exactly what we can do to help them, and they look at our slate of offerings to pick and choose. That becomes a very challenging situation because they sometimes don’t know what they don’t know, so you have to spend a lot of time with them to really indoctrinate them in this business.

KW: What’s interesting about having a platform in an ecosystem that glows up around that platform are the network effects that come from having a robust platform and ecosystem players that add richness to its core capabilities. Can you tell me how that dynamic has worked for Datacap over the years?

TZ: Well, you have a lot of special application people looking for a way to get into your marketplace. For example, with mobile application development, it’s an interesting situation because a lot of these guys really have little hope of getting penetration into the marketplace because of the amount of money it’s going to take to build an entire ecosystem on their own. So they ask how they can bust into our dealer or ISV networks, and do an interface through Datacap to get to these guys.

So I think we support something like 26 different gift card services – I didn’t think 26 gift card services existed. But we have them. We don’t do a lot of business with a lot of them, but every integrator you do business with has some unique relationship with someone he wants to do business with. So, you wind up developing all of these kind of attributes.

One situation that’s particularly interesting is with company called iDriveThru that operates out of New Jersey. They came up with the idea to use Easy Pass card readers as an RFI reading device to make payments automatically when you drive through a quick service restaurant. They don’t use Easy Pass to pay the bill, they just use it as a reader technology. What you’ve got is a token.

They came to us and asked us to help them make it work in the channel – so we used our token technology and our authorization technology and interfaced this whole thing together. We worked with a company called Comtrex that enabled a half dozen Wendy’s restaurants in Staten Island to accept this. What’s really clever about this technology is that when you drive through the window, the system automatically reads the ID tag, and then sends that data off to us.

The big data part of this gets wild. If the consumer is registered with iDriveThru, he can pay his bill automatically, paying through his iDriveThru account and getting access to loyalty programs, coupons and more. This is the only situation we’ve ever come across where they have perfect data on a consumer before they sign up for a loyalty program. They read that ID tag when a consumer comes through, and they take the data on the ID tag, not the consumer. When the consumer attached to that ID tag signs up for a relationship, they can measure what he does after he signed up versus before. That information is incredibly valuable to a merchant.

KW: To take that example one step further, let’s say you now have that capability on your platform as part of your ecosystem. Others who want to take advantage of what you have can get that capability, right?

TZ: It’s instantly available through hundreds of ISVs that we deal with, and they can do a very modest change for their system to effectively implement the capability. Most of the development for that particular application doesn’t have to do with supporting the payments side, that’s all straightforward. But the development is to accept the activation of a consumer’s card account.

KW: So it sounds like this is a part of the Datacap future – enabling these things and providing distribution for those use cases as they become available.

TZ: That is our business model.

KW: So what other examples can you give us of cool things that have found their way into your ecosystem? Anything else in mind?

TZ: We recently completed a project with an ISV named OmniTerm who implemented a point-to-point encryption and tokenization project for a chain of high-end, high-volume movie theaters. They integrated all of the restaurants, ticketing, retail and concession operations all under one interface and did that all with high security. Movie theaters are a tough situation – a lot of transactions, a short amount of time, and you need high security. A breach there could be massive in terms of card count, so that was really a powerful integration.

We also recently did a deal with a company to complete out-of-scope implementation with EMV-ready PIN pads for a major national sandwich shop that has about 3,000 locations. What was unique about that was that it was all done with remote updating capabilities. So they created a scenario where they were completely out of scope, so they can just drop in whatever upgrade comes along.

KW: Now P2PE – is that a pretty hot topic of conversation in your ecosystem?

TZ: Yes it is. It’s a challenging one, though, because with P2PE, the whole idea is to make sure that nobody can get ahold of any of that clear data while the transaction is dealt with at the POS or in flight. There are really two issues here. We’ve had P2PE for very long time as part of our normal out of scope applications – and in those situations, it’s been a applicability to all processors where we have an encrypted swipe read that goes into our software set, then we decrypt that at the POS, and re-encrypt it immediately to send out to whatever processor we’re dealing with. So the transaction is being encrypted, but at some point in the process, it’s decrypted inside the POS system. With merchants that have good control of their systems, it’s a very inexpensive way to get to a P2PE technology. But for merchants that aren’t as careful, they’re at risk because fraudsters can put memory scrapers on the system and take those transactions.

But that’s a universal application, and merchants are using it because it’s easy to use. In fact we have certified 40-something devices under that technology. But the real P2PE, the second step, is where somebody is encrypting at the swipe and it’s not being decrypted until it’s at a processor’s locations. So the way we do P2PE would be different for First Data, TSYS, Vantiv, etc. We’ve developed a number of those technologies but we’re seeing very little uptake on it now.

KW: Interesting. Why is that? Is it because they’re focused on EMV, or there isn’t a recognition that it’s that important?

TZ: The processors that give it away for free are doing P2PE, and the processors who charge for it are doing less of it. At least in our category, merchants don’t seem willing to pay whatever the processors are charging. We think what will happen is that technology will become buried in normal transaction fees, and it will be viewed by the merchants as free, so they’ll start embracing it.

To us, EMV is just one leg of a three-legged stool. Without tokenization and P2PE, it’s kind of foolish.

Terry Zeigler


CEO of Datacap Systems, Inc

Terry Zeigler is Founder, President and CEO of Datacap Systems, Inc., developer and manufacturer of integrated electronic payments systems. Previously, he held the role of Executive VP of Transaction Management Inc., a manufacturer of retail management systems.

Zeigler is an active member in the Retail Solutions Providers Association, serving on the Vendor Working Group and Strategic Planning Committee. He is also co-founder of Zeigler Family Foundation, which focuses on implementing age appropriate Financial Literacy programs in local school districts. Zeigler served for the past three years on the Bloomsburg University Foundation Board, and co-endowed the Zeigler Institute of Professional Development (ZIPD) and the Zeigler Business Case Competition. He actively supports the College of Business by providing student scholarships and hosting students through the Sophomore Experiential Learning program.

Zeigler graduated with a Bachelor of Science in Business Management from Bloomsburg University in May 1976.

To listen to the full podcast, click here.