Skip navigation
All Places > In the News > Blog

Developers prioritizing fraud management in a large stream of financial transactions is a difficult task, but instead of thinking about this from the needle perspective ("needle in a haystack"), allow us to flip the context and discuss the grass growing in the field prior to being cut, baled, and stacked. There is much to be learned from the environment that created a transaction that has already led to interesting fraud detection techniques.


In recently released data from Juniper Research they report that retailers will lose $71 billion in CNP (card not present) fraud over the next 5 years.  That amount should make even the most optimistic payment professional pause and reflect on how we as an industry can wrap our heads around this challenging ecosystem.


In this article we attempt a fraud perspective shift. Instead of thinking a transaction is either fraudulent or not fraudulent we consider the implications of a set of continua (did you know the plural of continuum is continua?) from highly likely to commit fraud to very unlikely to commit fraud, across a set of reputations.


While many of the examples below have been implemented in fraud prevention systems, in this article, the goal is a high level theoretical conversation.  However, if you are interested in concrete details, please feel free to read about the advanced fraud toolkit provided by the Vantiv eComm platform that implements some of the ideas below.



"It takes many good deeds to build a good reputation, and only one bad one to lose it." -- Benjamin Franklin


Essentially, there are four primary targets where reputation can be used towards better fraud management by developers:

  1. Reputation of the card/account
  2. Reputation of the “device” that is initiating the payment
  3. Reputation of the person presenting the card/account and using the device (this person is not necessarily the person that is authorized to use the card/account).
  4. Reputation of the merchant processing the transaction




Consider the plastic on which the card account is imprinted and what happens if the account (or track) data transitions is written to a piece of paper, or the account/track data is stolen in transit and imprinted on another card.  All of the physical cards that come to represent this specific account and all of the locations of data that originated from the card all have a reputation.  Good reputation or bad reputation is not the point; rather, each iteration of the card/account has a distinct reputation.


Imagine a card typically used to purchase day-to-day items like groceries and fuel in a card present swiped form and then one day the card is used to purchase shoes from an eCommerce store as card not present.  Was this fraud?  Or simply a change in the reputation of the card? Monetary values the card submits are also a portion of the card’s reputation. If the average use of a card is $100.00 per transaction, then an outlier suggests either fraud and/or a change in reputation.


  A card reputation split occurs when the original plastic is used for a card not present transaction or when track data is stolen or tokenized.  Each of these splits generates a reputation birth that can be linked to, or unlinked from, the original reputation.  For example, when one gives their credit card number to a utility for monthly billing, the card data (or hopefully token) stored at the utility company retains its own reputation while also being linked to the original card from which it was born.



The device that processes the card (or card data) also forms a reputation over time and device fingerprinting is an excellent source of reputation data.  Below we consider both card present and card not present environments.


Card Present Environment


Consider the device that processes transactions in a brick and mortar store.  It is typically either a pin pad connected directly to an IP connection or a pin pad connected to a computer (connected to an IP connection). In both cases the reputation of the device is stable both physically and from an IP viewpoint. The device is eventually going to provide a fingerprint of average ticket, physical location, Internet location, day and time of use, etc.  If there is a steady stream of $50 tickets flowing through the device and then a $1000 ticket flows through, we can question the reputation of the device. Another scenario is seeing transactions flowing through for a year only on business days but then seeing a transaction for $60.00 on December 25th.  Those amounts and days might not reflect poorly from a card reputation perspective, but they might trip a device reputation alert.


Card Not Present Environment


In CNP processing, the consumer and card data are typically flowing through the consumer’s personal device(or in some cases, a publicly accessible computer at a library or kiosk). From a CNP fraud perspective the reputation of the device is critical.  Imagine making a payment from your personal smart phone.  The smart phone, like the payment terminal above, is going to quickly create its own reputation.  Purchases are made on certain websites, at certain times of day, for specific amounts, at specific geo locations, and for specific products. Now consider the view from the eComm site’s owner.  They love and seek out device reputations like the one described above.  If however, the website owner detects a transaction inbound from a device located in France, for example, and that website owner knows they do not do business in France, then it is easy to stop fraud based on, in this case, the geo location of device.




The consumer, or person presenting the card (or card data) is typically identified as the fraudster, but as indicated above, there is more of a reputation continuum from highly unlikely to commit fraud to very likely to commit fraud.  Even if the consumer is deemed highly unlikely to commit fraud we still might want to decline a transaction based on a device that is highly likely or card data that is highly likely to commit fraud.


There are some excellent techniques for validating consumer reputation.  To keep things simple, assume the same card data reputation and same device reputation are being used.  How would the reputation of the consumer be judged?  Imagine the ability to detect how fast the consumer types the card data during an eComm checkout and in what manner the keys on the keyboard or smartphone are being tapped.  Or with a smartphone leveraging the accelerometer to detect how the device is being held while the data is being entered.  There have even been applications built around authenticating a consumer to smart phones by leveraging gait analysis with the accelerometer.  In addition to these scenarios there are the obvious differentiators such as products purchased, day/times of purchase, amounts, etc. All of these examples create the cardholder or consumer reputation. Social media is also becoming an important consideration in establishing the reputation of a consumer.




The final piece of the reputation puzzle is the merchant: either eCommerce, brick and mortar, or both. The processing environment and merchant metadata are critical to establishing the processing reputation. The vertical that the merchant processes in the number of years in business, average ticket, business hours, and volume are all excellent indicators that help to establish a merchant’s reputation.  Taking this a step further, and differentiating from device reputation, consider a virus infecting a merchant’s back office computer but payment processing occurring from a dedicated payment terminal.  The device fingerprint, having no virus, might be highly unlikely to commit fraud but from a holistic merchant perspective having a virus on any computer or device within the merchant environment degrades the merchant's reputation score.  As with other properties discussed above each merchant property will be assigned a weight so that the reputation score does not over emphasize smaller attributes.  For example a fraud scoring algorithm might weight the number of years in business and average ticket higher than business hours.


"Bad boys, bad boys Whatcha gonna do, whatcha gonna do, When they come for you"


There is no doubt that fraud occurs on a daily basis and if the data is correct, it is going to get worse before it gets better.  However, there is no reason to stick our heads in the sand.  There are tools out there for developers to manage fraud and leveraging the notion of reputation is an intriguing way to approach the issue.  We enjoy participating in the discourse from both theoretical and concrete approaches so please feel free to leave comments, or better yet, write an article on VantivONE to share with your peers engaging in the fraud conversation.  As always we look forward to hearing from you.


