Guest payment experience
Letting customers pay without logging in
my role
Sole Lead Product Designer
TimeLine
3 months, kickoff to launch
Team
Product Owner, Business Analyst, Tech Lead, and a UX Researcher — with support from the Pru.com, analytics, and compliance teams
Outcome at a glance
Over $400K saved annually
86% Ease of Doing Business score (vs. 75% benchmark)
97% of payments processed with no manual review ·
About a third of phone volume moved to self-service
"You guys are still doing business like it's the 90s."
That was a customer describing how they paid their life insurance premium. If you didn't have an online account — or weren't eligible for one — your only options were a complex phone system or a paper check in the mail. Payments got lost. Due dates got missed. Policies lapsed. Our customers were telling us, loud and clear: just let us give you our money.
The problem
Our payment options hadn't kept up, and it was costing us on both sides — customer trust and operating budget.
Customer pain points
No online account, no digital path. Policyholders without portal access could only pay by phone or by check.
Caregivers were locked out. Family members managing an aging parent's finances had no way through our digital channels — even though 27% of payments were made by someone other than the policyholder.
Login recovery was a dead end. A forgotten password triggered a long security-recovery process. Most people put it off in the moment and never came back — and some policies lapsed as a result.
Business challenge
Phone payments were just 0.6% of our transaction volume — 219,710 of roughly 35 million payments a year — but the second-highest-cost channel in the entire payment system. At $6.69 per call, that's about $1.47 million a year. An online payment cost $0.60 — roughly 11 times cheaper. Every payment we moved off the phone mattered.
Competitors had raised the bar. Direct competitors already let customers pay with a few pieces of basic policy information, no login required. Indirect competitors — ecommerce sites with guest checkout and a wide range of payment options — had reset what "normal" felt like.
Leadership was worried. A poor payment experience was a renewal risk: frustrated customers don't stay.
Our target: deliver a simple payment experience that doesn't require a login, and divert at least a third of phone volume to self-service — at least $400,000 in annual savings.
What we learned
I partnered with a UX researcher to interview 10 customers. A few findings shaped everything that followed:
All 10 preferred paying online over calling or mailing a check.
8 of 10 had a partner or adult child make premium payments for them at some point.
All 10 had forgotten their Prudential login.
When a bill arrived, they either went to a bookmark or searched Google for "Prudential payments" — then double-checked they'd landed on the real Prudential site before entering anything.
I paired this with a competitive analysis:
Direct competitors let customers pay by entering basic policy information, no login.
Indirect competitors — ecommerce guest checkout — had already trained customers to expect fast, low-friction, login-optional payments.
Before designing anything, I mapped several versions of the user flow so we could see the real decision points. Three challenges stood out.
Challenge 1 — Offer a no-login path without cannibalizing accounts
How might we guide customers to discover the no-login payment experience without confusing them with the existing login experience?
Login is still the experience the business wants for customers who have an account — it's more secure and it keeps people engaged with the portal. The risk: a frictionless guest path could quietly kill account sign-ups.
Options we explored
Option 1 — A standalone no-login flow, completely separate from the login path, reached from the bill or Prudential.com.
Option 2 — One landing page that shows both the login and no-login options side by side and lets customers choose.
We went with Option 2. It balances the convenience of guest payment against the goal of still encouraging account holders to log in. Working with the analytics team on likely entry points, we also learned that about 60% of users arrive from a Google search like "Prudential payments" — which told us the front door mattered as much as the flow itself.
My approach
Give the login and no-login options equal visual weight so neither feels like the "lesser" path.
Briefly explain the pros and cons of each so customers pick the one that fits them.
Optimize for SEO to capture that organic search traffic.
Solution: I collaborated with a partner design team (Modenso) to redesign the payment landing page, placing the login and no-login options side by side so customers choose their preferred path.
Outcome
In testing, 90% of users clearly understood there were two ways to pay.
After launch, 60% of traffic arrived through organic search — validating the decision to invest in SEO rather than rely only on emailed or texted links.
Challenge 2 — Verify the right policy without scaring people off
How might we protect customer data without making people drop out mid-flow?
My approach
Ask for only what's necessary.
Ask for information that's easy to find.
Help people locate it.
Solution: We brainstormed three combinations of data that could reliably identify a policy, then reviewed them with the internal team, stakeholders, and compliance. We landed on just two fields — policy number and the insured's last name. Both are unique identifiers, both are easy to find on the monthly bill, and together they keep the ask to the absolute minimum.
Outcome: 97% of users who reached the verification page completed it and moved into the payment flow.
Challenge 3 — Show enough to pay, without exposing sensitive details
How might we display enough information for someone to pay confidently, without revealing critical policy details?
My approach
Show the minimum useful information.
Review the design with compliance throughout.
Solution: We display only what a person needs to make a payment — amount, due date, and default frequency — and nothing more.
Outcome
In usability testing, every participant said the information shown was enough to comfortably go ahead and pay.
After launch, 97% of payments processed automatically, with no manual review.
Impact, in detail
Launched in 3 months, kickoff to production.
Beat our target: over $400,000 in annual savings as of March 2026. (Method: we used guest-payment traffic to estimate call deflection. Each deflected payment saves the gap between a phone payment and an online one — $6.69 − $0.60 = $6.09.)
86% Ease of Doing Business score, against a team benchmark of 75%.
97% of payments completed with no manual intervention.
60% of traffic arrived through organic search — the SEO bet paid off.
Retrospective
Where this goes next
More payment options. Today we support ACH only.
Recurring payments, so customers don't have to track a due date every month — cutting the effort that caused missed payments in the first place.
What I'd do differently
Bring risk and compliance in earlier. We looped them in once the design was ready, then spent real time getting them up to speed on the problem and the solution. Involving them from the exploration phase would have earned buy-in faster and saved a lot of back-and-forth.
Set measurable goals before launch, with the product team. Under time pressure, we didn't plan how we'd track success. After launch I had to circle back with the Product Owner several times to define the outcomes we were after and gather the data to prove the work solved a real business problem. Agreeing on SMART goals up front would have made the impact obvious from day one.
Back to projects