I Built an EWA Platform — Here Are Six Questions Every HR and Payroll Leader Should Ask

I spent more than a decade in payroll before I ever wrote a line of a product spec. I processed pay runs, closed out reconciliations, and fielded the calls that come in when a paycheck doesn't match what an employee expected. I also ran a small business for years before Tapcheck existed. I watched people on my own team stretch every two weeks and take out payday loans against money they had already earned. That gap between doing the work and getting paid for it is what led me to start Tapcheck with my husband, Ron.

I designed Tapcheck to work inside the payroll and time systems that were already running, because I had spent years on the other side of a bad integration and knew exactly what that cost a team. That's still the lens I use every time I evaluate an EWA provider, including my own.

Most providers offer the same basic promise: employees get access to wages they've already earned before payday, at no cost to the employer, with no change to payroll. Most of the time, that promise is real.

The differences show up later, in how the available balance gets calculated, what your payroll team has to do on every pay run, and whether a mid-cycle termination creates a compliance problem or resolves itself automatically. At enterprise scale, those differences aren't edge cases. They're daily operations.

I've sat on both sides of this evaluation. First as the payroll person fielding the sales calls, and now as the founder building the product. Here are the six questions I'd ask before signing with any provider, including mine.

Question 1: How does the provider actually connect to your payroll system?

I've heard someone ask a payroll vendor “do you integrate with our system?” and take the yes at face value. Every provider will say yes. The real answer comes from the follow-up question: is this a direct API connection, or does the data pass through a third-party connector?

I know the difference because I lived on the receiving end of both. A direct integration reads live data from your payroll and time system in real time. Employee balances update as hours are worked. When someone registers, their identity gets validated against your system of record instantly, and reconciliation happens inside the normal payroll run.

A connector-based integration routes everything through a middle layer. Balance updates can lag behind the hours actually worked. That middle layer is one more system that can fail or miscommunicate data, and when something breaks, the EWA provider may not be able to fix a problem that started with the connector.

Both models get called “integrated.” Ask the specific question: does data flow directly between your system and the provider's platform, or does it pass through something else first?

While you're at it, ask how many active integrations the provider currently maintains. A provider running 300 or more live connections across major payroll and time platforms has already solved the engineering problems you're worried about. A provider with a handful of integrations is a different risk profile, and you should treat it that way.

Question 2: How is the available balance calculated?

When I was still processing payroll, I saw what happens when a number on a screen doesn't match what actually lands in someone's bank account. That mismatch is exactly what's at stake in this question.

The number an employee sees when they open the app is either accurate or it isn't, and that accuracy comes down to whether the provider calculates the balance against actual net pay or against a gross earnings estimate.

Gross-based calculation is common because it's simpler to build. It creates a real problem for employees with meaningful deductions: garnishments, benefits elections, retirement contributions. Picture an employee who earns $800 gross but takes home $580 net. Under a gross-based model at 50%, they can access $400. If $220 of that paycheck is already committed to deductions, accessing $400 puts them behind before the next pay period even starts. I built Tapcheck because I didn't want any employee caught in that math.

Net pay calculation removes that risk because it factors in taxes, benefits, garnishments, and retirement contributions in real time. Because the calculation is accurate, these providers can typically offer access to 70% or more of net pay without over-advancing, and employees with high deductions are protected automatically.

Ask specifically: does the balance calculation account for taxes, benefits, and garnishments? Would two employees who earn the same amount and work the same hours see the same available balance? If the answer to the second question is no, ask what determines the difference.

Question 3: What does it cost, and who pays?

In a well-structured EWA model, the employer pays nothing. No implementation fee, no platform fee, no per-employee-per-month charge. The employee pays a small fee per transfer when they choose to use the benefit, comparable to an ATM withdrawal, and a free transfer option is typically available.

That's the baseline I hold every provider to, including my own. A small number of providers deviate by charging the employer a PEPM fee, a platform subscription, or a minimum volume commitment, and that changes the economics of the benefit considerably. A benefit that costs the organization nothing requires no budget approval and no ongoing justification. A benefit with a monthly fee becomes a line item that has to earn its keep every quarter.