Wanna Build the Next Airbnb?

Posted by daniperea Jun 20, 2017

Got a killer idea and want to code the next big industry darling in tech? Looking at what Airbnb's developers did to make their site and app so successful is a great way to get started. What do you think makes Airbnb so successful? Let us know in the comments below.



1. Focus on the best experience for your user

Airbnb has a simple and delightful user experience. For travelers and backpackers on a budget, Airbnb is as easy to use as craigslist, but far better designed and without the inconsistency of a Craigslist listing. For travelers with more cash to spend, Airbnb is still easier to use than most hotel sites. This ease of use for travelers and hosts of all stripes has disrupted the staid lodging industry and raked in lots of revenue for Airbnb.


Focus on the best experience for your users, and let that experience inform your decisions on what features to add, while keeping in mind that too many features can easily distract.



2. Do regular updates to enrich your user’s experience

Regular updates might seem obvious to developers, because it’s a key factor in a great experience. Even after its scrappy startup beginnings, Airbnb has maintained the typical startup best practice of using agile development (Google does this as well), pushing out their product as fast and as often as they can. Instead of waiting for a feature set to be finished before updating, Airbnb updates their app as soon as new features are implemented, even if the feature is behind the scenes. 



3. Simplify the Payments Process

Payments can be one of the riskier parts of the sharing economy, but Airbnb made the process simple for travelers and hosts. Visitors enter their credit card number to book a stay and hosts are paid automatically after a successful stay. This removes the inconvenience of giving change for cash transactions and allows for a seamless experience that doesn’t even require a face to face transaction – perfect for travelers on the move. It’s a perfect outcome of meeting the business goals of the product while delivering user satisfaction in a simple, accessible and delightful to use interface.



4. Create add-ons for customers that improve their experience and increase your revenue.

Airbnb developers have done an excellent job of weaving in add-on options that add value for their hosts and customers without going overboard and creating cluttered complex checkout process that decrease conversions. Add-ons for hosts include free professional photographs of their listing and a click-to-post-on-craigslist option. Guests can click to add “experiences” like a nearby wine tour. When you’re developing a checkout process, think beyond the final transaction and consider what will improve your customer’s experience without detouring from your conversion funnel.



5. Develop a seamless omnichannel experience across web and mobile.

Airbnb’s marketplace can be accessed via their site, their iOs and Android apps, and on the Apple Watch. Registration and account creation is free and users can save their credentials once and then automatically sign in to both the app and site. No matter what channel customers are using to access Airbnb, the UX is the same, from filtering lodging options to messaging hosts to checking out.


Want more tips on creating a business like Airbnb? Merchant aggregation, like the Airbnb model, is powering a whole new category of commerce. A payments facilitator (PayFac) is a business that facilitates payments between merchants selling goods or services and the end user. This enables the end-user to easily pay online and the merchant (or property owner in the case of Airbnb) to get paid quickly. The sharing economy is a new generation of business, and so far it's booming. Want to get in on the action? Check out Becoming a Payment Facilitator (PayFac)

Apple Pay and mobile wallets continue to be big news in payments. While some analysts point to slower than expected growth, there is a deeper, more positive story behind the headlines. With recent technical innovations, Apple Pay is poised for growth, particularly for web and mobile payments. For eCommerce merchants, Apple Pay support is likely a must-have payment method going forward. Readers who are interested in a more technical view of Apple Pay should check out our article Apple Pay on Vantiv.


An Apple Pay refresher

For those who don’t follow payments closely, Apple Pay is a feature of the latest iPhones and the Apple Watch. With Apple Pay, payment card details can be stored in a wallet app on iOS, enabling consumers to pay with their phone (or in some cases, their tablet) in different ways:


  • In-Store – using the NFC capabilities for “tap” checkout at the point of sale
  • In-App – enabling one-touch payment from within a payment capable iOS apps
  • Online – the most recent innovation in Apple Pay, enabling eCommerce websites to recognize Apple Pay capable devices, and offer one-touch payments at checkout


While consumers often think of Apple Pay from the perspective of in-store payments (currently the most visible use case), it turns out that web payments are where the action is.




The deeper story behind Apple Pay adoption statistics

In March of 2017, PYMNTS and Infoscout released their latest market research around Apple Pay adoption. As of March 2017, only 21.9% of surveyed consumers self-identified as having tried Apple Pay, according to Infoscout, leading many to suggest that adoption had stalled. While this is an important data point, there are other important factors to consider as well.


  • During Apple’s Q4 2016 earnings call, Apple pointed to Apple Pay transaction growth of almost 500% vs the year before, with Q4 2016 Apple Pay revenue exceeding revenue for all 2015 – impressive growth that is hard to argue with.
  • US shoppers spent $22.7 billion USD in eCommerce purchases from mobile devices in Q4 of 2016 according to comScore, a 45% increase over the same period last year showing enormous growth in mobile payments (a different statistic than mobile wallets, but an important indicator nonetheless).
  • In the same Infoscout research cited above, fully 95% of respondents viewed Apple Pay as offering the same or better convenience than paying with a payment card.


What do we take away from all this research? The story is complex, but consider that most credit card purchases take place in-store at retail locations. As a result, surveys tend to reflect the predominant in-store, NFC/tap use case for mobile wallets. Looking at in-store statistics only can miss a critical point. According to separate research by McKinsey, the fastest growth in digital wallets (including mobile wallets like Apple Pay) is taking place in eCommerce/mCommerce payments. Payments made via digital wallets are expected to exceed $1 trillion by 2020, with mobile wallets seeing a 50% CAGR to $400 billion. In other words, by far the fastest growing market for mobile wallets is in eCommerce, with point of sale transactions expected to make up only a tiny portion of digital wallet payments by 2020.


Apple Pay on the Web is a game changer

Apple Pay on the Web is a new technology that helps merchants operating eCommerce sites easily add Apple Pay as a payment option. Most of us who have experienced the tedious process of keying in details like payment credentials, and shipping or billing addresses on a tiny phone keyboard. This is precisely the reason that according to Barilliance, users abandon shopping carts on mobile devices at a rate of 85.6%.


Apple Pay on the Web solves the checkout problem for consumers and merchants alike. It allows consumers on a suitably equipped iOS device to securely make a payment and relay personal information to a merchant with a single touch. This means that smaller online retailers can offer the same level of payment convenience as best in class providers like Amazon, offering one-touch payment for first-time purchases.


