For most businesses, a payment gateway is something you choose once and rarely think about again. For an independent software vendor, it is the opposite. The gateway you select becomes infrastructure that your product, your merchants, and a real revenue line all sit on top of. Choose well and payments fade into the background while quietly strengthening your platform. Choose poorly and you inherit a problem that is slow, costly, and disruptive to unwind.
This guide is built for ISVs and vertical SaaS companies evaluating a payment gateway for the first time, or reconsidering one they have outgrown. It lays out what actually matters, the criteria that separate a short-term fix from a long-term platform, and a practical way to run the evaluation.
Why gateway selection is different for an ISV
When a single merchant chooses a gateway, they are deciding how to accept their own payments. The stakes end at their own checkout. An ISV is making a different decision entirely. You are choosing the rails that every merchant on your platform will run on.
That changes the math. A gateway that is merely adequate for one business becomes a recurring liability when it sits underneath hundreds or thousands of them. Onboarding friction multiplies. A weak API multiplies. Thin reporting multiplies. So does every advantage. The right platform compounds in your favor as you grow, which is why this decision deserves more rigor than a standard procurement exercise.
For vertical SaaS specifically, payments are also one of the clearest ways to expand revenue per customer without expanding your product surface. That potential only materializes if the underlying gateway is built to support it.
The real cost of choosing wrong
The expense of a poor gateway decision rarely shows up on day one. It accumulates.
The most common version is fragmentation. A platform stitches together one vendor for processing, another for reconciliation, a separate tool for compliance, and yet another for reporting. Each connection carries its own contract, its own API, its own failure modes, and its own maintenance burden. We unpacked this in the hidden cost of fragmented payment integrations in vertical software. Over time, the cost of holding that arrangement together quietly exceeds the cost of the payments themselves.
Fragmentation also widens your compliance scope. Every system that touches cardholder data is something you now have to secure and account for. And when you eventually want to switch or consolidate, the migration is harder precisely because so much is tangled together.
The lesson is not that fragmentation is always avoidable. It is that the cost of a gateway decision should be measured across years and across your entire merchant base, not at the moment you sign.
The evaluation framework
A serious evaluation comes down to a set of criteria that matter far more for an ISV than for an ordinary merchant. Here is what to weigh, and what to ask for before you commit.
Security and compliance
Security is the floor, not a feature. Any gateway you consider should be a PCI DSS Level 1 service provider, the most rigorous level of payment security certification. Look for tokenization, which replaces sensitive card details with secure tokens so raw card data never has to live in your environment. Strong security does more than prevent breaches. It narrows your own compliance scope and removes work from your team. For a deeper look at how the underlying technology works, see our guide to what a payment gateway is and how it works.
Integration and developer experience
This is where ISVs feel the difference daily. A modern gateway should offer clean RESTful APIs, SDKs for the platforms you build on, and documentation thorough enough that your engineers do not have to file support tickets to make progress. Good integration shortens time to value. Poor integration turns every new feature into a custom project. Ask how long a typical integration takes, and ask to see the documentation before you commit, not after.
Payment method and channel coverage
Your merchants accept payments in more than one way, so your gateway has to as well. Confirm support across the channels your customers actually use: online and card present, digital wallets such as Apple Pay and Google Pay, ACH, and recurring billing if your platform involves subscriptions. Coverage gaps become your problem, because your merchants will ask you to fill them.
Reliability and uptime
In payments, downtime is lost revenue, for your merchants and for you. A gateway needs stable infrastructure that holds up during peak activity, not just on an average Tuesday. Ask how the platform performs under load and how it handles failover, and treat reliability as a primary criterion rather than an assumption.
Reporting and data
A modern gateway should give you and your merchants a clear, real-time view of every transaction. Strong reporting reduces support load, surfaces problems early, and gives merchants the visibility they expect from your platform. Fragmented or delayed reporting does the opposite, and it lands on your support team.
Economics and monetization
For an ISV, payments are not only a cost to manage. They can be a revenue stream. Understand the pricing model in full, including how interchange and processing costs are structured, and understand how the gateway lets you participate in payment economics through a revenue share or similar arrangement. A platform built for software partners treats your ability to monetize payments as a core part of the model, not an afterthought.
Merchant onboarding and boarding
Every merchant you bring onto the platform has to be underwritten and boarded. That process can be smooth, or it can be the single biggest source of friction in your payments program. Look closely at how merchants are onboarded, how underwriting works, and how much of the burden falls on you versus the platform. At your scale, small inefficiencies here turn into large ones.
Support and operations
Behind every payments program is a steady stream of operational work: chargebacks, disputes, escalations, compliance changes. A strong gateway partner absorbs this in the background so your team stays focused on your product. Ask who owns these processes and what support actually looks like when something goes wrong at month-end, not just during the sales cycle.
Roadmap and embedded finance
The gateway you choose today should still fit two years from now. Payments are moving toward real-time settlement, smarter fraud prevention, and embedded finance, where software platforms offer financial services directly inside their own products. Ask where the platform is heading, because you are buying its future as much as its present.
Partnership model: vendor or partner
This is the criterion that ties the rest together. A vendor sells you a service and moves on. A partner is structured to grow as you grow and to stay aligned with your interests over time. For an ISV making a decision this consequential, the difference between the two is often worth more than any single feature on the list.
Build, buy, or partner
Behind the criteria sits a larger strategic choice.
Building your own payments infrastructure gives you maximum control and maximum burden. Compliance, processor integrations, underwriting, risk, and support all become yours to solve and maintain. Few software companies have the appetite for that, and fewer still find it worth the investment.
Buying piecemeal, assembling best-of-breed tools yourself, is the fragmentation trap described earlier. It feels flexible at the start and grows heavier with every merchant you add.
Partnering with a platform built to carry that complexity lets you offer payments inside your product without becoming a payments company. For most ISVs and vertical SaaS businesses, this is the path that balances control, speed, and economics. The question then becomes which partner, which is exactly what the framework above is designed to answer.
How to run the evaluation
Turn the framework into a simple scorecard. For each candidate, score the following from one to five, then weight the criteria that matter most to your business:
- PCI DSS Level 1 certification and tokenization
- API quality, SDK coverage, and documentation
- Time to a working integration
- Payment method and channel coverage
- Uptime and performance under load
- Real-time reporting for you and your merchants
- Pricing transparency and revenue opportunity
- Merchant onboarding and underwriting experience
- Operational support for disputes and escalations
- Product roadmap and embedded finance direction
- Whether the relationship is structured as a vendor or a partner
A few habits keep the scoring honest. Read the documentation before signing, not after. Talk to the support team, not only the sales team. Ask for specifics on onboarding and uptime rather than accepting general assurances. And weight the criteria deliberately, because the gateway that wins on a feature you rarely use is not the gateway that should win.
Where Constellation Payments fits
Constellation Payments built CSIPay around a simple idea: software companies want to offer payments without becoming payments companies. Developed to support the needs of Constellation Software operating companies, it is a PCI DSS Level 1 platform serving the US and Canadian markets, designed so partners can integrate once and access processing, compliance, risk controls, and settlement through a single platform rather than a stack of vendors. The aim is straightforward, to let software teams turn payments into a growth driver while the complexity stays out of sight.
If you are working through the evaluation in this guide and want to see how that model applies to your platform, talk to the Constellation Payments team.