Joshua Jung

From paper checks to instant payments.

Chase was losing real money on paper checks. We found a way to move those payments to Zelle, instantly.

Client
JPMorgan Chase2025
Role
Product Designer
Team
Banking PaymentsBill Pay · Zelle
Platform
Web + MobileiOS + Android
Impact
$1.2M/moProjected savings

Paper checks were quietly bleeding money.

Every month, Chase mails out around 4 million paper checks. The data made it clear that most of those recipients were already on Zelle.

~$2M/mo
operational cost of paper checks
$300K/mo
lost to checks stolen in transit
Instant
payment delivery, down from 5 days
2.2M+
Business Banking recipients already on Zelle

Bill Pay and Zelle run on separate back-end systems.

Bill Pay and Zelle don't just store data differently, they run on entirely separate third-party back-end systems. The Zelle team uses one to track recipients, and Bill Pay uses a different one to manage payee details. Plugging them together directly was never going to happen.

So we worked around it. We focused on a specific group of billing companies: the ones that get paid by paper check today but also accept Zelle. If a company was already set up to receive Zelle, we could quietly route the customer there instead of cutting a check.

Chase Pay Bills and send money with Zelle screen
Bill Pay recipient: CREDIT CARD ending 1234

Bill Pay speaks in account numbers and payee addresses. A payee here is a biller and account number, like CREDIT CARD (…1234).

Zelle recipient: Amber Davis, adavis@gmail.com

Zelle speaks in emails and phone numbers. A recipient here is a person, like adavis@gmail.com.

I mapped the logic before designing a single screen.

Before I touched a screen, we mapped the logic behind each concept: where Bill Pay and Zelle actually connect, what data we could pull, where the eligibility checks would live, and what the system needed to do at every step. Those maps became our anchor for syncs.

I made sure we weren't designing in a vacuum. From day one we looped in data, engineering from both sides, ADA, and legal. Data showed us what we could collect. Engineers told us what the systems could handle. ADA caught accessibility gaps early. Legal weighed in on whether moving customers between products mid-flow raised any flags, and reviewed our marketing copy to make sure nothing overpromised or could mislead a customer.

Logic map across add a payee, make a payment, and post-payment
Logic map: add a payee, make a payment, post-payment. Click to view full size.

Bill Pay thinks in account numbers and addresses. Zelle thinks in emails and phone numbers. The hard part was bridging two systems that were never built to talk.

Start with what ships.
Build toward the north star.

Capture value immediately with Phase 1, prove the system works with Phase 2, then remove the last bit of friction in Phase 3.

Phase 01Low lift
Awareness & Redirect
Surface Zelle alongside the existing flow, with no changes to Bill Pay UI, at the end of the add-a-payee flow.
Phase 02Medium lift
Smart Routing
A real-time eligibility check positions Zelle as preferred, with Bill Pay details pre-imported. Failures route safely back to paper check.
Phase 03Future state
Seamless Payment
Eligible customers skip the add-recipient step and land directly in the Zelle flow, fully pre-populated.

Try the eligibility check yourself.

Toggle between Delivered, the Phase 2 design that shipped, and Proposed, the original full concept. Run the check live with an email or phone number.

The decisions behind the design.

01
Upsell Zelle, but always preserve the exit.

The goal was to move people from Bill Pay to Zelle, but I never wanted it to feel pushy. Every touchpoint sells the value of Zelle while keeping an easy path back. As a team, we agreed early this should be about persuasion, not pressure.

02
Get legal in early, not late.

Instead of designing first and getting our copy shot down later, we brought legal in from the start to set guardrails on messaging. We landed on phrasing like "your money typically arrives in moments," language that felt persuasive and still passed legal.

03
Bridge the data gap transparently.

Bill Pay and Zelle identify people differently, so we showed both sets of details and let customers confirm the match themselves. It felt more honest than asking them to trust a recommendation they couldn't see into.

04
We earned trust one phase at a time.

Each phase builds on the one before it. Phase 1 plants the idea, Phase 2 proves the system works, and Phase 3 removes the last bit of friction, letting eligible customers skip the add-recipient step and land directly in a fully pre-populated Zelle flow. By handling the work progressively, we earned trust from our partners at every step.

Currently in phased rollout.

2.2M+
Business Banking recipients already on Zelle
1.8M+
Commercial Banking recipients already on Zelle
$1.2M/mo
in projected savings

Reflection

Honestly, the hardest part was getting everyone bought into the logic maps. Aligning that many teams early isn't easy, especially on a tight timeline. But looking back, it was the most valuable thing we did. Having data, engineering, ADA, and legal all reviewing the same maps up front meant we caught the big problems before they turned into expensive rework.

The functional redirect works. The next step is making the transition feel like an upgrade.

With the timeline we had, a lot of the work was balancing what we could ship now against the long-term vision. If I had more time, I'd push harder on the UI-enhanced version, the one that feels like a real upgrade moment instead of just quietly moving someone between products.