What does this mean for merchants?

While Apple Pay on the Web is still young, it is a critical enabler for eCommerce merchants. Fully 50% of eCommerce purchases already involve stored credentials, according to McKinsey, and as one-touch checkout becomes the norm, it will be a convenience that consumers demand.


For eCommerce merchants, the challenge is how to implement Apple Pay on the Web quickly and cost-efficiently in a way that minimizes disruption to existing systems and processes. Also, while Apple Pay is the dominant mobile wallet at present, merchants need to take an approach that makes it easier to adopt additional digital wallets in future from their eCommerce or mobile websites.


Vantiv offers a comprehensive set of developer resources for the Apple Pay API on Vantiv O.N.E. at Create your free account to access the Vantiv O.N.E. Apple Community.

Other business books have sold more copies worldwide, but the title I hear mentioned in our channel as having the biggest impact is Ownership Thinking by Brad Hams. Multiple software developers and resellers have mentioned to me that the book has improved accountability and profitability at their organizations.


I first learned about Ownership Thinking four-and-a-half years ago through keynote speaker Tom Bouwer at the 2013 RSPA INSPIRE Conference in Curacao. After a workshop Bouwer coordinated on the final day of the event, I was inspired to write an article for Business Solutions Magazine titled “Yes, KPIs Can Be Fun,” and then I read the book.


Following are 26 insightful quotes from Ownership Thinking that apply to ISV organizations:


  1. Ownership Thinking is about moving employees away from only the “me” way of thinking and toward the concerns of the business and its financial performance.
  2. What we want to achieve: The creation of organizations whose employees think and act like owners toward creating wealth (which, in turn, creates opportunity). We want to create great cultures that are fun and rewarding to work in.
  3. The 4 components of Ownership Thinking: the Right Incentives, the Right Education, the Right Measures, and the Right People.
  4. Create a culture where (1) Everyone is challenged and must take responsibility for their company’s destiny and their role within it; (2) workers know what the heck is going on and how they contribute; (3) everyone is a “part of”; and (4) people have fun.
  5. Entitlement destroys motivation. It lowers productivity. In the long run it crushes self-esteem.
  6. For an organization to achieve excellence, it must engage all of its organization members.
  7. The question is not if we give but what and how.
  8. Skills can usually be taught, but my experience tells me that attitudes and behaviors are pretty tough to change.
  9. An incentive plan must be self-funding.
  10. The absolute worst scenario I have encountered is a salesperson who is commissioned on revenue and has the ability to negotiate or manipulate pricing. The company is just asking for reduced margins.
  11. Everyone can contribute to the financial performance of the company, and everyone can sabotage it.
  12. In absence of information, people make stuff up.
  13. When employees assume their company is making wheelbarrows of money, they become wasteful.
  14. I don’t believe that full disclosure is necessary. I believe that employees simply need to receive the information necessary for them to do the best job they can.
  15. If you have too many measures, it’s quite likely that none of them will get measured very well. Or, people will become overwhelmed and then paralyzed.
  16. Industry standards = “this is what mediocrity looks like”
  17. The objective of a Rapid Improvement Plan (RIP) is to attack and improve one Key Performance Indicator (KPI) at a time with a high-involvement, detailed plan.
  18. The 6 steps to creating RIPs: (1) Identify a KPI that needs improvement. (2) Identify a quantifiable goal and a time frame for the RIP (typically 90 days). (3) Quantify the financial benefit of reaching the goal. (4) Determine the actions and people required to achieve the goal. (5) Name the RIP and create a theme (have some fun). (6) Identify a celebration for reaching the goal.
  19. 90 days is long enough for organization members to significantly affect a KPI, but not so long that they lose interest.
  20. A celebration should be identified at the beginning of the RIP that will be carried out if the goal is met.
  21. The biggest problem with creating RIPs is that people overthink them. They turn them into something very ominous and complicated.
  22. Companies are pretty good at starting things, but not very good at following through with them.
  23. People become advocates of what they understand, appreciate, and take ownership of.
  24. As a business leader, you have many things on your mind every day, so the resistance will typically win out and the initiative will go away.
  25. Adults address reality and deal with it. Adults don’t argue with reality. Adults remain calm in the face of adversity or failure – and they simply try again.
  26. Regardless of the economic conditions (or any other circumstances for that matter), some companies will win, and some companies will lose. The winning companies (and people) will be those that accept reality for what it is and make the decisions and take the actions that will get them through successfully.


If you’d like to talk more about Ownership Thinking and 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.

Every month, Vantiv and team up to deliver the latest news in developer spaces. Here’s the overview of the Developer Tracker published in May 2017.


Creating a seamless environment for online commerce requires the harmony of many different factors. Consumers must be able to navigate a company’s website easily, add items to their shopping carts effortlessly, and complete payment without friction. With so much margin for error and so many abandoned shopping carts, winning the eCommerce race can be tough.


May’s Developer TrackerTM features an interview with Deck Commerce, a company that’s focused on making the online checkout race a bit more winnable. Deck Commerce partners with global fitness and athletics brands like New Balance, Rawlings, Warrior and others, developing omnichannel software and solutions to keep these companies ahead of their competition.


In the interview with Deck Commerce’s Founder, Chris Deck, Deck provides his insight into many of the opportunities and challenges facing omnichannel merchants today. In particular, he says that the key to winning omnichannel is turning the problems that plague many brands into the very tools that help them grow.


Before Deck and his colleagues became a software team, they were consultants, helping athletics brands and retailers design omnichannel commerce strategies. During their time as consultants, they realized that many of these retailers and merchants struggled with three common issues: collecting usable data from their legacy back-end systems, managing and leveraging inventory and, finally, managing orders and delivery. The company saw an opportunity to use their knowledge and experience to provide a better solution, so Deck and his team decided to develop their own software. Deck Commerce morphed from a team of consultants to a development group in 2015.


To develop personalized solutions increasingly demanded by eCommerce shoppers – for instance customized recommendations and offers— brands need data about their customers and their online habits. Deck says that Deck Commerce software helps brands collect that data by giving them tools to analyze sales in an existing POS solution, delivering information on what items customers are most likely to buy.


“So, the first thing we built were the tools to help merchandisers expand their data, have it ready for easy digital consumption in forms they could understand, and then push that data out across the whole enterprise,” he says.


