Share
In this Article
Share
For years, OnePay offered two leading apps on two stacks: OnePay and ONE@Work.
ONE@Work counts leading employers as our customers and is an app that empowers their employees with financial wellness tools to take control of their pay: get paid early, track earnings, and save automatically. OnePay is an app that is used by millions to manage every aspect of their financial life.
The overlap between the two apps kept growing. Many employees of our customers kept choosing OnePay as the destination for their earned wages. Two great apps. Two different doors. Common customer base.
This week, we made a giant leap towards our vision of creating one place to money. We are thrilled to introduce the all-new OnePay @Work product to our employer partners and their employees, all by offering unique, employer specific benefits in the OnePay app.
Why a single app
Our vision has always been to create "one place to money." That's hard to deliver across two separate apps. Bringing Earned Wage Access into the OnePay app means employees of eligible customers can seamlessly move from viewing earnings, to taking an Instapay, to immediately putting that money to work, whether that’s building savings, paying a bill, avoiding overdraft, sending money to family, or building their credit with the OnePay Builder Card. All without switching apps, re-authenticating, or rebuilding context. One identity, one cohesive experience.This capability is meaningfully different than almost every other Earned Wage Access provider in the market. For most, employees leveraging an EWA tool meant multiple transfers in order to get their paycheck to a financial destination where they could manage their money holistically. OnePay is among the first in the market to provide employer integrated EWA directly alongside a full suite of other financial wellness tools - like a banking product that helps you build credit - that employees can opt into.
Principles that guided the migration
A few non-negotiables shaped every decision we made along the way:
Same great features, better experience. We preserved the functionality customers depend on, while lifting every screen into OnePay's design system. The result is an experience that doesn't just look better — it feels better and more intuitive to use.
Architecture built for what's next. A migration is a rare chance to improve the foundation. We designed for scale given that we support some of the largest and most dynamic workforces in the country and for the next set of products the team will ship, not just for the features in front of us.
Continuity first. Our employer partners and their employees shouldn't notice the seams. Every choice, from copy to routing to how we move a user between apps, was made to keep the experience as uninterrupted as possible.
Employee choice for where they direct their earned wages remains a core product principle. While some early wage access apps require employees to move their direct deposit in order to access earned wages, we believe financial wellness should come with flexibility and choice. While a growing number of OnePay @Work users choose to make OnePay their instapay destination, that decision will always remain in the hands of the employee.
Architecture: unifying two systems into one experience
The two apps were built on different foundations, and both needed to run in parallel during the transition. That meant we had to power the new in-app experience without disrupting the legacy experience in order to migrate users safely.
We weighed two approaches:
Let the frontend integrate directly with multiple backend systems.
Introduce a dedicated service layer that unifies how the frontend talks to them.
The direct approach was simpler on day one. But it meant missing an opportunity to unify our observability and operations, which would have increasingly made maintenance of two systems harder. The service layer added an acceptable amount of overhead upfront in exchange for a single, standardized interface.
We chose the service layer, and we saw the impact almost immediately. Once the first set of features was live, the new layer surfaced inefficiencies in the request flow that had been invisible before: unnecessary dependencies stretching out response times. We cut them. Both the new experience and the legacy app got faster as a result.
Execution details that shaped the migration
Once the architecture was settled, the real work started: a long series of decisions across design, tooling, support, AI, and data that ultimately determined what the experience felt like. The ones below were the most consequential.
Design: Migrating screens was never a copy-and-paste job. The OnePay design system enforces different UX patterns and interaction models, and a lot of legacy flows simply didn't translate. Rather than retrofit old designs into the new system, we reworked the flows that mattered. We simplified where we could, and rebuilt anything that no longer fit. Some of the most complex legacy interactions were broken apart and put back together in a way that felt native to OnePay.
AI: AI was a force multiplier at every phase. We used it to write a scripting solution that converted ONE@Work's GraphQL backend into typesafe REST endpoints, which got us to a working foundation in days instead of weeks. It sped up UI development by letting us iterate on screens faster. And it let us expand test coverage in step with development, so we kept moving without trading away confidence, critical at this scale.
Integrations: A single app meant a single platform behind it. ONE@Work and OnePay often used the same third-party vendors, but in separate instances. Each with its own configuration, data, and workflows. Merging them was a project in itself.
Customer communications demanded a highly coordinated process. Every message needed to be recreated and retested inside OnePay, bringing engineering, product, and marketing into close collaboration. To keep risk low, we rolled the migration out gradually, starting with a small percentage of users and ramping from there. That required us to solve routing for everything from user traffic to comms, so each customer got the right end-to-end experience based on exactly where they were in the transition.
Support: Supporting millions of users through a migration meant further scaling OnePay support for employees of our customers. We expanded tooling, training, and internal routing so support teams could quickly understand where a user came from, what experience they were in, and how to guide them effectively through the transition and beyond.
Data: One of the hardest problems was correctly identifying users who existed in both systems. We worked closely with our fraud team to build a matching approach that prioritized accuracy above all else. When confidence wasn’t high enough to safely associate two accounts, we left them unlinked and escalated the user through an identity verification step instead.
Reducing Complexity: Migrations spiral when you try to support every possible user state, parallel flow, and backwards-compatibility path. We pushed hard in the other direction: cut user states wherever we could justify it.
The highest-leverage move was enforcing a minimum app version on the legacy ONE@Work app. Forced upgrades aren't something we reach for lightly, but supporting older versions would have meant maintaining additional migration paths indefinitely. Requiring users to upgrade to a version that supported the new flow collapsed the matrix of states we had to handle, and made testing and rollout dramatically simpler and more accurate.
Closing
Migrations at this scale are rarely about rewriting code. They're about carefully untangling years of decisions without disrupting the people who rely on your product every day.
We were deliberate about the architecture, pragmatic about the tradeoffs, and disciplined about reducing complexity wherever we could. That's how we shipped quickly without compromising the experience. It’s how we approach product and engineering at OnePay more broadly: deliberate, pragmatic, and centered on the customer.
And for employers and platforms, this transition represents something bigger than a technical migration. It marks the evolution from a single-point EWA solution into a holistic financial wellness platform built for their workforces, bringing together liquidity, savings, credit building, rewards, and more into one unified experience.
One app. One place to money. OnePay@Work, finally home.