What´s the differences between ISVs and ISOs in payment processing?

• ISOs focus on selling, onboarding, and supporting merchant accounts; ISVs focus on software, integrations, and in-app payment experiences.

• ISO revenue comes mainly from transaction fees and residuals; ISV revenue comes from software subscriptions plus integrated payment share.

• ISOs manage risk and underwriting; ISVs manage software, APIs, and technical workflows.

• The lines are blurring as ISVs add payments and ISOs add software-like layers.

• Orchestration platforms help both models connect devices, acquirers, and workflows without lock-in.

Don't have time to read more now? Sign up to our newsletter to get the latest insights directly in your inbox. 

If you work in payments, you’ve probably heard ISVs and ISOs mentioned as if they overlap, and sometimes they do. With software, onboarding, and payment services blending together, it’s understandable that the differences can feel blurred. But the two models were built for very different roles in the ecosystem...

...and merchants feel those differences every day, so much so, they often wonder: 

• Is it the ISO who handles pricing, onboarding, and ongoing payment support?
• Is it the ISV whose software they use to run their business and take payments inside the app or POS?
• Is it the ISO managing compliance checks and merchant setup?
• Is it the ISV controlling the features, software workflow, and overall user experience?

This article breaks down what each role actually does, how they differ, how they’re evolving, and how orchestration helps both models work together more smoothly.

Before diving deeper into each role, it helps to look at ISVs and ISOs side-by-side. This comparison shows how they differ across function, revenue, technical depth, and compliance, and why those differences matter in day-to-day payment operations...

In short:

• ISOs own merchant acquisition and services.
• ISVs own software experiences and embedded payments.
• Both rely on payment partners to move funds.

So, let’s break this down even further...

An ISO is a reseller that gives merchants access to payment processing without dealing directly with an acquiring bank. Their core focus is merchant services, i.e. the commercial, operational, and support side of payments.

In pure form, this is different from a PSP (Payment Service Provider), which manages the technical side of payments - authorizing transactions, settling funds, and maintaining the processing infrastructure.

However, in practice the boundaries can overlap. Some ISOs operate gateways or provide semi-technical services, and some PSPs also sell commercially like ISOs, bundling onboarding, pricing, or support into their offering. The key difference is still the primary role each model was built for: ISOs focus on merchant services; PSPs focus on transaction processing.

In practice, an ISO typically:

• Sells payment processing plans and acts as the merchant’s commercial point of contact.
• Collects KYC/AML documents, pre-screens merchants, and guides them through the onboarding process (while the acquirer performs the final underwriting and approval).
• Provides terminals, device setup, or gateway configuration depending on the solution offered.
• Offers first-line support for disputes, chargebacks, settlement questions, and day-to-day payment issues.
• Guides merchants on PCI basics and risk controls, helping them understand what’s required for compliance even though the acquirer owns the regulatory approval.

ISOs work across many different types of businesses, from small cafés to fast-growing ecommerce merchants. For example, a café might meet an ISO rep who brings hardware, sets pricing, and becomes the go-to support contact. A fast-scaling online retailer, on the other hand, might work with an ISO to get gateway access, fraud tools, and chargeback workflows set up quickly.

In short, ISOs stay close to merchants, handling day-to-day payment needs so businesses can keep trading with confidence.

An ISV builds software that businesses rely on, often point-of-sale systems, booking platforms, retail tools, or industry-specific SaaS. Payments are embedded inside the software experience so merchants don’t have to switch systems or re-enter data.

Examples include:

• A hospitality platform that takes table orders and processes card payments
• A fitness app that handles class bookings and recurring billing
• A retail POS system that integrates inventory, staff tools, and payments

ISVs think ‘software first’, then layer payments inside it. They typically work with acquirers, PayFacs, or processor partners while they handle the application logic, integrations, APIs, and user experience.

Their relationships are long-term, as merchants keep using the software daily, so the payment experience becomes part of the product’s value.

(As ISVs take on more ownership of the payment experience, questions about revenue, control, and scale become more important. We break down these trends in our whitepaper on how ISVs can monetize and expand their role in in-person payments).

The truth is, merchant expectations have changed. Where they once wanted simple card acceptance and basic support, they now expect something much more unified. Today, merchants look for:

• Less fragmentation - fewer vendors, fewer portals, and fewer conflicting systems.
• Unified support - one experience that blends software, payments, and support without hand-offs.
• Flexibility - the ability to add new payment methods, switch acquirers, or change devices without disruption.
• Cleaner data - a single view across devices, transactions, and acquirers to simplify reconciliation and decision-making.

Is there a way to ‘de-blur’ these lines?

Yes, through payment orchestration. That’s because it helps bring clarity. By separating acceptance at the device (POS, SmartPOS, SoftPOS) from processing at the backend, orchestration allows providers to mix and match acquirers, support different device types, add local payment methods, and unify data across every endpoint.

The result is simpler, more flexible payments, and a modern alternative to the old “one gateway, one processor” setup. It also makes the ISV/ISO hybrid model far easier to deploy and scale.

There’s no "one size fits all" here. ISOs, ISVs, and hybrid setups each deliver value in different ways, and the right choice depends on whether you’re prioritizing commercial scale, software experience, technical control, or a blend of all three. The clearer you are on your goals, the easier it is to pick a model that supports them. In the meantime, this might help...

Choose a hybrid if you want:

• Both software + payments economics
• Custom onboarding
• Integrated experiences across devices
• More control over routing, methods, and partners

And as always, orchestration strengthens any of these choices, because it removes lock-in and lets providers evolve as their business grows.

As software-led payments continue to grow, the line between ISVs and ISOs is becoming far less defined. ISVs are taking on more payment responsibilities, ISOs are adding software layers, and hybrid models are emerging as merchants push for fewer vendors and more unified experiences.

What really matters is choosing the model that fits your strategy:

• Need fast onboarding and operational support? ISO strengths align.
• Need integrated workflows and a product-led experience? ISV models fit better.
• Need both? Hybrid setups give you more flexibility and more control.

And with payment orchestration standardizing devices, acquirers, data, and connectors, providers can move between these models more easily (without adding complexity or locking themselves into a single path).

In short, ISVs and ISOs are evolving toward the same destination. The right choice is the one that supports your product and gives merchants the consistent experience they expect.

Ready to explore how in-person payment orchestration can support your ISO, ISV, or hybrid model? 

Let’s talk about what orchestration could look like across your merchant network, and how it can help you scale with less complexity and more control.