A Primer on Card Processing Fees

For developers who have worked mostly with gateways, coding to a payment processor can be a different experience. The interfaces can feel a little more complicated, but it turns out that understanding arcane topics like interchange fees, assessments and discount rates vs. interchange plus is worth the effort - especially as payment volume scales. If you’re wondering why this is, read on - you’ve come to the right post!

Interchange

In payments, interchange refers to the fees that are paid by the merchant’s bank (or the acquirer in industry lingo) to the cardholder’s issuing bank. These fees are set by the card brands and compensate the issuer for going to the trouble of qualifying consumers, issuing cards, handling transactions and taking on the risk involved in offering a line of credit.

The money moves from the acquiring bank (the bank handling the front-end of the transaction) to the issuing bank (the bank issuing the card), but fees are ultimately passed on to the merchant.

The card brands usually update interchange rates twice per year, and at the time of this writing, the links to latest fee structures for VISA and MasterCard are provided below:

A casual look at these schedules will confirm what you probably suspect – the policies are complex, and every transaction is potentially different subject. Rates charged by the card brands depend on a variety of factors:

Assessments

In addition to the interchange fees described above, card networks charge an assessment fee for each transaction. The point of an assessment fee is to provide a source of funding for the card networks to maintain their infrastructure. A quick Google of “VISA Assessment Fee” shows an assessment rate is 0.13% for credit and debit cards. Assessment fees can change with time, vary by jurisdiction and be different for different card brands. Assessments are paid by the payment processor/acquiring bank, and like interchange fees, these costs are passed onto the merchant.

Payment Processing Fees

As you’ve probably realized, interchange fees and assessments don’t benefit the payment processor. They only benefit card companies and card issuing banks. Typically, payment processors contract with the merchant for additional processing fees. Usually these fees are per-transaction and may vary by transaction type. The processor may also include additional fees for value-added services you elect to use, such as account updating or enhanced security offerings that can benefit merchants in other ways, such as reducing chargebacks, or minimizing declined authorizations.

Discount Rates vs Interchange Plus

Most of us are conditioned to appreciate a good discount, but in payments the story is more complicated. Processors determine discount rates by examining a number of factors, including MCC, average ticket price, and risk factors among others. From this info, processors negotiate with you a discount rate that accounts for the mix of interchange, assessments, and other fees, along with their profit margin. For example, imagine an internet gateway charging a discount rate of 2.9% + $0.30 per transaction On a hypothetical $100 card purchase, this would cost the merchant $3.20 as shown below:

Now imagine the same transaction subject to an interchange plus fee structure. In interchange plus, the processor passes through interchange, assessments, and other network fees without change. The processor then adds a per transaction fee, as well as any fees for value added services you elect to use. In this second scenario, the actual costs of interchange fees will vary with every transaction, but a typical transaction might look like the following:

This is not to say that one pricing model is better than the other, or that an interchange plus fee structure will always be less expensive, but the approaches are different. Payment providers who offer a discount rate, are providing merchants with simplicity and predictability, but arguably at the price of transparency. Interchange fees and assessments still apply behind the scenes, and the payment provider is taking a risk because they could potentially lose money on some transactions. When offering a discount rate, the payment provider earns their margin on the difference between the discount rate offered to the merchant and the actual underlying fees they pay to facilitate the payment including interchange, assessments and processing fees.

While discount rates are simple, they are not transparent to the merchant. The merchant understands their total cost, but they don’t have visibility to how much of the cost is due to interchange, assessments or earnings retained by their gateway providers or processors.

To gain transparency, larger merchants often prefer interchange plus pricing schemes. While they can be more complex to understand, they do allow merchants to analyze their payment transactions and understand the cost components of each transaction in detail. With visibility to all sources of cost, merchants can take steps to avoid excessive fees including understanding what types of transactions are the most or least costly and taking steps (including coding applications differently) to reduce costs where possible.

Processing fees matter

To state the obvious, processing fees matter. For a small business transacting $5M annually, a 50-basis point reduction in average fees can yield $25K to the bottom line – enough to hire a part time employee or lease a couple of vehicles. For a national retailer, analyzing and understanding fees is even more consequential.

