As consumer-permissioned income and employment verification services via Payroll API become more common, it is critical to find the right one for your business. Follow these three steps and you'll be able to make the best decision for your company without the hassle of developing your own evaluation criteria.
When it comes to finding the right vendor to solve any business problem, the best teams usually consider three things: the return, the investment of money and time, and the risk.
When choosing a consumer-permissioned income and employment verification service, you should consider:
Let's start by unwrapping each component.
There are a variety of definitions of “success rate” from Payroll API services, so we need to make sure we're comparing apples to apples.
At Truv, we define success rate as the ratio of successful connections to the number of times Truv Bridge was requested to be presented to users.
The formula is simple:
Success rate = [ # of successful connections / # of unique users ]
Each successful connection requires successful authentication and successful execution of a function, such as reading employment information, processing paystubs to calculate income, changing direct deposit, and so on.
When Truv claims a successful income and employment verification, we mean that we connected to the payroll account AND collected all of the necessary data within the stringent Government Sponsored Enterprise (GSE) specifications. If we are unable to obtain all of the required data, we count the instance against our success rate.
Payroll API services use a variety of methods to link payroll accounts, so always double-check that the definition of a unique user is the same.
For example, to improve the success rate, a developer could first search a list of supported companies and then only show the Truv Bridge if the search is successful. As a result, fewer unique users will see the Truv Bridge, and each user will be much more likely to connect to their payroll provider.
In non-integrated solutions, we see the success rate negatively affected. Without the direct integration to the Truv Bridge the workflow relies on an email to the end-user which means the success rate is only a fraction of its potential in this workflow simply due to some users being unresponsive to emails.
When comparing success rates, make sure you're comparing apples to apples in terms of successful connections and unique users who will see the UI. Always request real data for a specific flow and for your vertical (e.g. mortgage).
Let's look at what other factors influence the success rate.
Truv defines coverage as the number of end-users who can access their data via our platform, which is only limited by the number of payroll systems that Truv is integrated with.
Payroll systems come in a variety of flavors and covers over 160 million people in the workforce: off-the-shelf payroll integrations (e.g. ADP, Paychex), white-labeled systems that require authentication via single sign-on, purpose-built systems (e.g. MyPay), home-grown systems (e.g. Walmart), gig companies, unemployment portals, and more.
Because each payroll API company decides how to best serve its customers, comparing the number of integrations between one API and another is meaningless.
Trying to figure out which payroll API provides the best coverage is similar to rating which car is the best; ‘best’ depends on what’s important to you. To help prospective customers evaluate whether Truv could be a good coverage match for their business we offer a quick, simple coverage analysis of your top 100 or top 1000 employers.
Alternatively, you can inquire about a provider's coverage for each workforce segment or request coverage for industry benchmarks such as the Fortune 1000.
To summarize, remember to request the following information to better understand the coverage of a payroll API:
Even if the payroll system is covered by a payroll API company, this does not guarantee that the user will be able to successfully connect their payroll account.
Drop off can occur at any point along the process. A few common areas where we see drop-off occur:
When evaluating payroll APIs, be aware of the extent of white labeling available on the platform, the ability to skip screens, and the general aesthetics of the user interface (UI).
To summarize, here’s a list of information to request:
Due to a variety of use cases, a payroll API’s data quality and data availability may differ dramatically. It’s best to compare APIs based on the most relevant data for your business.
It is best to compare available data fields by looking at benchmarks such as fields required by GSEs. As a mortgage provider, you might be interested in the last three years of data, while as a consumer lender you might need only the last three pay stubs. We recommend always referencing industry benchmarks, as some data returned by a payroll API might be irrelevant.
To compare data quality, look at the availability of data for your most important fields, such as job title or annual income summary. The metric that we use internally at Truv is the average and median ratio of the number of cases when a data field is filled out divided by the number of successful connections.
For some applications, you may want to keep a connection open and update the data as needed. A good example would be a mortgage application where the lender must verify income and employment multiple times. Many providers track these types of continuous connections and attempt to block payroll APIs. It’s important to ask for the median time that a connection stays active for each payroll provider to confirm that those times meet your requirements.
Finally, raw data in the form of pay stubs or W2s in PDF format should be available if you want to double-check the data quality.
Here’s a list of information that should be available from a quality payroll API:
Adopting a new feature to a hectic roadmap can be difficult for many organizations, so having an easy-to-implement payroll API is critical.
To get a good effort estimate, ask your developers to go through the quickstart apps and getting started guides provided by a payroll API in their online documentation. Quality APIs should maintain up-to-date documentation and provide a testing environment for your developers.
When it comes to implementation, you'll want to work with a team that can create prototypes or shows you how other companies have implemented payroll API solutions. If you’re an enterprise customer, ask whether you will be assigned a dedicated engineer to assist you through the implementation process by answering questions and guiding you through the process.
A quick checklist for evaluating implementation:
After the solution is successfully implemented, you’ll continue to collaborate with your partner's team on an ongoing basis. Request a quick session with an existing client or review available case studies to evaluate what a post-launch experience would look like. Ideally, you'd want to find a partner who can provide post-launch marketing, engineering, and analytics support.
Below is a quick checklist for assessing implementation:
Truv takes pride in being the most affordable payroll API solution, but what does the price entail?
The total cost of ownership includes both the initial investment and the ongoing costs of running the solution. Depending on your use case, payroll APIs may charge significantly different fees, and the total cost of ownership may be quite different.
The best method is to compare the cost per 1000 transactions over a twelve-month period. This way, you'll account for implementation costs, transaction costs, minimums, and ongoing monitoring fees.
We recommend requesting pricing broken down by category:
When it comes to payroll API risk, it is critical that personal data is encrypted in transit and at rest. This means that even if a data breach occurs, no one will be able to access the data in its raw, unencrypted form.
Furthermore, your production data should never leave the United States, so before allowing anyone access to the data, you should understand where it is stored and what protocols the payroll API has in place.
Finally, the payroll API should provide end-users with the appropriate disclosures regarding what data will be accessed and how data will be used and stored.
Instead of assessing all of the security and privacy risks yourself, it’s a good idea to rely on security certifications such as SOC 2 Type II and review the reports associated with such certifications.
To summarize, security is the key risk associated with any payroll API solution, so we recommend requesting the following:
Enterprise companies must be able to delete data and credentials once they have been gathered by the payroll API and successfully downloaded to the service.
Although most payroll APIs have excellent tools, it's always a good idea to double-check that you can manage data and retain ownership of the data.
Finally, because your company will be associated with the payroll API service, you are likely looking for a partner with a stellar reputation.
Before making a purchase decision, we recommend conducting a few Google searches and reading about a potential partner's prior industry experience or adherence to InfoSec best practices.
To conclude this blog post, we decided to organize all of the information you might want to request in a sample RFI. If you decide to begin the journey of picking a payroll API, we'd love to share with you a sample RFI and discuss how we stack up against the competition.