What ISVs are really asking for: Modern payment platforms, SDKs & developer experience

Across industries and stages of growth, I keep hearing the same priorities from software companies.

‍

On the first day of RetailNOW 2026, I asked a question I’ve kept coming back to since:

What's the essence of what Verifone does?

"Sell PIN pads,” someone offered. “Process transactions,” said another.

Close. But those are the mechanisms, not the point.

We move money. We make commerce possible. When payment software stops working, we don't simply have a support ticket. Somewhere, a business has stopped taking orders, serving customers, or getting paid.

That distinction matters because I spend most weeks talking with the people building the software behind those businesses: first-time founders, ISV veterans, and everything in between.

Some are developing payment applications from scratch. Others have built deeply specialized platforms for scheduling, inventory, payroll, loyalty or restaurant operations, with payments as one function among many.

I recently spoke with an ISV that builds scheduling software for garage door installers. Payments are included because, as they put it, “Somebody's got to get paid for the garage door."

The industries vary. So do the use cases. But the priorities I hear are remarkably consistent.

1. More time to build what makes their software different

For a lot of the ISVs I talk to, payments were never the point.

Payments are one spoke in a much larger solution wheel. An essential one — nobody forgives a failed transaction — but still one part of the experience their customers rely on.

One salon software company explained its real complexity to me using shampoo. A salon doesn't stock cases of 25 bottles like a big-box retailer. It may keep 12 bottles on the shelf and want the system to reorder automatically once six have sold.

That's the work that makes its platform valuable: inventory logic, appointment scheduling, payroll, and loyalty.

The best teams want to spend as little time managing payments as possible. Not because payments do not matter, but because every hour spent there is an hour not spent on what makes their product distinctly theirs.

2. A clear path from hello to production

One phrase I come back to a lot is "hello to production — and beyond."

A successful partnership starts long before the first line of code is written.

It starts with understanding how an ISV wants to build. Is the application cloud-based, on-device or hybrid? Does it support countertop, mobile or unattended experiences? What payment methods do merchants need today, and what might they need a year from now?

Once those questions are answered, developers need the right tools to move confidently: clear documentation, practical SDKs, sample code, responsive technical support and, increasingly, AI-assisted guidance that helps answer questions in real time.

Technology matters. But I've found successful integrations rarely happen because of technology alone. They happen when people, process and technology work together.

Getting an application into production is only the beginning. The real partnership starts after launch, as merchants grow, software evolves and new capabilities are added over time.

3. One application across every customer experience

Even relatively small merchants rarely have a single payment experience anymore.

Take a neighborhood pizza shop. It may have countertop checkout, handhelds for tableside service, online ordering and delivery — all within the same business.

From an ISV's perspective, that's one customer. It shouldn't require four different applications.

What I hear consistently is a desire to build once and deploy everywhere. That requires more than a common SDK. It requires hardware powerful enough to support the rich applications ISVs are building today.

That's why processing power matters. Modern payment applications are expected to run payments alongside loyalty, inventory, ordering and other business-critical workflows. Octa-core processing gives ISVs the headroom to build those richer experiences without compromising performance. That’s the thinking behind the Victa portfolio.

4. A foundation that grows with the business

Software never stands still. Every successful ISV I’ve worked with has reinvented its product more than once.

Merchants add locations. Consumer expectations change. New payment methods appear. Businesses expand into new markets.

ISVs need technology that can evolve alongside those changes — not force them to start over.

That means hardware designed for longevity, development tools that continue to evolve and a platform flexible enough to support whatever comes next.

The goal isn't simply to meet today's requirements. It's to give software companies confidence that the decisions they make today won't limit what they can build tomorrow.

5. AI gives developers back their time

AI is already changing how software gets built.

I've watched developers describe an application in plain English and generate working code in minutes. I've seen engineers ask technical questions conversationally instead of digging through documentation or waiting for support.

It's not perfect, and it's improving every day.

The real opportunity isn't replacing developers. It's removing the repetitive work that slows them down so they can spend more time solving customer problems and less time searching for answers.

The part that doesn't show up on any roadmap

After years of working with ISVs, that’s how I think about our role.

It isn’t selling hardware or processing transactions.

Helping software companies move from hello to production — and beyond.

Because the most successful ISVs aren't looking for another payment terminal.

They're looking for a partner that helps them spend less time thinking about payments, and more time building the software that makes their business different.

If you’re building the next generation of commerce software, I’d love to continue the conversation. Talk to Verifone's ISV team about what "build once, deploy everywhere" could look like for your platform.