Because the amounts are so substantial, larger merchants will often negotiate for lower discount rates, or prefer interchange plus pricing where they have visibility to their fees. With visibility to fees, merchants can take steps to address sources of cost including coding transactions differently.

How does this impact the developer?

Basically, how you code payment transactions matters because decisions you make can affect Interchange rates for a particular transaction. Following card brand rules is essential to not only minimizing fees, but reducing instances of fraud and chargebacks as well. As examples:

For card not present transactions always perform an AVS (Address Verification System) check. Simply performing an AVS check can result in better interchange and also acts to deter fraud.

Providing detailed metadata in payment transactions (like industry types, terminal types, electronic indicator codes and commercial card IDs) can also help merchants obtain more favorable interchange rates. If this information is not provided, card brands will err on the side of caution, defaulting to higher rates.

For developers, to minimize merchant costs, it is important that their payment SDK or API provide the ability to accept and pass on as much of this supplementary metadata as possible. Worldpay’s triPOS and Express APIs for card present transactions are good examples, as both allow for extensive metadata collection including things like freight, duty, taxes, ship-from and destination zip codes, and a variety of other items that affect interchange fees.

An opportunity for increased sales and conversions

Mobile wallets have been in the news recently, with much of the focus on the relatively slow adoption of mobile wallets in North America. When looking at statistics though, the answer we get often depends on the question we ask. Rather focus on a few mobile wallets, we might instead ask, “What percentage of online purchases are made using stored credentials?”

According to Mckinsey, the answer to this question is a much bigger number - already around 50 percent. Every time we purchase an app or movie in the Play Store, buy something on Amazon Prime, or shop at our favorite web store, the chances are good that we’re using digitally-stored credentials. Mobile wallets represent just a slice of a broader set of digital payment options already accessible from mobile devices.

For online shoppers, convenience is king

Few customers have the patience to key in payment card and address details on a small screen device like a phone. Unlike the point of sale, where mobile wallets provide only minimal added convenience, for online purchases the difference in convenience is huge. For online merchants, providing access to stored credentials is essential. Consumers purchasing online would much prefer to authenticate themselves with a thumbprint or password than key in a hundred or more characters. This consumer behavior explains why according to the same Mckinsey study, total U.S. digital wallet transactions (broader than just mobile wallets) is forecast to grow to $1.2 trillion by 2020, representing approximately 18-20 percent of retail spending. For wallets, online commerce is where the action is.

About Google Pay

Google Pay is a new service offered by Google, implemented using the new Google Pay API. Google is one of the world’s most recognized brands and Google users across the globe have hundreds of millions of credit and debit cards saved to various Google accounts. These users make purchases on Google properties like the Google Play, YouTube, Chrome and more.

With the new Google Pay API, merchants can reach these same customers by letting them use their cards on file with Google to make quick, easy purchases from mobile apps and websites when they’re shopping from mobile devices or using the Chrome browser.

For mobile users, this offers a new level of convenience. Even if I’ve never visited a merchant before, as a consumer, I can select “Google Pay” as an alternative to keying in payment card details. Google will look up any payment cards I have on file, present them to me, and allow me to choose the credential to use as shown above.

Google Pay extends Android Pay functionality, however unlike Android Pay which can be used at the point of sale (tapping your phone in a store or restaurant) Google Pay is designed for online purchases only. Consumers that have already activated their Android Pay wallet can continue to use their Android Pay credentials, providing a seamless transition for users and merchants already supporting Android Pay. The main difference when users Google Pay is that they can access any payment card on file with Google, even if they’ve never activated a mobile wallet.

Lowering the barriers to online commerce

For merchants, Google Pay is an important innovation. Juniper Research estimates approximately 24 million Android Pay users in 2017, and Google already has hundreds of millions of cards on file across its various platforms. By removing the need for consumers to pre-load a payment card into a wallet, merchants can benefit from faster checkouts, more conversions, and increased sales.

While Google Pay is significant for all merchants, it may be especially important for small merchants competing with larger online retailers. Google Pay helps level the playing field, providing all merchants with the opportunity to offer the same streamlined purchase experience that users expect from tier-one retailers. Consumers can enjoy a seamless checkout experience even if they’re visiting a merchant’s website for the first time making it easier to attract new customers.