The solution also works to change how brands sort and store their inventory. “Ten years ago, businesses were often creating individual warehouses or allocating inventory that was specifically separated for online selling only,” Deck explains.


Rather than keeping inventory in an online-specific warehouse awaiting shipment, Deck Commerce works to build inventory management solutions that enable brands and retailers to store a large variety of items in local warehouses around the country, managing each item via an online dashboard. This helps these companies speed up delivery times to compete with Amazon and other popular eCommerce warehouses known for speedy delivery.


“You really want to try to leverage your inventory across all your distribution centers, and now, with buy-online-pickup-in-store, even your retail stores,” he says. “So you need an enterprise view of your inventory, spread out across multiple warehouses, so you can know what marketing to push out and where the inventory is to support that.”


Deck also emphasizes the importance of managing multiple streams of orders for brands. With the development of online sales and an increase in big-box stores, many brands are selling their products through more channels than ever before. And, to solve for potential logistics headaches for brands, Deck said the company’s software enables merchants to manage shipping, customer service, payments acceptance and other tasks via one portal, so that brands can easily monitor and manage orders as they are filled.


“When you’re successful and engaging with customers, you’re getting lots of orders,” he says. “But when lots of orders are coming in, it’s critical to know how to most effectively process that order, whether from an allocation perspective, who is going to ship it and where, servicing customers, settling payments, all of that.”


The end result is software and expertise that helps even established brands like New Balance improve eCommerce sales and grow their business. The company, known for its running shoes and other fitness gear, recently announced it would be expanding its eCommerce business to meet increased demand for orders through the New Balance online store.


Read the full interview in May’s edition of’s Developer Tracker, powered by Vantiv. It also covers other developer-focused news and updates including:


  • Are mobile apps becoming less safe?

Some developers may be motivated by an increasing consumer desire for mobile payments, but many are wary of the security of mobile devices and applications in general. Mandeep Khera, chief marketing officer for security technology company Arxan, recently commented on the state of mobile security, saying the risk of app security is growing. To guard against threats to mobile devices, Khera called on financial institutions, retailers and regulators to put more stringent security protocols into place and to stop the “rush-to-release” mentality that can bring products to market before they are fully secured. He also advised consumers to actively ask about companies’ security protocols.


  • Biometric-secured mobile payments projected for big growth this year

With so many consumers concerned about the security of mobile payments, it’s no surprise that some analysts are expecting biometric security to create gargantuan growth. Mobile payments using biometrics to authenticate users are forecasted to reach close to $2 billion in 2017, up from $600 million last year, according to new data from Juniper Research. The adoption of biometric payments is being helped by the growth of Apple Pay and other mobile wallets, and the increased availability of fingerprint sensors on smartphones and tablets. The report found that around 60 percent of smartphones are expected to launch with fingerprint sensors this year.


  • Vantiv pays for Paymetric

While some partnered to improve software, Vantiv went the acquisition route. The company inked a deal to acquire Paymetric, a portfolio company of Francisco Partners. In a press release, Vantiv said Paymetric automates B2B payments workflows within enterprise systems, including SAP, Oracle, Hybris and Salesforce. Paymetric also tokenizes payments data, enabling secure storage of customer information and history.


Download the report.

Top five Payment API Must-Haves for Developers


If you’re familiar with Payment Facilitation, chances are that you’re already pretty savvy about payments. Payment Facilitation can be critical in unlocking new business models and enabling growth, but for software developers there are many issues that complicate application design. Developers need to think about not only processing payments, but deal with a range of complex issues associated with managing a community of merchants.

As reminder, a Payment Facilitator (also known as Payment Aggregator, or PayFac®) is an entity that acts as an aggregator, providing payment related services and facilitating transactions for a number of sub-merchants. PayFacs basically sponsor merchants, enabling these sub-merchants to be boarded with the support of a payment processor and underwriting bank. This arrangement provides several efficiencies. It simplifies the process of engaging and signing sub-merchant partners, and puts the PayFac more firmly in control of their business.  Instead of your merchants signing up with a third party payment gateway (eroding your margins and control) they in effect sign up with you, and you facilitate payments for your own community of sub-merchants. In essence, you become a mini acquirer.

Operating a PayFac at scale depends on efficient management of functions beyond simple processing like boarding, management, funding, and handling chargebacks. As with most things in software, doing these well demands not only the right infrastructure, but modern, flexible programming interfaces.

1. Boarding & Sub-merchant Vetting


While not as onerous as establishing a merchant account, whenever you sign a sub-merchant, you and your sponsor bank are taking on some level of risk. Few PayFacs can afford the administrative overhead of processing new sub-merchant requests manually, so having automation behind merchant setup & vetting is a first essential requirement.  PayFac management platforms should offer a boarding API to support streamlined processing and fast approval of submerchants for underwriting. The boarding API needs to differentiate between legal entities and individual sub-merchants attached to those entities (because your sub-merchant may operate multiple stores for example).

Ideally, the API should allow you to pass key information about a legal entity (type of business, tax identification numbers, details on principals, years in business etc.) and receive information back.  Is the business legit? Is the address valid? Are outstanding liens? Are there criminal records or a history of bankruptcies? Depending on your business, you’d like to have the option of performing background checks with different levels or thoroughness. In cases where sufficient information cannot be verified electronically, you’d like your payment processor to undertake a manual review on your behalf and notify you electronically of the results so that you receive either an approval or a clear explanation of why a particular application cannot be approved.

Once legal entities are approved, you should be able to easily manage and maintain details about individual sub-merchants including banking information, approved transaction limits and the like. To operate as a PayFac you will have registered with the card brands in their respective programs, so the API for boarding sub-merchants should automatically provide notifications as you add or retire sub-merchants.

2. Transaction Tagging


This will be obvious to most developers, but once you board a merchant, you’ll need to be able to tag transactions like Authorizations, Captures and Reversals to the appropriate merchant in your code. This requires that your transaction-oriented APIs be sub-merchant aware. Your business might involve a partner branded web presence or a mobile app that end customers download from Apple’s AppStore or Google Play. You’re clearly not going to build separate apps or infrastructure for each sub-merchant, rather you’ll parameterize your code to deal with each.


Ideally, transaction-level tagging should be flexible enough to allow for additional metadata like campaign identifiers, affiliates, or other information useful for downstream reporting. As your business grows, you might provide financial incentives to your merchants by paying them differentially based on their performance around specific marketing campaigns or programs.  It’s essential that your transaction level APIs and reporting systems support this kind of flexibility.

3. Chargeback Management


