The Green Sheet Online Edition
October 12, 2026 • 26:10:01
Vertical specialization should not limit an ISV's ability to monetize merchants
Integrated software providers (ISVs) exist to make their clients' lives easier. Their software is purpose-built for a specific vertical, and their goal is simple: attract as many businesses as possible that can benefit from their solution. Boutique booking tools for hair salons or tattoo parlors. Specialized veterinary applications for mobile livestock and field payments. Niche plugins designed to enhance major software platforms. Each is built around the particular needs of a narrowly defined customer base.
That specialization is precisely what makes an ISV valuable. But it also creates an interesting challenge. When your addressable market is already narrowly defined, every qualified prospect matters. What happens when the software can support the merchant, but the ISV's payments solution cannot? For ISVs, the challenge is more than attracting merchants within their vertical. It's building a payments strategy capable of accepting the full range of merchants their software was designed to serve.
That may sound obvious. Yet it can easily be overlooked by an ISV focused on pricing, integration and product functionality. The capabilities of the payment provider ultimately define which prospects the ISV can and cannot monetize.
Consider just a few examples:
- Geographic reach: If an ISV's software is available worldwide but its payment provider only supports U.S. merchants, qualified international prospects are excluded before they ever enter the sales funnel.
- Payment methods: Some merchants require BNPL, ACH, EBT or specific debit networks. If the payment provider doesn't support or isn't certified for a required payment method, the ISV may be unable to serve an otherwise ideal merchant.
- Omni-commerce capabilities: Some merchants need a true card-present and card-not-present experience under an omni-commerce environment. A provider requiring multiple MIDs, separate integrations or restricting access to EMV and transaction data may not meet the merchant's needs.
- Cost and checkout functionality: Interchange optimization, surcharging, tokenization and other capabilities can be requirements rather than conveniences. A provider lacking them may make the ISV's solution economically or operationally unattractive to certain merchants.
- Industry and transaction requirements: Certain verticals require specialized transaction types, gateway-to-processor functionality or industry-specific capabilities. Others may include merchants with credit or risk profiles outside a provider's appetite.
Each limitation creates the same result: a prospect that fits the ISV's software but doesn't fit its payment provider.
ISVs should not be quick to cede business they could otherwise support simply because of the limitations of a single processor. Instead, ISVs should carefully consider their payment partners before they integrate.
Once integrated, they should continually test the boundaries of those partners and evaluate which prospects are being lost at the top of the funnel. The reasons should be examined and the lost opportunity quantified. If the potential is meaningful, closing those gaps should be pursued as aggressively as any other road-mapped opportunity.
The impact extends beyond payment revenue.
A merchant that can be fully served may remain on the platform for years, purchase additional products, generate recurring software and payments revenue, and become more difficult to displace. That changes the economics considerably.
If closing a payment gap allows an ISV to acquire 100 additional merchants, the value isn't simply the payment revenue generated this year. It's the lifetime value of those merchants, the incremental EBITDA they create, and ultimately the value that EBITDA may command in a growth investment or exit. Conversely, every qualified merchant turned away because of geography, payment method, risk appetite or technical limitations represents more than a lost transaction. It can represent years of lost revenue and enterprise value.
Ask Mr. Owl
The solution may be a new or additional payments partner, additional internal development, or some bridge solution that closes the gap. This is where the difficulty lies. How is an ISV, even an experienced one, to select the right partner, development path, or solution when payments are critical to its business but not a core competency?
ISVs should prioritize solutions that deliver the greatest incremental reach with the least amount of internal work. For merchants that would otherwise be lost, reach and execution should initially take precedence over optimizing every basis point of margin. Economics can be improved over time. First, serve the merchant.
For an evaluation like this, I recommend the RICE—Reach, Impact, Confidence, Effort—method for determining which payment gaps are worth solving:
- Estimate the Reach or how many additional merchants could a specific solution enable you to serve.
- Identify the Impact or how significantly the solution could improve conversion or merchant acceptance.
- Assess your Confidence that the proposed solution will deliver the expected result.
- Define the Effort of what it will take in development time, resources and ongoing support.
Apply that framework and score the opportunities to serve merchants your payments stack cannot accommodate today.The solution and the opportunity may be more obvious than you think. First, find a way to serve the merchant. Then optimize the economics. 
As founder of Humboldt Merchant Services, co-founder of Eureka Payments, and a former executive for such payments innovators as WePay, a division of JPMorgan Chase, Ken Musante has experience in all aspects of successful ISO building. He currently provides consulting services and expert witness testimony as founder of Napa Payments and Consulting, www.napapaymentsandconsulting.com. Contact him at kenm@napapaymentsandconsulting.com, 707-601-7656 or www.linkedin.com/in/ken-musante-us.
Notice to readers: These are archived articles. Contact information, links and other details may be out of date. We regret any inconvenience.