Google Pay and Vantiv

Vantiv is presently one of just a few payment providers able to offer Google Pay functionality for merchants. Vantiv’s Google Pay integration utilizes an existing server-to-server connection between Vantiv and Google that facilitates the secure and efficient transfer of payment credentials and provides developers and merchants with a straightforward integration experience.

Whether merchants are already using Android Pay with Vantiv, or are just getting started with digital wallets, Vantiv can help merchants get up and running quickly.

Developer resources for Google Pay will be available at Vantiv’s developer portal, Vantiv O.N.E., in the Mobile & Digital Wallets section once Google officially unveils the Google Pay API. Extensive documentation and code examples on Vantiv O.N.E explain how developers can add Google Pay functionality to their Android App or their website.

If you have questions or comments about Google Pay or any other digital wallet, we’d love to get your thoughts and comments.

A Primer on Card Processing Fees for Developers

For developers who have worked mostly with eCommerce gateways, coding to a payment processor can be a different experience. The interfaces can feel a little more complicated because they expose additional fields and capabilities including support for various types of card present transactions. It turns out that understanding topics like interchange fees, assessments, and discount rates are worth a developer’s time. By keeping processing fees in mind when building payment applications, developers can code in a fashion that can potentially help merchants avoid fees or reduce chargebacks.

Types of credit card fees

Interchange and assessment rates and fees

Certain fees are usually non-negotiable, including interchange and assessments. Interchange and assessment fees are determined by the card associations and are charged to payment processors, who then collect the fees from their merchant clients. Interchange goes to the authorization network (the banks that issue credit cards) to pay for the verification and routing of funds, and assessments go to the card brands (Visa, MasterCard, etc.) for the privilege of using their cards. The interchange rates are based on how a transaction is conducted—whether it’s swiped, dipped, keyed, conducted , and well as the merchant’s business type, size, and many other variables.

Acquirer fees

In addition to collecting interchange and assessment fees for the card brands and networks, credit card processing companies also known as “acquirers” also assess fees to cover the costs of the services they provide to merchants. Unlike interchange and assessment fees, this type of fee can vary by processor and can sometimes be negotiated.

Fees in this category pay for services such as equipment rental, payment gateway access, PCI compliance programs, minimum processing amount, reporting, and many other value-added services that make payment processing convenient and reliable for merchants.

Sometimes credit card processor fees are listed separately from interchange and assessment fees, but some processors bundle them into one rate. It’s important to talk to your credit card processor about their particular fees including what they are for, how they are collected, and whether you need the particular service associated with the fee.

Popular pricing structures

Pricing structures can vary widely and are complex by nature. It’s important to note that one pricing model isn’t inherently better than another. It all depends on your business and the variables noted above regarding business type, processing volume, acceptance methods and so on. Let’s take a look at some of the popular pricing strategies used by processors.

Flat rate pricing

Flat rate pricing consists of one monthly fee that covers all the processing services a business needs and is commonly offered by payment facilitators (PayFacs) that don’t require a merchant account.

This type of pricing is non-negotiable and doesn’t fluctuate with transaction volume. Every transaction receives the same rate. This appeals to businesses that value simplicity and don’t have large transaction volume or high average ticket values.

Bundled or tiered pricing

In a bundled or tiered pricing model, transactions are categorized into different pricing tiers—qualified, mid-qualified, and non-qualified—based on their risk factors like whether the card is present, whether it was swiped or key entered, and whether PIN or signature is captured. Qualified transactions are the safest and therefore have the lowest rate whereas non-qualified transactions are the riskiest and have the highest rate.

This type of pricing generally requires a merchant account and can save money in the long run for larger, more complex businesses due to their processing volume and card acceptance variables.

How does this impact the developer?

How you code payment transactions matters because decisions you make can affect Interchange fees. Following card brand rules is essential to not only minimizing fees but instances of fraud and chargebacks as well. As examples:

For card not present transactions using AVS to deter fraud, the accuracy of the address match (returned in response to an Authorization) will impact interchange rates – the better the match, the lower the rate.

