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.
It’s all about risk-adjusted return on investment
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:
- your return: what’s the success rate that you’ll get when end users try to connect to each payroll provider?
- your investment: the amount of time and money you’ll have to invest in the implementation of the solution and how much you’ll pay per transaction going forward
- your risk: the provider’s data and security governance procedures
Let’s start by unwrapping each component.
Success rate
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.
Coverage
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:
- Live payroll integrations
- Coverage benchmarks: Fortune 1000 companies, largest GIG economy companies, top Federal agencies, etc.
- Custom analysis for your top 100 or top 1000 employers
User experience
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:
- Mapping: A user may not be aware of their payroll provider, even if it is supported by the payroll API.
- Single sign-on (SSO): Before a user can access their payroll provider they might have to authenticate via SSO.
- Credentials reset: If a user does not remember their login credentials, they may have trouble resetting their credentials.
- Multi-factor authentication: The provider may add additional security such as text messaging, links sent to email, or captchas.
- Errors: A connection may fail after the user has successfully authenticated due to integration errors.
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:
- Number of mapped companies to payroll providers
- Number of payroll providers that allow credentials reset in the UI
- Supported single sign-on systems
- Supported multi-factor authentication methods by the provider
- Integration error rate as a percentage of total attempts
- Ability to customize colors and remove branding
- Number of companies available in search and search quality
Data fields
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:
- List of data fields that are available
- Benchmark vs. available fields comparison (e.g. Form 1005 by Fannie Mae)
- The average and median ratios of the number of cases in which a data field is filled out divided by the number of successful connections
- Availability of raw data that was used for aggregation
Investment & total cost of ownership
Implementation
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:
- Request an overview of the process with a dedicated solutions engineer
- Ask your engineers to estimate effort based on the public documentation
- Review implementation options (e.g. in-app, no-code emails, and text)
- Request UX guidelines and developer handbooks
Post-launch
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:
- Request a sample of a monthly or quarterly business report (QBR).
- Request a list of case studies or speak with current clients.
- Understand the contract and ensure that the SLAs are included.
Pricing
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:
- Implementation cost (if any)
- Sum of minimum payments made over a 12-month period
- Total number of expected connections over the next twelve months multiplied by the cost per connection
- Total expected number of active connections over a twelve-month period multiplied by the cost per connection
Governance
Security
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:
- SOC2 Type II auditor report (if available)
- Overview of InfoSec practices
Data management
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.
Reputation
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.
Conclusion
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.