Unlocking financial success
Cash flow, unstuck: the product decision behind a 30% jump in payment method capture
Notch Financial had automation in place, but suppliers were still getting paid late. The issue was not usability or feature coverage. It was a product decision that allowed customers to avoid providing payment information.
Watch the full walkthrough
Who I Am
I led product design for Notch Financial’s customer portal, and the job was never really about the interface. It was about a decision buried inside the product that nobody had gone back to question: customers could access their invoices without ever committing to pay.
I’m drawn to problems shaped like this one, where the real fix isn’t a new feature but a rule the product has been quietly enforcing (or not enforcing) all along. My job was to find that rule, make the case for changing it, and carry the change through design, engineering, and go-to-market without adding friction the business couldn’t afford.
The goal was never to ship a portal. It was to make getting paid predictable.
Challenge
The Real Constraint
Notch Financial is an AP and AR automation platform used by suppliers to invoice and collect payments from their customers.
On paper, the system worked. Invoices were sent on time. Reminders were automated. Payments could be processed digitally.
In reality, cash flow was unpredictable.
Most suppliers did not have credit card or banking information on file for their customers. That meant payments depended on follow ups, checks, and manual workarounds. Automation existed, but it could not be enforced.
Late payments were not caused by broken flows or missing features. They were caused by a decision the product allowed. Customers could access invoices without committing a payment method.
As long as that remained true, suppliers would continue to chase payments instead of collecting them.
This was not an execution problem.
It was a decision problem.
Solution
Research & Discovery
We interviewed suppliers and reviewed support tickets to understand why payments were consistently late despite automation being in place. Three patterns pointed to the same gap: customers could access the product without ever committing to pay. There was no gate, no incentive, no capture.
Most customers had only ever paid by check, so suppliers had no digital payment method on file to charge even when they wanted to enforce one. Automation handled invoicing, but nothing on the product side enforced commitment from the customer.
The fix wasn’t a new feature. It was a product access decision: customers could no longer view their invoices without first registering a payment method. Automation already existed; we just needed to close the gap that let customers opt out of it.
The Solution: Customer Portal
We designed a white-labeled customer portal that suppliers could send to customers via a branded invite. The key constraint: customers had to register a payment method before they could access their invoices. Every feature in the portal was built around that single decision. Open prototype →
Suppliers trigger a branded invite from their dashboard, so customers land in a controlled onboarding flow rather than a raw product signup. The welcome email frames registration as access to their invoices rather than a payment request, lowering the barrier before the constraint hits.
From there, customers land on a registration page where adding a payment method is required to continue. A modal blocks invoice access until a card is on file, with no workarounds and no partial access. Customers managing multiple suppliers can store and organize every payment method in a shared wallet, reducing friction on the second and third capture. Once a method is on file, suppliers can enable autopay with a single toggle, turning a one-time setup into a standing collection mechanism.
Shipping it meant more than a design handoff. The invite, the welcome email, and the registration page all had to enforce the same rule, or the constraint would have had a side door for customers to slip through. I worked across product, engineering, and go-to-market to land it consistently everywhere at once, and made sure support and customer success had the reasoning and a response ready before launch, so the added friction read as a clear rule rather than a surprise.
Results
From Chaos to Cash Flow
Payment method capture increased by 30% following the portal launch. Suppliers saw a 25% improvement in cash flow predictability, with fewer outstanding invoices and fewer manual follow-ups. Switching payment infrastructure from Stripe to Adyen during the same cycle reduced transaction costs by 10-20%, compounding the financial impact.
If I ran this again, I’d put a support-ticket and complaint metric in place before launch, not after. A constraint that adds friction on purpose needs a counter-metric from day one. Otherwise you can’t tell whether you removed a problem or just moved it somewhere else.
What I Learned
The most impactful fix wasn’t a new feature · it was changing who controlled the condition for access. Automation without commitment is incomplete. Once we closed the loop on payment method capture, the automation Notch had already built could actually do its job.
It’s the pattern I keep finding in this kind of work: automation and new features get most of the attention, but the highest-leverage fix is usually a decision nobody has revisited. I’m most useful on problems like that, where connecting a product rule to the metric it’s actually driving matters more than adding something new.