Chargebacks are a headache for any merchant, so imagine the challenge when handling hundreds or perhaps even thousands of sub-merchants. This is another case where the scale of the challenge demands a comprehensive API.  While some chargebacks are legitimate (stolen cards, disputes, fraud and the like), other chargebacks are the result of customer error and can be reversed by simply following the chargeback process prescribed by the card networks.

Similar to onboarding, to be effective the chargeback management API needs to automate the process fully, avoiding costly and time-consuming manual steps on the part of the PayFac. The API needs to not only allow tracking of chargeback activity by sub-merchant, but it needs to accommodate the variance of rules and policies associated each card brand. For example in the case of a dispute involving MasterCard, the decision of whether to go to arbitration is made by a merchant whereas with VISA, the decision resides with the card issuer. A chargeback management API should automate tracking and interactions through all phases including retrieval requests, chargeback initiation and pre-arbitration or arbitration. It should also provide programmatic interfaces for common tasks like assigning chargebacks to the correct sub-merchant, allowing sub-merchants to assume liability when appropriate, adding notes, and providing requested documentation via the direct upload of binary files to support a case.

With a proper chargeback management API, PayFac application designers can build chargeback management features directly into the custom interfaces that they present to their sub-merchants. They can better manage risk (by identifying frequent sources of chargebacks), avoid unnecessary charges, and maximize revenue and pofitability both for sub-merchants and themselves.

4. Merchant Funding


The whole point of a sub-merchant signing up to your service is to get paid, so doing a good job in this area is essential.  Small PayFacs may be able to manage paying sub-merchants themselves, but at any scale, automation becomes essential here as well. PayFacs should have access to APIs that allow them to provide precise funding instructions, easily moving money to sub-merchant accounts, various holding accounts and to their own accounts.

By utilizing an API rather than web-based tools, developers have the flexibility and control needed to enable creative new business models. For example they might levy particular fees for different types of services, or offer their sub-merchants incentives or compensation based on tiered revenue attainment structures. They might want to offer flexibility to sub-merchants like the ability to perform deposits across multiple bank accounts to make their offering more attractive to partners. PayFacs can also precisely control the schedule for funding, and can consciously withhold payments for contract or risk related reasons with the right APIs.

While a PayFac may not need all this flexibility out of the gate, as revenue grows and business models mature, flexible funding APIs help ensure that systems don’t get in the way of delivering new capabilities that can provide a source of competitive advantage.

5. OmniChannel Transaction Support


The way that consumers make payments is changing fast, with mobile payments, digital wallets and other forms of stored credentials becoming increasingly important. A PayFac might start out accepting credit cards on a mobile-optimized web-site, but this channel might be quickly augmented with a downloadable mobile app, or even retail locations requiring card present solutions. Similarly, the types of payments accepted will almost certainly expand. 
The payment APIs for handling sub-merchant transactions need to be flexible and support a variety of card-present and card-not-present payment methods. The last thing a PayFac developer needs are separate sets of APIs for each method of payment or mobile wallet. Finally, a customer who makes a purchase using one channel should be recognizable in future when they purchase via a separate channel.


To learn about Vantiv’s PayFac specific APIs and access our technical documentation, visit our developer community built for PayFacs at

vantivone-linkedin-header_nedcanningsheader_2 (1).jpg

Do your customers appreciate all that development effort?


cup_of_coffee.JPGI consider myself to be a tech-savvy consumer. When I want to grab a coffee from my favorite chain on the way to work, I pull up the merchant provided app as I start the car. I see my recent orders, and in most cases just re-submit my last purchase. I can get up-to-the-minute information about the stores around me, in case my normal stop is running low on my favorite brand. I place the order, and authenticate payment with a thumbprint as I shift into reverse gear, and set out on the short drive to the coffee shop. When I get there, I check my phone to verify that the order is ready, walk in to the store, greet the clerk, and leave with my cup of brew in a few seconds. The process I just described takes a small army of systems marching in lockstep to pull off. It no doubt took an enormous amount of design, development work, QA & testing. Consider some of the issues that developers had to grapple with:


The mobile application needed to communicate with the store’s inventory management system, with a CRM system (to access my profile, preferences and buying history), with Apple Pay or Android Pay to access my payment credentials, and with a payment processor to authorize & process payment. The point-of-sale (POS) system in the coffee shop needed to be able to accept my on-line/eCommerce order and pass it to the barista's queue as it would a regular in-store purchase. The POS needed access to my stored (tokenized) payment credentials, in case I wanted to add some banana bread at the last minute while picking up the coffee.


As if this all wasn’t enough, the systems behind the transaction needed my customer details to print out a personalized label that could be used to identify me when I came in to claim my coffee. Trials are already underway with smarter payment systems that pull up a customer’s photo as they walk into the store so that a savvy barista can greet their customer by name and perhaps even wish them a Happy Birthday.


Whether too much personalization starts to feel creepy is up for debate, but months of development work and cross-functional teaming no doubt went into this delicate ballet.  Do I appreciate the effort? I haven’t really thought much about it to be honest. I just want my coffee to be ready when I walk in the door. If this shop can't do that, odds are I’ll just find a competitor who can.


The lessons for developers & merchants:

Customers may not be familiar with (or care) about things like Tokenization, BLE or Beacons, but they certainly care about convenience, security and good service. Consumers want the buying experience to be simple and seamless. Providing this type of consistent, convenient buying experience requires a high degree of integration between traditionally discrete, channel-specific technologies that merchants have been using for years. The omnicommerce “first movers”, backed by talented IT shops and developers, have set the bar high indeed. Customers might not care about omnichannel, but they certainly know convenience when they see it and are voting with their (increasingly digital) wallets.


Developers have a crucial role to play in engineering customer experiences that are as satisfying as the coffee itself!


Liked this post? Click "like" at the top to tell us you'd like to see more posts like this.



To learn more about integrating In-App and web-based buying experiences with your POS, check out our Mobile & Digital Wallet Developer Resources on Vantiv O.N.E.

A Fascinating undercurrent of business funding is currently shifting to a new model. This model is sometimes called a token sale or as some call a pun on the IPO process, the ICO or Initial Coin Offering. This term ICO has become a bad word in some circles, with others preferring ITO or token sale to remove the term from the possible correlation with the regulators. Don't worry if you haven't heard of this, but you probably will in the coming years, and hopefully below will shed a bit of light.


How and Why