Providing detailed metadata in payment transactions (like industry types, terminal types, electronic indicator codes and commercial card IDs) can also help merchants obtain more favorable interchange rates. If this information is not included in an Authorization request, card brands may err on the side of caution, defaulting to higher rates.

For developers, to minimize merchant costs, it is important that their payment SDK or API provides the ability to accept and pass on as much of this supplementary metadata as possible. Vantiv’s triPOS and Express APIs for card present transactions are good examples of APIs that do this. Both allow for extensive metadata collection including things like freight, duty, taxes, ship-from and destination zip codes, and a variety of other items that can affect interchange fees.

To say that application architectures are evolving quickly is an understatement. In the age of cloud, mobile apps and back-end services can simply never go down. Developers are increasingly turning to scalable, resilient micro-service architectures based on Docker containers as a preferred way of building applications.

Stats from the last DockerCon 2017 event in Austin shine a light on the pace of change. Today there are more than 14M Docker hosts and more than 900K Docker apps. In just the last three years there has been a 77,000% increase in Docker job listings and a 390,000% increase in Docker image pulls. Payments are often a feature of cloud-delivered application services including mobile apps, online gaming, and new types of interactive voice-activated services. As a result, developers of payment-enabled applications are getting swept up in this enormous shift.

The Case for containerized applications

Among the reasons that developers favor containers is that they promote modular design, code reuse, unit testing and lend predictability to application deployments. If my application needs a database, key-value store, and a web-tier, rather than deploy hardware or a VM, I can simply pull Docker images of MariaDB, Redis or NGINX, add my application logic and publish my own derived Docker containers to my favorite registry. I can rapidly wire together these containers into an application comprised of multiple service tiers using a lightweight YAML (yet-another markup language) specification and publish a complex, multi-tier application to a containerized orchestration environment in seconds. The explosion of interest Docker and containers has ushered in a revolution in how applications are built and deployed. Today there are dozens of container management platforms supporting these types of applications including Kubernetes, Docker Swarm, Amazon ECS, Azure Container Service, Google Container Engine, Mesos Marathon and more.

Payment applications pose unique challenges

In this brave new world, containerized services are ephemeral, can scale up and down dynamically, and are placed on Docker hosts based on run-time conditioners by sophisticated schedulers. Application administrators often lack visibility to what VMs their services are executing on not to mention the cloud or physical host. These environments pose unique challenges for both Docker users and assessors when it comes to PCI DSS compliance. A discussion of securing Dockerized applications is too big a topic to address here, but a challenge that developers invariably face is how to securely make secrets like payment API credentials available to application logic inside a Docker container.

Enter Secret Management

This challenge of managing secrets is not unique to payments. Secret Management solutions have existed for years for Software Configuration Management (SCM) tools like Puppet, Chef, and Ansible. What makes Secret Management challenging for containerized applications are issues of scale, the breadth of public cloud providers and the sheer rapidity with applications evolve.

To explain the issue, imagine we have a cloud-resident component in a Docker container that needs to call one of Vantiv’s end points on behalf of a merchant. The challenge is how to get the credentials to the application securely. The credentials can’t reside in the Docker image itself, or they would be visible to anyone, and all instances of the application would share the same credentials. Similarly, they can’t reside in a YAML specification that is accessible to anyone on GitHub. We might have the idea of encrypting the credential and passing it to the container, but then the question becomes how do we distribute and protect the key needed to decrypt the payload holding the credential? If we attempt to pass the key across an encrypted channel, we still have the problem of passing additional keys needed to secure the channel. It’s a challenging problem. Dan Somerfield of ThoughtWorks describes this “bootstrapping” problem generically in his talk titled Turtles All the Way Down. What’s needed is a secure way to pass payment credentials in a fashion that is cloud provider agnostic.

Securing Payment Credentials in Containerized Applications