I think about cost in the context of what employees are actually paying when they don't have this option. An overdraft fee averages $35 per incident. A payday loan costs $15 to $30 per $100 borrowed, with APRs that frequently exceed 400%. A $2 to $4 transfer fee to access wages already earned is, for most employees, the lowest-cost option available when they need money before payday. That comparison is the reason I started this company.

Ask for specifics: what is the employee fee per transfer at each available transfer speed? Is there a free option? Is there any cost to the employer, in any form?

Question 4: Who funds the advances, and what happens when someone leaves?

When an employee accesses earned wages before payday, that money comes from somewhere. In provider-funded models, the EWA provider puts up the cash. The employer's accounts stay untouched until the normal payroll run, and if an employee terminates with an outstanding balance, the provider absorbs the exposure. That's the model I built Tapcheck on, because I didn't think employers should carry that risk for offering a benefit that costs them nothing.

In employer-funded models, the employer maintains a prefunded account that advances are drawn from. That introduces cash flow impact, float exposure, and in some cases, balance sheet treatment. The employer may also carry partial recovery risk.

Ask this question directly: do we need to prefund an account? If an employee is terminated with an outstanding balance and the final paycheck doesn't cover it, who absorbs the loss?

Question 5: What does your payroll team actually do differently on each pay run?

This is the question I'd ask first if I were still sitting in a payroll seat. Ask it in exactly those words. Any answer other than “nothing” or “very close to nothing” is worth understanding in detail, because I know from experience that payroll teams absorb the cost of vague answers.

There are four recovery models in the EWA market today, and I've watched each one play out inside a real payroll operation.

Payroll deduction:

the employer processes a deduction on each participating employee's paycheck and remits it to the provider. The deduction is visible on the paystub, which I like, but it adds a processing step to every pay run. Edge cases like garnishments, terminations, and retroactive adjustments may require manual handling, and I know from years of running payroll how much time that adds up to.

Payroll intercept:

the employee's direct deposit gets redirected to a provider-held account. The provider recovers the advance automatically, then releases the remainder to the employee. That's very little manual work for the payroll team, but the paystub's net pay won't match what actually hits the employee's bank account. I've fielded those confused employee calls myself, and they turn into HR tickets fast. The payroll team also loses the flexibility to process reversals or direct deposit changes for enrolled employees.

Bank account settlement:

the employee opens a new account with the provider and updates their direct deposit to that account. Reconciliation happens automatically, but it asks employees to change their banking relationship, which limits adoption and adds friction at enrollment.

Payroll-native:

the deduction is visible on the paystub, direct deposit stays exactly where it is, and no new bank account is required. The recovery process embeds inside the payroll run itself, so the payroll team never processes a separate file, manages an exception queue, or verifies deductions by hand. This model takes deeper integration to build, which is why I don't see every provider offer it. It's the architecture I set out to build because it scales cleanly at enterprise size.

When you're evaluating a provider, ask them to walk through a specific pay run scenario: what happens at termination, what happens when there's a garnishment, and what happens when a timesheet gets updated after an employee has already accessed wages.

Question 6: How does the provider handle situations that aren't in the brochure?

I spent enough years in payroll to know that edge cases aren't occasional at enterprise scale. They're daily operations. Every pay cycle includes some combination of mid-cycle terminations, garnishments, retroactive pay adjustments, late timesheets, and multi-entity payroll routing. How a provider handles these is what determines whether EWA becomes a real benefit to your payroll team or just another thing they have to manage.

Three scenarios worth asking about directly:

When a manager updates an employee's timesheet mid-cycle, does the available balance adjust automatically, or does it wait for the next batch transfer? Providers with real-time integrations adjust continuously. Providers without real-time data only learn about changes when the next file arrives, and by then the employee may have already transferred against hours that were later revised.

For states that require final pay within 24 to 48 hours of termination, does the provider handle the deduction automatically, or does your payroll team have to step in? The answer depends entirely on integration depth. A file-based or connector integration can't support real-time termination deduction inserts, which means your team manages the exception at the worst possible moment.

If you run payroll across multiple entities or EINs, does the provider route deductions to the correct entity automatically, or does the payroll team consolidate manually?

The answer that should concern you most is “we handle those situations on a case-by-case basis.” At enterprise scale, that means your payroll team handles them.

How to Use These Questions

I built Tapcheck to hold up against each six of these questions, because I asked myself these same questions before I ever wrote a business plan. If a provider can't answer clearly, that's the answer.