This finance process is accomplished by raising money by issuing a cryptocurrency token via an initial cryptocurrency offering crowd sale. Generally, the guidelines of the sale are put in place by the capital raising group, although there have been a recent flurry of suggestions and new off-shoots to help guide both the token creator and the purchaser.


These companies and their tokens are blazing ahead with incredible traction leaving regulators wondering what to do. There are already hundreds if not thousands of tokens issued and while there are some big hits, there are also many failures. Fred Ehrsam of Coinbase wrote "Some token models don't make sense. For every 1 huge hit there will be 3 minor success and 100 failures, so we shouldn't be surprised when some fail. However, the fundamentals of the token model are valuable and powerful. They allow communities to govern themselves, their economics, and rally a community in powerful ways that will allow open systems to flourish in a way that was previously impossible." A common correlative example is that this now allows the ability to fund a large distributed project, something like Linux, which before there was no direct mechanism to do such a thing.


Another good point to keep in mind if you are skeptical about this is that the history of venture capital faced very similar issues. At one time, stocks were considered a new asset class just as cryptocurrencies are today and the very idea of venture capital required re-engineering of the financial regulatory infrastructure.


The tokens are coming (what to do about it)

On the Distributed panel, a lot of focus was placed on what to do if you were interested in offering, funding or purchasing token offering. The first thing is to make sure you understand the risks, this is high-risk, bleeding edge technology. Now that we have that out of the way, read about the different types of tokens that are being offered (realize this is a fast moving space, and even that article is a bit dated).


Once there is a basic understanding the things to look for include:

  • Team Quality, this is the most important piece, they should have a business team
  • A distinguished product
  • A legible and clear whitepaper that directly calls out the case for the token
  • Should take an international perspective
  • Should have a good advisory board with leading experts in the space


Things that to watch out for:

  • If this is a new network token, why?
  • Does it seem speculative and only for profit?
  • Does it have a ceiling in place for the raise
  • If it is complex, it is a red flag


If you are looking to create an offering there were some good points brought up as well:

  • Ensure that you have a good product that fits the model
  • Enable information access about the offering
  • Build a large community for the product and the offering


Clearly, there are many taking a deep hard look at what is going on here, venture capitalists among those. The blockchain space is clearly bleeding-edge. It seems as if the technology is something similar to the early days of the internet and it is difficult to develop a filter for what is fiction at this point. The use cases are numerous and at times obvious, yet it is unclear how and when we will see adoption. That said, it is exciting that we can fund blockchain projects in a way we never could before and hopefully open up new possibilities that we have never seen before.


Follow me on twitter

Connect with me on Linkedin


Read Part 1 Here: Blockchain Part 1: Cross-Border Payments and Remittances

Read Part 2 Here: Blockchain Explained: Debt Markets and P2P Lending (Part 2)

In February I got to attend the distributed markets hackathon and after spending 24 hours hacking our way through The Coffee Chain we won some bitcoin and got third place! If you want to learn more about our experience read Tony's post here. Due to our efforts, we continued on to the conference and were graced to learn about blockchain use cases from many panelists across different tracks. I want to discuss three of the tracks I attended and I'm going to break this up into three parts. The first being Cross-Border Payments and Remittances, the second, Debt Markets and P2P Lending and the third Token Sales and ICO Funding models. If you need a primer in blockchains, see this article from Brian Forde.


Cross-Border Payments and Remittances


One of these tracks was cross-border payments and remittances. One of the first things we realize in this space and existing systems is that costs are high. See this guardian article that describes the huge profits extracted on oversea money transfers. At times that can rise into the double digits. When a worker in one country wants to send money to his family in the Bahamas, a double-digit fee can take a significant bite out his pay. The other issue is that the transfer can be inefficient. It can take days or weeks to settle and requires the use of many intermediaries to arrive at settlement.


This brings us to bitcoin and the blockchain and it can potentially offer nearly a trillion dollars in savings on these types of transactions. It allows, for a much smaller set of fees and near instant settlement. The issue arises really on the edges of this system where the end users have to convert and deal with their individual fiat currencies. In some realms, it is relatively easy to convert and transfer bitcoin to a fiat currency, in others it is prohibited by central banks. This is where one of the company and individuals directly focused, Gabriel Abed of They took the Barbados dollar and made it digital, the Barbados Digital Dollar. They are doing a lot of the hard legwork with central banks, foreign banks and trying to build true trust amongst the public. There are a lot of questions that remain, but many positives that can be achieved.


So, what are the barriers to adoption at present to moving cross-border and remittance transactions into this new digital blockchain realm? As mentioned building trust is probably the first component. There is a cultural stigma to the digitization of cash that is real and present and this must be addressed to gain end-user mass adoption. For now, depending on the friction involved in the transaction, many users will opt for the digitized version if it is easy to use.


This brings us to another high priority issue which is ease of use, dealing with private keys, PHPthe highest priority is ease of use.  Crypto-Markets can be complex and understanding cryptographic keys, PGP and more, can all be a bit much for an end user to handle. This is something many gladly pay to have abstracted away in the existing system and don't even know it. This is where something like netki can aid with the abstraction,  working to break down the ease of use case.


Another barrier is the lack of standards in the blockchain space. This is where enterprises like can play a role. Having been involved in payments for many years, recently doing functional testing of EMV cards, standards increase trust, especially amongst B2B intermediaries. UL actively sees a role for standards and will aid in pushing this forward.


Traditionally counterparty and systemic risk have been a large issue in this marketplace. When viewed from a crypto-market lens, the glasses can get quite rosy. That is not to say that counterparty and systemic risk do not exist, they do, perhaps, in this case, it could be the underlying trust in the network itself, as opposed to a counterparty risk.


In the future, remittance and global money transfer may become as cheap and fast as sending an SMS message to your friend in another part of the world. There may come a point where there is a proliferation of cross-border payments as they become near-free and the ease of use cases are adopted.


Next - Blockchain Part 2: Debt Markets and P2P Lending


blockchain blog button.png

P2P Lending in the technological sense is a relatively new phenomenon. In the early part of the millennium, a few P2P marketplaces began to spring up in the U.S. offering (at times) high-risk, high-reward loans. One example of this started around 2005, They had to overcome a number of hurdles and even faced a class action lawsuit in 2008. There were others like TrustBuddy that went out of business completely due to misconduct. As of June 2012, Lending Club is the world's largest P2P lending marketplace.


