- Payroll-connected income verification APIs return verified employer name, job title, income, and employment status in seconds, without a borrower uploading a single document.
- The five providers most worth evaluating are Argyle, Pinwheel, Truework, Atomic, and Plaid Income, each with meaningfully different payroll coverage maps and pull-success rates.
- Coverage rate, not feature count, is the deciding variable. A provider covering 85% of your borrower base outperforms a feature-rich one covering 55%.
- Pricing is not publicly listed by most providers. Budget for per-pull fees, not subscriptions, and negotiate volume tiers before you sign.
- Consumer-permissioned data carries FCRA obligations. Anyone using these APIs for credit decisioning needs a compliant credentialing and adverse-action flow before going live.
The best income verification APIs for lenders connect directly to payroll systems and return verified employer name, employment status, gross income, pay frequency, and tenure in a single API call. Argyle, Pinwheel, Truework, Atomic, and Plaid Income are the leading US-focused providers. Truework adds document-based fallback for borrowers outside payroll coverage; Argyle and Pinwheel lead on direct payroll integrations; Atomic covers a large share of ADP and Paychex users; Plaid Income combines bank-data income estimation with payroll connectivity.
Why Pay Stubs Are a Broken Verification Method
Asking borrowers for pay stubs made sense in 2005. Today it produces friction, fraud risk, and abandonment. A borrower who has to locate, download, and upload a recent pay stub faces three opportunities to give up, and one opportunity to fake the document instead.
Document fraud on income verification is not theoretical. Tools that generate convincing fake pay stubs are widely available. A lender processing manual documents has no reliable way to detect manipulation without investing in separate fake document detection tools, which adds another layer of cost and latency to an already slow process.
Payroll-connected APIs solve this at the source. Instead of asking the borrower to prove their income, the API asks the payroll system directly, with the borrower’s explicit consent. The data comes from the employer’s payroll provider, not from a PDF the borrower touched.
What Does a Payroll Data API Actually Return?
A well-structured income verification API call returns more than a number. The response from providers like Argyle or Pinwheel typically includes: verified employer name and address, employment status (active, terminated, leave), job title and department, pay frequency (weekly, bi-weekly, semi-monthly), gross income per period, year-to-date earnings, and in many cases up to 24 months of historical pay data.
That income history matters for underwriting. A borrower who earned $90,000 last year but started a new job three months ago at $120,000 looks very different from one with two years of stable $90,000 income. Both show the same current salary; the history reveals the risk profile. According to Truework’s public documentation, their API supports access to historical pay records that supplement point-in-time decisioning.
Some APIs also return shift-level data for hourly workers, which is relevant for gig-adjacent employers. Others aggregate multiple income sources in a single response, useful for borrowers with a primary job plus a secondary employer.
The FintechSpecs Payroll Coverage Stress Test
Before evaluating features, apply what we call the FintechSpecs Payroll Coverage Stress Test: four checks that expose whether a provider will actually work for your borrower population, not just the demo population their sales team shows you.
Check 1: Payroll platform share in your geography. Ask the provider which payroll platforms they connect to and what share of US employed workers those platforms represent. ADP, Paychex, Workday, Gusto, Ceridian, UKG, and QuickBooks Payroll together cover the majority of US payroll. A provider weak on any major platform has a gap that will show up in your pull-success rate.
Check 2: Direct vs. credential-based connections. Some providers use employer-direct connections (the employer shares data via API agreement). Others use credential-based flows where the borrower logs into their payroll account. Credential-based connections have higher fallback rates when employees do not remember their login. Direct connections are more reliable but depend on employer participation agreements.
Check 3: Fallback coverage for non-payroll workers. Gig workers, contractors, self-employed borrowers, and employees of small businesses often have no payroll platform to connect. Ask what the provider offers for these segments: bank data income estimation, document parsing, or nothing.
Check 4: Pull-success rate for your segment specifically. Providers publish overall coverage numbers. Ask for pull-success rates segmented by borrower type, income range, and employer category relevant to your portfolio. A provider with 80% overall success rate might have 55% success on hourly retail workers if that is your core segment.
The 7 Best Income and Employment Verification APIs for Lenders
| Provider | Primary Data Source | Document Fallback | Gig/Contract Coverage | Historical Income Depth | FCRA Compliant | Pricing Model |
|---|---|---|---|---|---|---|
| Argyle | Direct payroll + employer | Limited | Yes (gig platforms) | Up to 24 months | Yes | Per pull, custom |
| Pinwheel | Direct payroll API | No | Partial | Up to 24 months | Yes | Per pull, custom |
| Truework | Employer network + document | Yes (VOE/VOI forms) | Limited | Varies by employer | Yes | Per verification |
| Atomic | Payroll credential-based | No | Limited | Up to 24 months | Yes | Per pull, custom |
| Plaid Income | Bank data + payroll | Document parsing | Yes (bank transactions) | Up to 24 months | Yes | Per user, custom |
| MeasureOne | Consumer-permissioned data | Yes | Yes (multi-source) | Up to 24 months | Yes | Per verification |
| The Work Number (Equifax) | Employer-direct database | No | Limited | Varies | Yes | Per inquiry |
1. Argyle
Argyle built its product around direct connections to payroll platforms and gig economy employers, which means the borrower’s login credentials are used to pull data directly from the source system. Coverage spans major payroll providers as well as gig platforms including Uber, DoorDash, and Lyft, which is a meaningful differentiator for lenders serving non-traditional workers.
Argyle’s data model returns employment status, income, deductions, and shift-level data where available. Their consumer-permissioned approach means the borrower explicitly authorizes each pull, which satisfies the FCRA permissioned data framework. Pricing is not published publicly; Argyle sells on a per-pull basis with volume discounts negotiated directly.
The strongest use case for Argyle is a lender whose borrower base skews toward hourly workers, gig workers, or employees of large enterprises using well-known payroll systems. Lenders with a self-employed or very-small-business borrower base will find coverage gaps.
2. Pinwheel
Pinwheel focuses on direct payroll API connections, covering platforms including ADP, Gusto, Paychex, Workday, and several others. The connection mechanism is credential-based: the borrower authenticates into their payroll account during the verification flow, and Pinwheel pulls the data in real time.
Pinwheel’s differentiator within this set is developer experience. Their API is well-documented, the sandbox environment is functional for testing edge cases, and their webhook architecture supports asynchronous income pulls without holding the user session open. For a product and engineering team that wants to move fast, Pinwheel’s integration surface is one of the cleaner ones in the market.
One trade-off: Pinwheel does not offer document-based fallback. Borrowers who cannot remember their payroll login, or who work for employers not connected to a payroll platform, produce a failed pull with no recovery path unless you layer in a separate document solution.
3. Truework
Truework takes a different architecture than pure payroll API providers. It operates an employer network where participating employers respond to verification requests directly, alongside an automated instant path through payroll data, and a manual VOE/VOI (verification of employment and income) fallback. The practical result is higher coverage for hard-to-reach borrowers, at the cost of speed for the fallback tier.
For lenders who need a single vendor to handle both the fast payroll-connected pull and the manual verification for edge cases, Truework reduces the integration surface. Their API documentation states that the instant path returns results in seconds; the manual fallback adds business-day latency. Pricing is per verification and varies by path taken.
Truework is the strongest fit for mortgage and auto lenders, where the verification requirement is specific (VOE and VOI as distinct deliverables) and where manual fallback is expected rather than exceptional. Consumer fintech lenders optimizing for conversion speed may find the fallback latency frustrating.
4. Atomic
Atomic positions itself as a payroll connectivity platform that spans income verification, direct deposit switching, and earned wage access. For lenders, the income verification use case sits within a broader payroll data suite, which is relevant if you are also building adjacent payroll-connected products.
Atomic’s coverage skews toward large enterprise payroll processors. Their documentation highlights connections to ADP, Paychex, and Ceridian among others, which represents a significant share of W-2 employed workers in the US. Their pull mechanism is credential-based, and the consumer consent flow is embedded in their pre-built UI components.
The case for Atomic over Pinwheel or Argyle is largely a platform bet. If you expect to build direct deposit switching or earned wage access on top of income verification, Atomic’s multi-product payroll connectivity model reduces the number of vendors you are managing. For income verification as a standalone need, the comparison is closer.
5. Plaid Income
Plaid Income takes a layered approach. The first layer is bank transaction-based income estimation: Plaid analyzes a borrower’s transaction history to infer income, frequency, and stability without requiring payroll login credentials. The second layer is payroll connectivity, which provides more granular employer-level data. The third is document parsing for tax forms and pay stubs.
For lenders who already use Plaid for bank account verification or cash flow analysis, adding Plaid Income is a low-friction upsell with a single SDK and a single vendor relationship. The bank-data layer provides meaningful coverage for gig workers and self-employed borrowers who have no payroll platform to connect to.
The trade-off is depth. Bank-derived income estimates are probabilistic rather than authoritative. A payroll API returns the employer’s certified payroll record; a bank transaction analysis infers income from deposit patterns. For underwriting decisions where the income figure is a hard input, lenders should understand which layer a given borrower’s data is coming from and weight it accordingly. Plaid’s public pricing page does not list per-unit prices; pricing is custom and negotiated.
6. MeasureOne
MeasureOne operates as a consumer-permissioned data platform covering income, employment, and education verification. Their income API ingests data directly from the borrower’s source accounts, including payroll providers, tax platforms, and financial institutions, depending on what the borrower connects.
MeasureOne’s multi-source architecture means a single integration can cover a broader range of borrower types than a pure payroll API. Their documentation indicates support for up to 24 months of income history. The verification output is structured for lending workflows, including fields for employer name, income figures, and employment continuity.
MeasureOne fits lenders with diverse borrower populations where no single data source will cover the majority. The flexibility comes with integration complexity: the connection flow depends on the borrower connecting the right account type, which adds UX variables you need to design around.
7. The Work Number by Equifax
The Work Number, operated by Equifax, is the largest employer-direct income and employment verification database in the US. Employers contribute payroll records directly to the database. Lenders query it and receive a response from the employer’s actual payroll record without requiring any borrower action.
The coverage footprint is substantial. Equifax reports that The Work Number database holds records for a large share of the US workforce, contributed by employers including many of the country’s largest companies. The borrower does not need to log into anything or upload anything, which removes the consent-flow friction entirely.
The significant constraint is employer participation. Small and mid-sized employers are less likely to contribute records, which means the database is strongest for borrowers employed by large corporations, government entities, and major healthcare systems. Self-employed borrowers, gig workers, and small business employees will frequently return no record. Pricing is per inquiry and is not publicly listed; lenders access The Work Number through a credentialed account relationship with Equifax.
How Do Pull Success Rates Vary Across Providers?
No provider publicly discloses segment-level pull success rates in a comparable format, which is itself a red flag worth acknowledging. When a sales team quotes you a coverage number, the two questions to ask immediately are: what counts as a successful pull (a complete data response, or any response at all?), and what borrower segment was that number measured on?
Consider a hypothetical to illustrate the exposure: a direct-to-consumer personal loan lender processing 1,000 applications per month with a borrower mix of 60% salaried employees, 25% hourly workers, and 15% gig workers. A provider with 85% overall coverage but 50% gig-worker coverage would fail to retrieve data on roughly 225 applications per month. At a 20% approval rate, that is 45 loans per month that require a fallback document review or get declined without it.
That fallback cost compounds. Manual document review adds overhead; declined applications due to missing data increase acquisition cost per funded loan. Lenders evaluating income verification APIs should request a pilot on their actual application traffic before committing to a primary vendor relationship.
What Are the FCRA Compliance Requirements for Payroll-Connected Income Verification?
Using a payroll-connected income verification API for credit decisioning triggers FCRA obligations. The data returned by these APIs constitutes a consumer report when used to determine credit eligibility, which means the lender must have a permissible purpose, provide adverse action notices when declining based on the data, and maintain a compliant data use agreement with the provider.
All seven providers listed here operate as consumer reporting agencies or have compliant data use agreements structured for FCRA purposes. The burden on the lender is the procedural compliance: obtaining proper authorization from the borrower, running adverse action notices correctly when a decline is influenced by income data, and retaining the required records. For a deeper look at what compliance infrastructure lending products require before going live, the Fintech Product and Compliance Readiness Checklist covers the key pre-launch obligations.
One specific obligation worth flagging: the consumer-permissioned consent flow must be structured so the borrower understands they are authorizing access to their payroll data and for what purpose. Pre-checked consent boxes do not satisfy FCRA authorization requirements. This is an area where API providers offer consent UI components, but the lender is ultimately responsible for the adequacy of the authorization.
How Does Payroll-Connected Income Verification Compare to Bank Data Income Estimation?
These are not competing methods so much as complementary ones with different precision levels. Payroll-connected data is employer-certified: the figure reflects what the employer’s payroll system recorded as gross pay. Bank transaction-derived income is inferred: it reflects what arrived in the borrower’s account after deductions, taxes, and any other adjustments the payroll system applied.
Bank data has broader coverage because any borrower with a bank account can share transaction history, regardless of employer size or payroll platform. It captures multiple income streams naturally, including side income and gig deposits. The limitation is precision: net deposits do not map cleanly to gross income, variable pay is harder to normalize, and large non-income deposits (transfers, tax refunds, sale proceeds) can inflate apparent income if the model is not calibrated carefully.
For lenders building underwriting models, the practical approach is to use payroll-connected data as the primary input where available, bank data estimation as the fallback, and document verification as the last resort. Plaid Income and MeasureOne both support layered architectures; the others require you to stitch the fallback together yourself. This distinction becomes important when evaluating the total cost of the verification stack, not just the per-pull price of the primary API.
What Should Lenders Ask Before Signing an Income Verification API Contract?
Pricing varies across all seven providers, and none publish standard per-unit rates. Before entering procurement, lenders should ask five specific questions: What is the per-pull fee at your current volume, and at 3x volume? What is the refund or credit policy for failed pulls that return no data? What SLAs govern response time and uptime? Who owns the borrower’s consent record, and what does data retention look like? Can you provide pull-success rate data for a borrower mix matching our actual application population?
The fifth question is the most important and the one sales teams are least prepared for. Pushing for a segment-specific success rate before the pilot closes forces an honest conversation about coverage gaps before you are mid-integration. For a broader framework on evaluating fintech infrastructure vendors before a contract commitment, the 7-point fintech vendor evaluation framework applies directly here.
One additional consideration for lenders using this data in underwriting models: the data schema returned by these APIs is not uniform across providers. Argyle and Pinwheel return different field structures for the same underlying data. If you are ingesting income data into a decisioning model or loan origination system, plan for a normalization layer. Switching providers mid-integration without it can break your model inputs.
How Does Income Verification API Fit Into a Loan Origination Stack?
An income verification API is one input among several in a loan origination workflow. The sequence typically looks like this: identity verification and KYC runs first, then credit bureau pull, then income and employment verification, then underwriting decisioning. Each step gates the next; a lender does not want to pay for an income pull on an applicant who fails identity verification.
For lenders building or evaluating their full loan origination stack, the loan origination and management software comparison covers how these platforms handle third-party data integrations, including income verification APIs. Some LOS platforms have pre-built integrations with Truework or Plaid Income that simplify the technical side; others require you to wire the income API call yourself.
Fraud risk sits adjacent to income verification. A payroll-connected API significantly reduces synthetic income fraud by pulling from the source, but it does not eliminate identity-layer fraud. A fraudster using a real person’s credentials to authorize a payroll pull is a real threat vector. The income data will be accurate; the identity attached to it may not be. Layering income verification with identity fraud detection closes that gap.
Coverage by Employer and Payroll Platform: What to Know
| Payroll Platform | Argyle | Pinwheel | Atomic | Plaid Income | Work Number |
|---|---|---|---|---|---|
| ADP | Yes | Yes | Yes | Yes | Employer-direct |
| Paychex | Yes | Yes | Yes | Yes | Employer-direct |
| Gusto | Yes | Yes | Partial | Yes | Limited |
| Workday | Yes | Yes | Yes | Partial | Employer-direct |
| Ceridian / Dayforce | Partial | Partial | Yes | Partial | Employer-direct |
| QuickBooks Payroll | Yes | Yes | Partial | Yes | Limited |
| Gig platforms (Uber, Lyft, DoorDash) | Yes | Partial | Limited | Via bank data | No |
| Small/local employers | Limited | Limited | Limited | Via bank data | Limited |
Note: Coverage designations are based on publicly available provider documentation and developer portal information. “Partial” indicates the connection exists but with known gaps in data completeness or reliability reported in developer community discussions. Lenders should validate current coverage directly with each provider before production deployment.
Frequently Asked Questions
What is an income verification API?
An income verification API connects to a borrower’s payroll system or bank account, with the borrower’s consent, and returns structured income and employment data. The response typically includes employer name, employment status, job title, gross income, pay frequency, and historical earnings going back 12 to 24 months. Lenders use this data in underwriting to verify a borrower’s stated income without relying on documents the borrower provides manually.
What is the difference between an income verification API and an employment verification API?
Employment verification confirms that a person works at a specific employer, their start date, and whether they are currently active. Income verification returns the financial details: how much they earn, how often, and historical income trends. Most payroll-connected APIs return both in a single call. Standalone employment verification APIs, like those used for background screening, may return employment status only without income figures. For lending, you typically need both, and the providers listed here return both.
Does E-Verify have an API for income or employment verification for lenders?
E-Verify is a US government system used by employers to confirm that new hires are legally authorized to work in the United States. It is not designed for lender income or employment verification, does not return income data, and is not available for third-party lending use. Lenders looking for payroll-connected income and employment data need a commercial provider such as Argyle, Pinwheel, Truework, Atomic, or Plaid Income. E-Verify and these commercial APIs serve entirely different compliance functions.
What is consumer-permissioned income data?
Consumer-permissioned income data refers to income and employment information that a borrower explicitly authorizes a lender or data provider to access on their behalf. The borrower connects their payroll account, bank account, or other income source through an API consent flow. The data is pulled directly from the source system rather than provided by the borrower as a document. Under the FCRA, this data constitutes a consumer report when used for credit decisioning, which triggers specific disclosure and adverse action requirements.
How do banks verify proof of income?
Traditional banks verify income by reviewing pay stubs, W-2 forms, tax returns, or bank statements provided by the applicant. More technically advanced lenders now use payroll-connected APIs or bank data income estimation through providers like Plaid, Argyle, or Truework to pull income data directly from source systems with borrower consent. The payroll-connected method is faster and less susceptible to document manipulation than manual review, and it returns richer historical data than a single pay stub provides.
What pull-success rate should lenders expect from payroll income verification APIs?
No provider publicly discloses standardized pull-success rates by segment. Overall coverage figures quoted by sales teams vary and typically reflect best-case borrower populations. In practice, lenders should expect lower success rates for gig workers, small business employees, and borrowers outside major payroll platforms. Lenders should request a pilot on actual application traffic before committing to a primary provider, and specifically ask for pull-success rates segmented by employer type and payroll platform rather than accepting a single aggregate figure.
What is the FCRA risk of using a payroll API for underwriting?
Using payroll-connected income data to make credit decisions means the data provider is functioning as a consumer reporting agency under the FCRA. The lender must have a permissible purpose for the inquiry, obtain proper borrower authorization before the pull, send adverse action notices when a decline is based on the data, and maintain compliant data retention practices. All major providers in this space structure their agreements to support FCRA compliance, but the procedural obligations on the lender’s side require active implementation, not just a vendor contract.
The Real Differentiator in This Market Is Coverage, Not Features
Every provider in this list offers a well-designed API, reasonable documentation, and a consent flow that works. The features converge quickly. What does not converge is the coverage map, and that is where lenders make costly mistakes by evaluating providers on demos and pricing rather than on how their API performs against real application traffic.
The providers with the broadest gig and non-traditional income coverage, Argyle and Plaid Income, serve lenders whose borrower base skews away from traditional W-2 employment. Truework earns its position for lenders who need a single-vendor fallback for cases where automated pulls fail. Atomic fits lenders who are also building payroll-adjacent products. The Work Number by Equifax is the most reliable for large-employer W-2 borrowers without requiring any borrower action, but it leaves meaningful gaps for everyone else.
The borrower population you serve determines which provider fits. A lender processing mortgage applications for corporate employees and a direct-to-consumer personal loan company serving gig workers need different primary providers and different fallback architectures. Identifying that correctly before the integration begins is worth more than any feature comparison. For lenders thinking through the broader data infrastructure around underwriting, the data enrichment APIs for fintech underwriting comparison covers the surrounding data inputs that context-alize income and employment verification within a fuller risk picture.
