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

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