These P2P marketplaces have some interesting characteristics, these include:

  • Sometimes for profit
  • No necessary prior relationship between marketplace lenders and borrowers
  • Transactions take place online
  • Loans can be unsecured or secured and are not normally protected by government insurance
  • Potential for faster finance times
  • Ability to circumnavigate some regulations like CRA
  • Loans are securities that can be transferred to others for debt collection or profit


P2P Lending is more active abroad.

In non-U.S. based circles the activity in P2P lending has been considerably more active. China is estimated to have the largest and most active market with more than 4,000 providers. This has led some of the largest in the space to take a harder look at blockchain technologies.


Large P2P Marketplaces are evaluating BlockChain

During the discussion at Distributed, the panelists were asked if blockchain would even be a good fit in this space. It was generally accepted that from a contractual perspective it was. It appears some large P2P marketplaces are taking notice. China-based Dianrong has begun to integrate an application they are calling D-Chain for greater transparency and security on both the borrowing and lending side. We can see from their D-Chain image below how P2P based activities integrate to the blockchain.



P2P Lending is a new market and is high-risk. Working with bleeding edge technology in a high-risk space may not make sense.  Speed to finance appears to be a great issue to tackle in blockchain P2P finance at first glance, but this really may be a better issue for blockchain to solve on a more traditional instrument, like residential loans that generally take 3-9 months to complete the transaction.


The convergence of P2P and blockchain at first glance seem like a natural fit, under the covers, there may still remain a number of challenges that will need to be addressed.


Next - Blockchain Part 3: Token Sales and ICO Funding Models

Get Part 1 Here: Blockchain Part 1: Cross-Border Payments and Remittances


Vantiv Visits Voatz and Toast

Posted by jmather May 11, 2017

At the beginning of April, our team took to the road to visit our colleagues and partners in Massachusetts. We flew into Boston and high-tailed to Lowell office.



Here we got to learn the many intricacies of card not present, and how a well-oiled machine works under the covers.

Developer Integrations on the left, E-commerce on the right, notice our toes dip into the blue on Vantiv blue on both sides:




We also got to spend some time in Boston down on Milk Street. Here we got to visit with Nimit Sawhney, the Co-Founder of Voatz (of Techstars Boston fame, and previous multi-time hackathon winner) and Bjorn Ahbel one of our amazing Vantiv partners from Toast. The Voatz platform is pretty amazing, built on a distributed ledger, it is steadily changing the way the world votes, from political elections to shareholder voting and more. Below you can see Nimit demonstrating the Voatz platform to us.




Bjron and Toast are doing some amazing work, building a true restaurant ecosystem that is unique to the space, leveraging our Payment Facilitator line of business.


We, of course, got out to see Boston a little bit as well, unfortunately, the weather wasn't all the cooperative, we made a jaunt to Faneuil Hall but we were nearly stopped by the wind and rain:




We also spent the evening in Boston's north end where we go to visit the cash-only establishment of Mike's Pastry (come on Mike, you know you could make more money by letting Vantiv serve you!). Below you can see me looking very sad that I don't have a pastry of my own:




It is truly special to get to spend time with such innovative and thought provoking team members and individuals. At Vantiv we love to help drive and support innovation both in business and the world of payments. If you ever want to help us innovate with your business, please get in touch.


Follow me on twitter

Connect with me on Linkedin

I’m moderating a Communication Workshop for a Vantiv ISV partner next month, so I’ve been thinking quite a bit about the most effective place to start a discussion on communication best practices. I mean, if the workshop leader communicates poorly, that’s not exactly confidence-inspiring for everyone else the room.


I’ve learned that the foundation for effective communication – with co-workers, customers, and even family – begins with the Communication Rule: If you have an issue with someone or someone’s behavior and you seek change or resolution, talk directly to that person.


Following the Communication Rule provides an opportunity to demonstrate the Golden Rule – treat others the way you want to be treated. If someone has a problem with you, would you want them to talk with you directly about it? Or would you want them to talk with others, or say nothing at all?


The adage “Bad News Never Ages Well” is accurate. The longer you let a bad situation go, the worse it gets. Following the Communication Rule enables problems and misunderstandings to be resolved quickly, which in turn creates a more positive and more productive work environment.


In many cases, the person with the undesirable behavior will not know their behavior caused you grief. As a result, the individual will sincerely want to fix the issue. In addition, speaking directly to the person builds respect between the two parties.


The following four scenarios related to the Communication Rule show a clear difference in outcomes. Will is a field technician and Sarah is an account executive for Underwood POS. When Sarah calls one of her customers, Taki’s Restaurant, the owner says that he was dissatisfied with Will’s performance yesterday afternoon. The owner said Will was less friendly than normal and rushed through the job of servicing one of their POS systems. He didn’t refill and reattach the receipt printer before he left, and a new staff member had to figure out how to make it work on her own. Sarah apologizes to the owner and thanks him for letting her know about his dissatisfaction. Right after she hangs up the phone, Will enters the office and sits down at his desk across the room from Sarah.


  • Scenario #1: Sarah doesn’t say anything to Will because she is afraid of potential confrontations. She crosses her fingers and hopes this won’t be a recurring behavior. When Will leaves the office 45 minutes later for a maintenance call with Serafini’s Restaurant, Sarah’s biggest customer, she gets a pit in her stomach.


  • Scenario #2: Sarah doesn’t say anything to Will because she is angry at him. Instead, she walks to the break room where Kristin, a fellow account executive, is pouring herself a cup of coffee. Sarah tells Kristin about the conversation she just had with Taki’s and how angry she is at Will. Kristin only adds to Sarah’s anger when she says, “Yeah, we’re at the mercy of the techs. Nothing we can do but watch the customers that we bring in leave. I wish those guys cared as much as we do.”


  • Scenario #3: Sarah doesn’t say anything to Will and instead walks over to the desk of Stu, a field technician who joined the company a few months ago. Sarah vents to Stu about the conversation she just had with Taki’s and how frustrated she is with Will. Stu is uncomfortable hearing negative feedback about his mentor, and he isn’t sure how to respond. After Sarah finishes venting and leaves the room, Will stops by Stu’s desk to ask how he’s doing. Stu relays to Will a version of Sarah’s story about Taki’s. Will replies, “Really? She didn’t say anything to me.” Walking back to his desk, Will wonders to himself what else Sarah and the other sales reps are saying behind his back.


  • Scenario #4: Sarah walks over to Will’s desk and asks him if he has a minute. He says yes, so they walk to a conference room where Sarah closes the door. She tells Will about the conversation she just had with Taki’s. Will apologizes profusely. “I’m sorry – I rushed in-and-out of there because right when I pulled into their parking lot I got a call from the Assistant Principal that my son got into more trouble at school and they wanted to meet with me right away. I knew Taki’s wanted their POS system serviced before their dinner rush yesterday, so I told the Assistant Principal I would be there within a half hour. I should have just asked Taki’s if I could come back later to do the job the right way. Would you be OK if I went to Taki’s now before my 10 o’clock service call at Serafini’s? I want to apologize to them directly and then run through my servicing checklist like I should have yesterday to make sure everything is running correctly.” Sarah agrees to that action plan. Will finishes the conversation by saying, “Thank you for letting me know I screwed up. I hope I didn’t harm your relationship with them. I know how hard you worked to bring them in. I promise you I’m going to do better going forward – this won’t happen again.”