Because Docker containers are all in the rage in cloud deployments right now, I wanted to look at this problem in the context of Docker. As with so many areas of technology, there is not a single solution for secret management; there are literally dozens (partial list here). In the world of container orchestration frameworks, however, industry consolidation is taking place and leaders are starting to emerge. Kubernetes (open-sourced by Google) is enjoying considerable enthusiasm followed by Docker Swarm, followed by the big cloud providers with their container management and secret management solutions. (Google’s GKE uses Kubernetes, formerly known as Google Borg). If you learn the approach used by Kubernetes, the good news is that you can address a large number of container orchestration frameworks and cloud services that use Kubernetes as their foundation (list here).

For developers or operations folks who want to get their feet wet with Kubernetes secret management, I’ve developed an end-to-end example showing how secret-management in Kubernetes can be used to pass payment credentials used by Vantiv’s eCommerce platform securely. You can find this example in our Vantiv Labs area in Vantiv O.N.E.

If you’re interested in learning more about securely managing payment credentials in Kubernetes, check out the explanation and example here. I’d love to get feedback and learn how developers are managing secrets in your applications.

1. Counting the costs

Whether you’re a merchant or ISV, cost of payment acceptance is always a consideration. Pricing models can vary with some gateways offering percentage-based fees and others offering interchange plus rate structures. One approach is not necessarily better than the other, but pennies per transaction can add up fast. Check into fee structures carefully, and make sure you thoroughly understand the costs.

2. Authorization success rates

While cost is important, the percentage of successfully authorized transactions can be even more important. If a significant percentage of purchases result in improper declines, you’re basically turning away business. This is an area where not all gateways are created equal.

3. Type of bank account and deposit schedules

For serious merchants, a proper business merchant bank account is recommended. If you’re small, and new to eCommerce however, some gateways allow funds to be deposited into existing bank accounts. Understanding the nature of bank accounts required, their costs, and how quickly funds are available is important for any business.

4. Support for card present applications

When people think about payment gateways, they often think in terms of eCommerce or Mobile payments. In fact, some gateways handle card present, point of sale solutions as well. For retailers, in-store sales are often much greater than on-line sales. To avoid fragmenting volume across providers, and to provide a seamless experience in-store, in-app and over the web, a gateway that supports both in-store and eCommerce transactions may be preferred.

5. Ease of integration

Whether you’re an ISV, are integrating to a gateway yourself, or are relying on a third-party for a pre-built solution, ease of integration is important. If integrations are difficult or require significant ongoing maintenance, costs are passed on to merchant in the form of higher fees. Selecting a well-supported gateway with a good developer experience will pay dividends down the road.

6. Throughput & performance

Merchants often don’t think about performance, but this is another area where mileage can vary. The further a gateway is from a major payment processor, the more network “hops”, and the longer transactions may take. In the age of mobile apps and “tap to pay” at busy quick-serve establishments, seconds count. Consumers and merchants want efficiency, and performance can affect the bottom line.

7. Security, encryption and PCI scope

With an abundance of cyber threats, strong security is now table stakes. Merchants simply demand it because the cost of a breach has become unacceptable. For developers and ISVs however, delivering strong security can come at a cost. Developers should look for payment gateways with strong security capabilities both online and in-store. These include encryption, tokenization, EMV support, and software approaches that help them reduce PA-DSS scope by avoiding the need to handle cardholder data. If gateways support strong security features, developers can save time and certification costs, and will be able to pass savings on to their merchants.

8. Multi-currency support

For US merchants selling internationally, multi-currency support can be a plus. While merchants can always accept international cards, and settle payments in US dollars, foreign consumers often prefer to shop in their own currency rather than be surprised by sometimes excessive exchange rates. While not essential for international sales, multi-currency support can help online merchants improve conversions and boost revenue.

9. Breadth of processors and payment methods supported

There are many types of payment gateways. Some have affinities to particular banks, and others to specific methods of payment. Merchants and developers should look for a gateway that supports the broadest range of payment methods including in-store payments and various mobile wallets. If a gateway can support multiple payment processors as well, this is a bonus because it provides added flexibility for merchants.

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

