How Each EWA Model Works

If you're reading this, you've probably decided that bringing an earned wage access benefit to your team is a good idea. And for that, I commend you! But the journey does not end there -- in fact, it's just beginning. As you're doing research, you've likely come across several popular providers that each use slightly different models for how they actually deliver earned wages to employees.

Today, we'll be tackling the core difference between each model: four unique models that provide balances to employees in completely different ways, each of which have ramifications for your team.

So let's demystify.

To this point, you might have evaluated earned wage access by looking at cost and adoption. Those are reasonable places to start, but there aren't many differences to be found amongst the various employer-sponsored models. Fees are in the $2-$5 range per transfer, and adoption hovers anywhere from 20-50 percent.

The next reasonable question to ask is how this works, and where does this vendor sit in relation to your payroll?

That question decides whether your payroll team's job changes at all, who ends up handling it if something goes wrong on a Thursday night, and whether your employees ever end up confused about where their money went. Before you're locked in with a vendor, it's worth exploring more deeply.

Here's a look at what changes for payroll under each model on the market, along with a few questions worth asking if you're not sure which one you're currently running.

The four common models, explained

Earned wage access providers tend to fall into one of four setups. Three of them integrate directly with the employer to connect to hours worked and wages earned, and if you're an employer reading this you're not likely to consider a model like settlement (explained below) that shuts you out of the process entirely.

But what are some of the other differences?

Deduction

‍The provider tracks accessed wages on its own, then sends your payroll team a reconciliation file to import each cycle so the deduction can be applied. It keeps payroll nominally in control, but it also means someone on your team is reviewing and reconciling a spreadsheet every pay period. Unfortunately, a manual import is always one mistake away from becoming a headache. This model has advantages when it uses net pay to provide transfer balances but has a small manual work tradeoff.

Intercept

‍The provider redirects your employees' direct deposit to its own account first, deducts whatever was accessed, and forwards what's left to the employee on payday. What often gets missed when employers sign up for this is that it touches everyone, not just the employees using the benefit. All of your paychecks pass through a third party before reaching your workforce. If that vendor runs into an outage or a banking issue, your employees don't get paid on time, and you're stuck fielding distress calls from employees that you can't solve.

There's also a longer-term cost to this model that doesn't show up until an employer tries to leave. Once deposits are rerouted at scale, unwinding that relationship tends to be harder than setting it up in the first place, and employees can find it more difficult to change their own direct deposit settings back.

Settlement

‍Employees are asked to open a new account with the provider, usually a neobank, and move their direct deposit there. The provider then deducts accessed wages from that account once a paycheck is deposited. This isn't really a payroll benefit so much as a deposit account switch with an EWA label on it, and it comes with a failure mode of its own: post-payday debits that can bounce and a repayment cycle to a third-party. Payroll teams have zero insight into how employees are using this benefit and cannot safeguard against overuse.

Payroll-native

‍This is the only earned wage access model that integrates directly with your existing payroll or time and attendance system. Because it's built into payroll, these models can provide accurate transfer balances based on real hours worked, not guesstimates from previous paystubs.

Accessed wages show up as a line-item deduction on the employee's pay stub, similar to a 401(k) contribution. Direct deposit is never touched and your payroll team keeps doing what they've always done. And if an employer needs to unwind the benefit or shut it off for an employee, there's no messy breakup.

Here's what actually changes for payroll

Looking at that table, the pattern is fairly simple. Three of these models ask your payroll team to either do the work themselves or hand control to someone else, and sometimes both. Payroll-native is the one that asks for neither.

Questions worth asking your current vendor

If you're not sure which model you're evaluating (or running) today, fire these off to your point-of-contact and see what they say:

1. Where does my employees' direct deposit go on payday? If it's not going directly to their existing bank account, it's worth finding out whose account it passes through first, what extra work this creates for your employees, and what happens to your employees if that entity runs into trouble.
2. Do employees need to open a new bank account to use this? If so, ask who's on the hook for a failed post-payday debit, and who takes the call when an employee doesn't recognize a withdrawal. Are they troubleshooting, or are you?
3. Does the deduction show up on pay stubs before payday? If it doesn't, your payroll team loses a valuable audit trail and employees have no way to check their own pay until it's too late to ask questions.

Can every model provide net pay accuracy?

The second layer to this, beyond where a vendor sits in the payroll process, is how the vendor arrives at the available balance it provides to an employee. A balance based on net pay, meaning pay that is inclusive of taxes and other obligations, remains the gold standard. It ensures employees are only able to withdraw money based on hours they've actually worked.

But can each model provide net pay balances for employees? Not always.

Tapcheck calculates real net pay because it has access to the real data by virtue of being payroll-native. ExactCalc, Tapcheck's wage engine, reads directly from an employer's actual payroll and timeclock systems to work out net accrued wages, meaning what an employee has genuinely earned after taxes, benefits, and other withholdings. There isn't a prediction step involved, since the same data the payroll run itself relies on is the data ExactCalc is reading from.

Providers that sit outside payroll, like the intercept and settlement models, generally can't do this in the same way since they aren't connected to that data. DailyPay, for example, is the leading intercept-model provider and their own help documentation describes the balance shown to employees as based on a "dynamic proprietary algorithm," not actual net pay.

That "dynamic proprietary algorithm" is really just a code word for estimated. Their balance figures are a forecast built from historical pay patterns rather than a number tied to that period's actual payroll run. Their documentation also notes that new users initially see a balance based on a flat percentage of gross pay, before it's recalculated using estimated net figures.

In practice, that means a payroll-native calculation reflects what someone has actually earned right now, including the current period's tax and deduction load, while an estimated balance is closer to an informed guess based on prior cycles. It can drift when hours, withholding, or deductions shift, and someone eventually has to catch that drift and correct it.

A few answers about Tapcheck

Does Tapcheck calculate net pay or gross pay? Net pay. Because ExactCalc is built directly into an employer's payroll and timeclock systems, it reads the same real-time data the payroll run itself uses, so the amount reflects taxes, benefits, and other withholdings that have already been applied rather than an estimate based on gross earnings.

How is that different from DailyPay's earnings balance? DailyPay's describes its pay balance as "inclusive of net pay," but that's only after an earned wage access transfer has occurred. While their final pay stub includes taxes -- that's not when it matters. It matters if their balance includes taxes and obligations before they begin a transfer, not after. It's a forecast, rather than a hard figure tied to that period's actual payroll run.

Why does this matter for a payroll team specifically? An estimated balance can drift from what someone actually earns whenever hours, withholding, or deductions change mid-period, which leaves payroll to catch and correct the gap later. A real-time calculation tied to the actual payroll run doesn't need that correction, since it was never a guess to begin with.

The bigger point

An EWA vendor that sits outside your payroll system is something you end up managing, one way or another, whether that's reconciling files, monitoring a third party's uptime, or fielding calls about a new bank account. One that's built inside payroll is something you mostly stop thinking about, which is really the whole point of it. EWA that lives outside your payroll system tends to behave like a liability, while EWA that lives inside it behaves more like infrastructure.

For what it's worth, across 300 plus payroll and time and attendance integrations, 99.9 percent of Tapcheck's deductions pass automatically without any action from your team, and the rare exception simply rolls to the next pay cycle. On the risk side, Tapcheck absorbs unrecoverable liability rather than passing it to you, so your balance sheet, and your payroll team's Thursday nights, stay out of it either way.

Bringing an earned wage access benefit to your teams is a huge step in committing to their financial wellness. Just by being here, you're already helping. But if you're evaluating a vendor right now, the three questions above will tell you more than most of what's in a pitch deck, and they're a reasonable place to start.