As those scenarios illustrate, the Communication Rule is fair treatment of your co-workers. They could be doing something wrong inadvertently or doing something below standard that affects their career, your customers, and your company. So direct communication is the best option, but why don’t we follow it every time? Common reasons include:


  • These types of conversations make you uncomfortable.
  • The person is your friend, and you don’t want to harm the relationship.
  • You feel you shouldn’t judge others. “Who am I to correct them? I make mistakes, too.”
  • You worry if you criticize them they will quit.
  • You feel you don’t have time to get into a conversation.
  • You assume they already know they need to perform better.
  • You rationalize that what they did isn’t a real problem. “Am I too sensitive? Was this really below standard?”
  • Resignation. “Even if I say something, nothing will change.”


Whatever your excuse for breaking the Communication Rule, you have to overcome that mental obstacle. Not addressing below-standard behavior directly and immediately with the person leads to co-workers talking behind each other’s backs, which in turn creates a toxic work environment. If below-standard performance is not addressed, you are essentially condoning the bad performance and allowing it to continue. This bad behavior/performance could spread to others, effectively lowering the standard for everyone.


Take a small step right now with the Communication Rule. I’m sure you have a positive opinion about one of your co-workers, so share that with them today. Deliver them a specific compliment about an action they took recently. Develop a habit of talking directly with others about their performance, and you’ll establish the foundation for an effective organization.



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.

Every month, Vantiv and team up to deliver the latest news in developer spaces. Here’s the overview of the Developer Tracker published in April 2017.


Tech-driven commerce might conjure up images of eCommerce giants and large national retailers that offer advanced capabilities like curbside pickup, real-time inventory and mobile point of sale (POS) systems. But what about grocery stores? Considering that consumers visit grocery stores an average of 1.6 times per week, they are a prime place to enhance shopping experiences and leverage some of the benefits that advanced commerce technology can provide.

Amazon and Kroger are making headlines with advancements aimed at speeding up the grocery purchase process. But for smaller grocery stores and specialty food and beverage chains, keeping pace with the resources and technology offered by large chains can be difficult.


There are solutions that can help these smaller businesses stay on the cutting edge and compete with the big players in the grocery game. April’s Developer TrackerTM features an interview with Burt Aycock, director of design for ECR Software, a company that develops solutions for smaller grocery and specialty food and beverage merchants. In the interview, Aycock explains how these smaller businesses can use technology to give consumers a taste of the convenience offered by larger chains.


According to a recent report, nearly 50 percent of grocery store shoppers both in the U.S. and around the world make decisions about where to shop based on convenience. And some of the biggest players are using self-service technology to make trips to the store faster, more convenient and safer than ever. Aycock says that smaller chains and stores can invest in technology like self-checkout terminals to satisfy consumers looking for more convenience. He goes on to say that online sales systems can give smaller chains a big boost when it comes to competing with larger national names.


Aycock’s team at ECR recently released an online shopping module, designed to allow smaller stores the ability to accept online orders that can be picked up in-store by consumers, similar to services being offered by large national chains. “That’s really just another POS lane when it comes down to it,” Aycock says of online sales capabilities, noting that much of the same software and code that powers in-store sales can be used for online channels. “It’s really just about bringing that same sales technology from in-store to the cloud and putting a user-friendly interface on it so that consumers can make their purchases online in a simple fashion.”


While consumers may want more convenience and control over their visits to grocery and specialty food stores, they don’t want speed to come at the price of security. “People have a lot of fear and uncertainty about security, so we always look to develop solutions that are obviously stringent and tough but also easy for retailers and consumers to understand and follow through on,” he explains.


But that doesn’t mean security should remove simplicity from transactions, either. It’s a hard balance to strike, Aycock says, but consumers expect digital convenience and safety to go hand in hand.


In order to offer safe transactions without wasting customers’ time, Aycock says that merchants should look for solutions that combine speed with security. That includes biometric and tokenization features that can be embedded directly into a store’s payments system, such as the OneTouch solution, a biometric fingerprint scanner that tokenizes data while cashiers ring up items.


Read the full interview in April’s edition of’s Developer Tracker, powered by Vantiv. It also covers other developer-focused news and updates including:


  • A cashless Coachella, with help from Square

Organizers of this year’s Coachella Valley Music and Arts Festival announced that all vendors will accept Apple Pay, Android Pay and Samsung Pay via Square. Coachella also has a digital partnership with American Express this year where the festival’s app will allow Amex members to link their cards for a chance to win rewards during the festival. Other music festivals have used RFID (radio frequency identification) for payments, where users link their payment cards to wristbands. Lollapalooza, for example, has been using RFID technology since 2014.


  • TransferWise turns to chatbots

TransferWise customers will now be able to perform banking and financial transactions via their Facebook accounts. The London-based company announced that it developed a chatbot to help users communicate and complete transactions with businesses. The chatbot is designed to send money to and from the U.S., Britain, Canada, Australia and Europe from Facebook Messenger. It can also be used to set up exchange rate alerts. Domestic money transfers are already possible on Facebook Messenger, but TransferWise claims that its service will be the first to enable money transfers globally.


  • Deutsche Bank offers HCE payments to German customers

Customers of Deutsche Bank in Germany can now make host card emulation–based mobile payments, according to NFC World. Bank executives said in a statement that customers can download the Deutsche Bank mobile app onto their Android smartphones and then use their Mastercard credit or debit cards to make cashless payments worldwide at Mastercard acceptance points. Deutsche Bank has approximately 300,000 customers who have both a Mastercard product and an Android smartphone.


Download the report.

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.