While consumers often think of Apple Pay from the perspective of in-store payments (currently the most visible use case), it turns out that webpayments 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.

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.

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.

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 (https://w1.mercurycert.net/ws/ws.asmx) in a browser shows the available SOAP methods and documents how they are called.

3. HTTP/S POST APIs

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.

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.

4. REST APIs

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.

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.

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.

It seems that every time we turn around, there is more news about digital wallets and their potential impact on payments. Whether you’re a merchant or an application developer, with so many players, and new developments coming at a furious pace, the digital wallet landscape is become confusing indeed. If your organization is like most, you have limited resources, so choosing the right wallet strategy is important. For most, the technology promises to improve customer convenience, conversions, loyalty, revenue and profitability. For readers unfamiliar with digital wallets, hopefully this short article will serve as a helpful primer.

Defining the term digital wallet seems like a good place to start. Definitions vary, but digital wallets are usually viewed as a way of storing or referencing payment credentials on an electronic device, such that the device can be used to make a payment. Most wallets allow you to place credit cards, debit cards or other payment sources into a virtual wallet, and use that wallet to make purchases on-line, in mobile applications (in-app), or in the store depending on the wallet and how and whether merchants support it.

With so many potential points of comparison, and hundreds of wallets on the market, it can be difficult to compare wallets directly. It's possible to group wallets into some broad categories however, and one way of doing this is to look at the types of organizations providing the wallets and their business motivations. While there are exceptions to any rule, most wallets fall into one of these categories:

Mobile wallets (from mobile device manufacturers) - Wallets provided by device manufacturers are meant to provide convenience, and bias a consumer to a manufacturer’s phone, tablet or other device as well as the software, service and partner ecosystems that surround them. These types of wallets are generally agnostic as to the underlying method of payment. Examples are Apple Pay, Android Pay and Samsung Pay. Most support in-store payments (using NFC or QR codes) as well as in-app payments. Mobile wallet providers are busily adding support for one-touch payments for participating eCommerce merchants, to simplify the payment process on mobile websites and compete with other wallet providers like PayPal and Amazon Pay traditionally focused in this area. There is some blurring of the lines between the terms mobile wallet and digital wallet, but mobile wallets are usually understood to be wallets provided by a mobile device provider.

Issuing banks – While most banks will support one or more of the mobile wallets described above, some banks also provide their own wallets for the convenience of their banking customers. These wallets typically provide capabilities that bias users in some fashion toward payment methods and services friendly to the bank – either by restricting the payment cards supported, by providing incentives to use bank-issued credit or debit cards, or by providing access to additional bank services in a convenient, consolidated app. Examples of wallets in this category are Chase Pay and CapitalOne. These wallets can generally be used at selected retail locations, and some (like Chase Pay) provide support for on-line purchases as well.

Credit card companies – The card brands play a key enabling role for other wallets, but they also offer their own wallets. Not surprisingly, card brands want to make it easier for consumers and merchants to use their payment cards regardless of the issuing bank, so wallets provided by these organizations reflect a bias to their own payment cards while being device, bank, payment processor and retailer agnostic. Examples of wallets in this category are Masterpass, Visa Checkout and AMEX Express Checkout. Credit card companies are working to make it easier for retailers to integrate eCommerce web stores and mobile apps with their respective wallets to help them capture a larger share of commerce. While most of the action is around on-line purchases today, the card brands clearly have their eyes on wallet-enabled in-store payments as well.

Merchant provided wallets – Large merchants sometimes provide their own wallets. Merchants want to promote loyalty to their own-brand, cross-sell and up-sell products and services, and avoid intermediaries in the payment processing chain that might erode revenue and margin. Wallets provided by merchants are typically agnostic of the device used for payment and are intended to bias consumers toward doing more business with that specific merchant by providing a variety of convenience features and incentives. Examples are wallets like Walmart Pay and the Starbucks app. Another large retailer, Amazon.COM with their Amazon Pay wallet has gone a slightly different direction allowing their wallet technology developed for their own on-line store to be used by other merchants as well, essentially competing with not only other retailers, but with other payment providers also. Other retailers not offering their own wallets are leveraging third party mobile wallets and incorporating these into their own apps and mobile websites.

Alternative Payment Providers – Some payment providers also provide their own wallets. Providers like PayPal and AliPay are well established in eCommerce payments, and store payment credentials for millions of users. Not surprisingly, they’re aiming to leverage their large base of existing users to gain further market share in mobile web and in-app transactions, and are providing features that compete with banks like peer to peer payments. Some of these providers are seeking to gain a foothold in in-store / card present payments as well. Other alternative payment players like Coinbase provide wallets focused on storing and facilitating payments using digital currencies like bitcoin and ethereum enabling both consumers and merchants and facilitating both consumer to business and peer to peer transfers. Social platform providers (like China's WeChat) are squarely in the game, augmenting their capabilities with wallets for peer-to-peer, on-line and in-store payments, helping solidify their position as a hub for on-line activity.

Specialty / Independent Providers – In addition to the wallet categories above, there are additional digital wallets types more focused or specialized capabilities. For our purposes we’ve lumped a few different types of wallets together in the interests of brevity. Some wallet providers focus specifically on the challenge of collecting, storing and managing the redemption of gift cards, loyalty cards and coupons. Managing these cards and ensuring that balances are fully spent is a challenge understood by all of us who have received gift cards or other program incentives. Examples are providers like Gyft (acquired by First Data), CardStar and Keyring. Other providers like eWallet take a different approach, focusing less on the challenge of payments, and more on the challenge of organizing credentials of all types (payment cards, web-site / social-media logins, insurance cards, passports) into a secure cloud-based service accessible from multiple devices. Providers in this category address another twenty-first century challenge, familiar to all of us with multiple cards and dozens or even hundreds of login accounts for various websites and on-line services. Other providers like LevelUp focus in important niche areas like quick-serve restaurants allowing consumers to order ahead and skip the line by paying on their phone. The Chinese market is likely the model where the use of digital wallets is widespread. According to Inside Retail Asia, 76.1% of respondents to a survey of smartphone users in China indicate that they have made a purchase from their smartphone.

For years, pundits have been claiming that “this will be the year of the digital wallet”. Despite a fragmented market, and relatively slow market adoption (at least in North America) the growth trajectory appears clear. Major technology providers and retailers now have well-articulated strategies, and are moving quickly to roll out the technology and promote it. While McKinsey estimates put mobile payments at less than two percent of consumer spending in the US in 2015, their analysis suggests that this will grow to 9% by 2020 (a 350% increase) with the majority of these payments involving stored credentials. Importantly, some industries will see much higher penetration for mobile payments and wallets.

As competition heats up, and consumers demand convenient payment options, especially from mobile devices, the use of digital wallets is expected to grow dramatically. If you’re not already thinking about how to serve your customer with more convenient payment options, chances are good that your competitor is.

For Vantiv customers and partners interested in embracing digital wallets as part of their payment acceptance strategy, 2017 is shaping up to be an exciting year. Vantiv is busily rolling out additional technical resources for developers of wallet-enabled payment applications across Vantiv’s payment platforms. Join the Vantiv O.N.E. community, and follow our Mobile & Digital Wallets sub-community to stay abreast of new developments.

Do you have thoughts on mobile wallets? I’d welcome your thoughts and perspectives!

The table below provides a brief summary and comparison of some of the mobile and digital wallets mentioned in this article as well as links to more on-line resources.

What developers need to know

Merchants selling services or digital goods on-line often employ a subscription model, where consumers are billed a set amount monthly rather than paying the full amount up front. Not only is this attractive to consumers, it helps merchants reduce sticker shock while enjoying a predictable revenue stream less affected by spikes or troughs in sales.

While consumers may think of mobile wallets in the context of tap payments at the point of sale, they are increasingly being used for in-app and mobile web purchases. With the convenience mobile wallets provide, merchants are understandably interested in using mobile wallets for subscription payments as well.

An abundance of wallet frameworks

For developers, combining subscriptions and mobile wallets can be tricky business. While issues vary by wallet provider, below are some considerations specific to Apple Pay:

Core to the security model of Apple Pay is the notion of a one-time payment token. This is attractive to consumers, because even if the payment token is compromised, the design is such that the token can't be used for a separate purchase in future. Such a scheme seems (on the surface at least) to be at odds with the idea of a recurring payment stream.

While Apple makes it clear that Fixed and Flexible Frequency Subscriptions are supported with Apple Pay (see Apple Pay description here), merchants are pointed to their payment provider for details. As developers know, the devil is often in the details!

Developers of applications involving the sale of digital goods are pointed to the In-App Purchase Programming Guide describing the use of the Apple Store Kit framework. While the Store Kit framework explains managing subscriptions through the Apple store, this may be the wrong business model for the merchant. Merchants with an existing on-line store already accepting card payments may be better served by using the Apple Pay PassKit Framework (for iOS in-app purchases) or the Apple Pay JS Framework (when adding Apple Pay to their mobile website)

Similar issues are at play for developers seeking to integrate with Android Pay. Developers have the choice of selling digital goods from within Android apps using Google Play in-app billing (which like its Apple counterpart is subscription payment friendly), using the Android Pay API for in-app payments, or the emerging W3C Payment Request API for mobile web payments. Other mobile wallets involve the use of still additional APIs depending on the mobile wallet and payments use case.

Most on-line sellers, will want to offer their consumers multiple payment methods. This means that in practice, developers may find themselves needing to support multiple frameworks to provide the richest set of payment options.

Evolving Network guidelines

In addition to fast evolving wallet frameworks and APIs, the rules around the use of stored credentials & tokenization schemes for subscription payments are evolving as well.

With its October 2016 release, VISA is implementing changes related to merchant-initiated transactions. Several of these changes will impact recurring / subscription payments using stored credentials including Apple Pay and Android Pay.

By April of 2017, installment transactions involving the use of a stored credential will need to be identified (VISA ID #0024724). Effective October 2017, initial transactions and installment transactions will need to be identified with an indicator with an indicator, and subsequent transactions in a recurring stream will need to contain the transaction identifier of the initial transaction (VISA ID #0029843). Discover is also extending their tokenization service to recurring billing transactions with similar requirements (See Vantiv Fall 2016 Network Updates – Discover Enables Recurring Billing and Partial Shipment Transactions for Tokenization).

Because of these changes related to the handling of subscriptions involving tokens, merchants may need to manage these recurring payment streams on their own until such a time as value-added software solutions that automate the handling of recurring payments catch up with network requirements.

Implementing subscription payments today

The good news is that subscription functionality with popular wallets is available today on Vantiv’s payment platforms. Vantiv can help developers can build payment enabled apps and websites that enable popular wallets to fund subscriptions while complying with network requirements.

Merchants accepting wallet payments will want to present traditional payment card alternatives as well because not all consumers will have a wallet enabled on their phone or tablet. For eCommerce merchants extending the functionality of their websites to support mobile wallets, Vantiv’s eProtect can be a good solution since it abstracts away much of the complexity of dealing with different payment types. The result is a single payments integration approach regardless of whether a consumer opts to pay with a Credit Card or via Apple Pay or Android Pay.

While eProtect is not strictly required to accept subscription payments with digital wallets Vantiv O.N.E. members can review a detailed example involving Apple Pay and Recurring Payments here. Other methods of integrations involving mobile wallets are detailed in the Vantiv O.N.E. mobile payments space in Apple Pay and Google communities respectively.

Gone are the days when Robots were massive and expensive beasts, purpose-built and affordable only to large manufacturers. As technology, materials and software have evolved, the cost of Robots has plummeted. Today, they are everywhere we look including around the home.

Some do useful work (thank you iRobot Roomba), but others are basically toys, wasting their enormous potential, consuming electricity and taking up space. After a while they’re like teenagers - talking back, sleeping-in past noon, and playing loud music (looking at you Amazon Echo). Before you know it, they’ll be raiding the fridge and even driving your car.

The time has come for your Robots to get a job. Of course, a pre-requisite is that they need to be able to do something useful. This is where you come in! Second, they need to be able to charge for their services, and this is where Vantiv comes in.

The Money 20/20 Hackathon

Vantiv values passion—not only for payments, but for technology, commerce and improving life. Over the past two years, Vantiv has sponsored the Money20/20 Hackathon. Now on our third year, we are excited to work with great minded developers again.

You likely have bigger and bolder ideas than just putting robots to work, and to help trigger your creative talents, we’re bringing an awesome bundle of cool gadgets to Money 20/20.