CONTEXT
Ascend’s mid-market customers were increasingly requesting support for checks and wires—payment methods still widely used in commercial insurance. While we had basic wire instructions at checkout, everything was handled manually by Ops and didn’t scale. We needed to turn it into a real product experience.
Problem
There was no way for users to track, reconcile, or manage these payments themselves. Ops handled everything through internal tooling. As volumes grew, this created bottlenecks, delayed payouts, and hurt deal velocity with larger clients.
Solution
I led the design and rollout of a dedicated Incoming Payments system. We started with wires—auto-matching based on metadata—and expanded it into a robust reconciliation flow with support for checks, split/partial payments, refund handling, and custom logic for agencies and MGAs.
Impact
The system has now processed millions of dollars and thousands of transactions, with over 85% of wires auto-matching. It reduced Ops workload, unlocked mid-market deals, and introduced reusable components across Ascend’s design system.
Step one: Laying the foundation
By 2022, Ascend supported wire payments for a few customers—but only via static instructions shown at checkout. Everything after that was handled manually by Ops: payments came in, and someone reconciled them offline. As usage scaled, this model became increasingly fragile.
I was asked to turn this workflow into a productized, scalable feature.
After aligning with engineering on the metadata we’d receive, I designed a new wire payments dashboard under the Accounting section. It listed all incoming wires, their status, and relevant metadata.
To support quick action, I introduced a new side drawer component—designed for glanceable context and streamlined interaction. Users could open a payment, search for matching invoices, and reconcile directly from the drawer. Overpayments triggered a refund flow; underpayments weren’t yet supported.
To close gaps in communication, we introduced a daily email to accountants notifying them if there was at least one unreconciled wire payment in the system. If a payment was auto-reconciled, we would instead notify the relevant account manager to confirm successful processing.
We shipped this MVP to a few select customers in a staged rollout, monitored usage via Smartlook, and gathered feedback from internal teams to inform the next phase.
Step Two: Expanding the System
Once the MVP shipped, real-world usage quickly surfaced edge cases and new needs. We gathered feedback through Smartlook recordings, internal Ops conversations, and feedback passed down from customer teams. While the core logic worked for simple one-to-one matches, the system needed to flex in different ways.
ADDING CHECK SUPPORT
We added full check handling and brought internal processes into the customer-facing UI. This marked the transition from Wire Payments to a more inclusive Incoming Payments system.
Partial & UNDERPAYMENTS
We introduced many-to-many matching and partial reconciliation, allowing users to split a payment across invoices—or vice versa. For underpayments, accountants could either create a new checkout link or absorb the difference.
Smarter Refunds
Refunds became more flexible. Users could now enter a return address manually, and issue full refunds even when no invoice existed. We also added a dedicated dashboard to help track and manage refund statuses.
Surfacing more details
We improved clarity by showing line items, memos, and fee breakdowns directly in the transaction drawer—so accountants didn’t need to dig through other views to match payments accurately.
These updates weren’t shipped all at once—they were prioritized based on friction we saw in Smartlook recordings, feedback from our Ops and Support teams, and gaps surfaced by customers in real payment scenarios. Each improvement solved a real pain point and helped us scale the system without overwhelming users.
Engineering handoff
I provided engineers with dev-ready Figma files, clearly annotated edge cases, and lightweight prototypes where needed. We relied on Figma’s dev mode, async Slack conversations, and occasional Zoom calls to clarify logic.
We didn’t follow a formal handoff process—instead, we worked in short, iterative loops. Engineers flagged gaps early, and I addressed them live to keep momentum. Our shared design system and React component library made collaboration smooth and reusable across teams.
Impact
Incoming Payments evolved from a manual, ops-led process into a scalable product feature—now responsible for a significant share of Ascend’s payment volume. By the time I left, the team was still actively expanding its capabilities.
While I don’t have exact metrics, I know the system processed millions of dollars in transactions, with the majority reconciled automatically. Most importantly, it significantly reduced Ops workload—freeing up time and allowing accountants to self-serve on payment tasks that previously required manual support.
Reflection
This project taught me how messy real-world payments can be - and how much hidden logic goes into building infrastructure that seems simple on the surface. It pushed me to design systems, not just screens, and to think ahead about edge cases even when user feedback is vague or non-existant.
If I could do it again, I’d aim to involve actual accountants earlier, rather than relying on indirect feedback via executives and support teams. I’d also invest more in instrumentation—basic metrics like time-to-reconcile or auto-match rate would’ve made prioritization clearer and impact easier to measure.
Lastly, I would’ve liked to run usability tests on multi-invoice selection and refund logic before launch. We caught those usability challenges later—but with more validation upfront, we might have moved faster through phase two.
If I could do it again, I’d aim to involve actual accountants earlier, rather than relying on indirect feedback via executives and support teams. I’d also invest more in instrumentation—basic metrics like time-to-reconcile or auto-match rate would’ve made prioritization clearer and impact easier to measure.
Lastly, I would’ve liked to run usability tests on multi-invoice selection and refund logic before launch. We caught those usability challenges later—but with more validation upfront, we might have moved faster through phase two.
Vytautas Kaleinikas