Netevia
Designing money movement worth trusting
A deep dive into four flagship flows inside Netevia's B2B payments platform — the AI assistant, bulk payments, two-factor security, and dispute resolution — and the UX decisions that made a complex financial product feel simple and safe.
- Role
- Product Designer (Team)
- Timeline
- March 2022 - June 2024
Context & Problem
Netevia Business is a full B2B payments platform — ACH transfers, P2P, vendor payouts, batch payments, crypto, and digital checks — all shipped to production. That breadth creates real UX risk: every flow has to feel equally trustworthy, and equally easy to recover from when something goes wrong — a failed SMS, a rejected batch, a disputed charge.
This case study zooms into four flows I consider the strongest examples of that thinking in practice.
Flows
Flow 01 — Netevia AI
- Flow 01 — Netevia AI
- Flow 02 — Batch Transfer
- Flow 03 — Security / 2FA
Netevia
Many flows,
one inconsistent experience
Context & Problem
Netevia Business was already a live, trusted payments platform — this wasn't a blank canvas. The work was about introducing new flows and features on top of an existing system: extending it with AI-assisted actions, bulk payments, and stronger dispute handling, without breaking the patterns customers already relied on.
Each addition started broad — what does this feature need to do at the platform level — and only then narrowed down to the specific flow: the exact screens, states, and edge cases that made it feel like a native part of Netevia rather than a bolt-on. This case study walks through that process for four flagship flows: Netevia AI, Batch Transfer, Security/2FA, and Dispute.
Netevia
Key Pain Points
No safety net for AI-initiated actions
Netevia AI could execute real transfers from a chat prompt, but nothing made those actions reversible, confirmable, or auditable — every fast path was one misfire away from breaking trust.
One-at-a-time flows that don't scale
Paying multiple vendors or employees meant repeating the single-recipient transfer flow payment by payment — slow and error-prone the moment a business had more than one payment to make.
Dead ends instead of a way forward
A code that never arrived, a session that expired mid-verification, or a dispute frozen at “Under Review” all read the same way to a user: their money is stuck, with no next step in sight.
User flow
How money moves across
three flagship flows
- Decision (code validity)
- Screen / page
- User action (button / click)
- Confirmation / system state
- Completed / success state
Every flow in this diagram starts from the same place — Payments — because that consistency is the point: whether someone opens Netevia AI, uploads a batch of vendor payments, or gets stopped for a 2FA check, the pattern for confirming, reviewing, and recovering from errors stays the same. Netevia's job doesn't end at initiating a transfer — it ends when the money has actually, safely arrived.
Flow 01 — Netevia AI
AI that acts —
without skipping security
Problem
Users needed a faster way to move money than clicking through multi-step forms — but a chat interface that can execute real transfers is a UX minefield. Every action it takes needs to be reversible, confirmable, and auditable, or trust breaks immediately.
UX approach
- SMS codes get their own dedicated confirmation screen with clear resend and time-remaining affordances, so a slow code is a known wait, not a dead end.
- Failure and expiry states are written and designed as recoverable, not punitive — the retry path is always one tap away, never a redirect back to square one.
- The same 2FA pattern is reused everywhere money moves — manual transfers, AI-initiated ones, batch payments — so trust in the pattern compounds instead of resetting per flow.
Flow 02 — Batch Transfer
Paying twenty vendors
shouldn't take twenty clicks
Problem
Business customers paying multiple vendors, contractors, or employees were forced through the single-recipient transfer flow one payment at a time — slow, error-prone, and painful at any real scale.
Netevia System
A second factor
that never dead-ends
Problem
Shown at mobile width — all five states fit in one row for easy comparison.
Two-factor authentication is where good products lose users — a code that doesn't arrive, a session that expires while waiting, or a plain error message with no way forward all read as "your money is stuck."
Making ‘where's my money’
A timeline, not a mystery
Context & Problem
A disputed charge is one of the more anxiety-inducing moments in a business owner's day — money is frozen, the reason was filed by someone else, and the real question ("what happens now?") has historically lived behind a single static label like "Under Review." The dispute list already tracked status (Open / Under Review / Resolved / Rejected), but a flat table row didn't answer the two things a merchant actually needs day to day: which disputes need attention right now, and exactly where each one sits in its lifecycle.
- Status-first triage, not a flat list.
- Filters shaped by how disputes get chased down.
- A status pill backed by a real, timestamped timeline.
Visual construction
- Status-first triage: four counts — Open, Under Review, Resolved, Rejected — sit above the list, so the whole dispute queue reads in one glance instead of row-by-row scanning.
- Filtering built around how disputes actually get chased down — a created-date range, a specific financial account, dispute status — plus a persistent card-last-4 search for when the transaction is already in hand.
- The status pill is backed by a real, timestamped timeline — initiated, submitted, resolved or rejected — so the view answers not just what's true right now, but how the case got there.
- The same detail content works as a slide-in side panel on desktop, so the list stays visible behind it, and as a dedicated full-screen view on mobile, where a split panel doesn't fit — one flow, two contexts.
Netevia
By the end,
What Changed
Guardrails built into every AI action
Every transfer Netevia AI initiates is now confirmable and reversible before it executes, and auditable after — speed without losing the checks a real transfer needs.
Batch payments in one flow, not many
Multiple vendors, contractors, or employees can now be paid in a single guided flow instead of repeating the single-recipient process payment by payment.
A way forward at every failure point
A missed SMS code falls back to an authenticator instead of a dead end, and a disputed charge now shows a live, timestamped timeline — so “stuck” became “here's what happens next.”
Lessons
What this project
taught me beyond this one flow
Acting AI needs a
different safety modelNetevia AI could execute real transfers from a prompt, which meant every response needed to be reversible, confirmable, and auditable before anything else — speed was never the hard part. Any interface that lets a model take a real action, not just answer a question, inherits this: the safety model for chat that acts is not the safety model for chat that answers.
A single channel is a
single point of failureSMS-based 2FA works until the SMS doesn't arrive, and when it doesn't, the product's only real feature becomes “wait and hope” unless a fallback was designed in from the start. The same is true of any flow that depends on one delivery channel for something time-sensitive — email verification, webhook confirmations, push notifications. Designing the failure path is designing the feature, not handling an edge case.
A status label is
not a status“Under Review” told a merchant what was true but nothing about how they got there or what happens next — replacing it with a timestamped timeline cut the “so what do I do now” support load. Any process with a single-word state — pending, processing, in review — is a candidate for the same fix: a label is a snapshot, but people are usually asking about a trajectory.
eWallet
