Straata: Finding the Payments Revenue Hiding in Plain Sight

An ISV can have a payments program that looks perfectly healthy on paper. Merchants are processing, residuals are arriving, and the revenue line keeps moving up. But that doesn't answer a more important question: is the program actually performing as well as it should?

Straata works with software platforms and other businesses that earn revenue from payments to help answer that question. It's not an ISV selling software to a particular vertical. It's a payments advisory and technology business built to give ISVs the expertise and analytical visibility they often don't have in-house.

On CentsChat, Brian Abernethy described the firm's roots in Utopia, where his team worked on processor selection, commercial negotiations, investor diligence, go-to-market planning, and payments optimization. That consulting work exposed a recurring problem: many software businesses add payments because their customers need to accept money, but never build a dedicated team to manage the economics and operational details behind it.

Straata builds on that experience with a more repeatable, technology-supported model. Its approach connects processor agreements, residual reports, transaction records, and merchant statements so a platform can compare what it contracted for with what's actually happening. The company focuses on five connected areas: commercial terms, residual accuracy, interchange optimization, merchant pricing, and payment product gaps.

The distinction matters. A dashboard can show that revenue increased. It can't, by itself, explain whether the increase came from greater merchant adoption, more payment volume, or higher fees charged to a shrinking merchant base. Straata's work is about putting those numbers in context, identifying practical opportunities, and helping teams decide what to do next.

The Pain Point: Your Residual Report Can Balance and Still Be Wrong

One of the sharper examples from Brian's conversation was a payments program where the reported residual math could tie out perfectly, yet the ISV still wasn't receiving everything its agreement entitled it to. The arithmetic wasn't necessarily the problem. The missing piece was context: the report didn't show every relevant fee, cost, or contractual obligation.

Brian said Straata's early residual reviews had uncovered issues in roughly 40% to 50% of cases examined at that point. That's his firm's experience, not an industry-wide error rate, but it illustrates why treating a processor's monthly payout as self-validating is risky. Some discrepancies can come from straightforward mistakes. Others involve billing systems that no longer line up cleanly with older contracts, especially after acquisitions and platform migrations. If nobody compares the contract's Schedule A with merchant statements and actual transaction data, the differences may continue month after month.

The problem starts even earlier with the contract. Brian challenged the tendency to judge an ISV agreement by its revenue-share percentage alone. A generous-looking split may be worth less than a smaller percentage on a program with stronger adoption, better retention, and viable merchant pricing. Buy rates, exclusivity provisions, minimums, and the ability to support different merchant segments all affect whether the business can grow on those terms.

Interchange adds another layer. Brian and Jason explained why multiplying a large processing volume by a theoretical basis-point reduction isn't a real savings plan. Some interchange costs reflect the customer's choice of card and can't simply be wished away. Other costs may be affected by data quality, qualification rules, or the path a transaction takes through gateways and processors. An optimization is only useful when the underlying technology and merchant workflow can support it.

Even successful cost reductions raise a commercial question: who gets the benefit? For a platform using blended merchant pricing, better interchange qualification may improve its margin. For one using interchange-plus pricing, much of that benefit may pass to merchants. The right answer depends on product maturity, competition, merchant expectations, and whether lower pricing could improve attachment and retention.

Then there's the volume the platform never captures. Brian described software businesses that can see invoices flowing through their systems but don't process all the related payments. A missing accounting integration or mismatch with a customer's day-to-day workflow can leave significant payment activity elsewhere. As Jason put it during the discussion, customers generally care about whether the software does its job, not whether their software vendor has built a more complicated payments operation behind the scenes.

Straata's approach is to start with the evidence: compare contracts and residuals, examine merchant statements and transaction costs, assess attachment and utilization, and identify which gaps can actually be fixed. Brian offered a simple first step for any ISV: take a residual report, pull several merchant statements from the same period, and spot-check whether the amounts match the contract. It won't replace a full audit, but it's a better health check than assuming that money arriving in the bank means the program is working as intended.

The broader lesson is useful even for a company that never hires outside help. Payments revenue is an output. A healthy payments business requires understanding the inputs, the obligations, and the customer workflows that produced it.