Ask a software executive what business they are in and you will hear about scheduling, practice management, field service, membership, point of sale. You will rarely hear the word payments. Yet look at where the revenue actually comes from at many of those same companies, and payments is already one of the largest lines on the page. It happened gradually, and in a lot of cases it happened without anyone deciding it should.
This is the quiet shift underway across vertical software. Companies that started out selling workflow tools are becoming, in practical terms, payments companies. Not because they wanted to build processing infrastructure, but because the customers they serve moved money through the product long before anyone thought to own that flow.
Here is what is driving the change, what it actually means to embed payments in software, and how to think about it if your company is somewhere on that path.
Payments used to be someone else’s problem
For most of the last two decades, payments was plumbing. A software vendor picked a processor, completed an integration, and moved on to the work that differentiated the product. If a customer needed to accept a card, the vendor pointed them to a merchant services provider, collected a referral fee if one was on offer, and let the processor handle everything from that point forward.
That arrangement made sense at the time. Building payment infrastructure is expensive, heavily regulated, and far removed from what most software teams are good at. Handing it off was the rational choice.
The cost of that choice was easy to miss. The vendor gave up the merchant relationship, gave up visibility into fees and terms, and gave up most of the economics. When the processor changed pricing, the software company found out at the same time its customers did, often through a support ticket. Payments generated revenue, but it generated that revenue for someone else.
Why that stopped working
Three things changed at roughly the same time.
Customer expectations rose. Business owners now expect to take a payment, see it reconcile, and issue a refund without leaving the software they use to run the day. A checkout flow that bounces to a third party, a separate login for a merchant portal, or a reconciliation report that never quite matches the invoice list are all friction points that customers notice and increasingly refuse to tolerate.
Retention economics became clearer. When payment data, reconciliation history, and billing workflows live inside the software, switching to a competitor is no longer a matter of exporting a customer list. It means re-underwriting, re-training staff, and rebuilding months of transaction history somewhere else. Payments that are truly embedded raise switching costs in a way that feature releases alone rarely do.
The economics of ownership became too large to ignore. A referral fee is a small slice of a small slice. Owning the payment flow means participating in the processing revenue directly, gaining pricing visibility, and deciding how the customer experience works. For a software company with an established merchant base, that difference compounds every month.
Put those together and payments stopped being a back-office obligation. It became a product decision, a retention lever, and a revenue line, all at once.
What embedded actually means
The word embedded gets used loosely, so it is worth being precise. Plugging a payment gateway into a checkout page is an integration. It is useful, but the merchant account, the pricing, the compliance burden, and the support relationship still belong to the processor.
Embedded payments means the software company owns the experience end to end. The merchant signs up inside the product. Underwriting happens as part of onboarding. Transactions, settlement, reporting, and disputes are handled where the customer already works. The customer may never know a separate processor exists, because from their point of view, the software is where payments happen.
Historically, getting there meant becoming a registered payment facilitator: taking on sponsorship, compliance, underwriting, risk, and the operational load that comes with it. That is a multi-year, multi-million-dollar undertaking, and most software companies rightly decided it was not worth it.
The newer model, often called PayFac as a Service, changes the math. The software company gets the benefits of facilitation, meaning ownership of the merchant relationship, a share of the processing economics, and full control of the front-end experience, while a partner carries the regulated and operational work underneath. The vendor integrates once and keeps the customer-facing product entirely its own.
What to look for in a partner
If embedding payments is on the roadmap, the partner decision matters more than the integration. A few things worth weighing:
- Compliance posture. PCI DSS Level 1 should be the baseline, and the partner should be carrying that burden rather than passing it back to you.
- Ask for the uptime commitment in writing. A 99.9% SLA is a reasonable expectation for infrastructure your customers depend on every day.
- Confirm the partner processes in every market where you have customers. For most vertical software companies in North America, that means both the US and Canada.
- Understand how revenue is shared, what is included, and what happens when interchange or network fees change. Transparency here is a signal of how the relationship will run.
- Implementation load. Ask how much engineering time the integration actually takes and who supports the merchant once they are live. The best answers involve one integration and a partner that handles onboarding, support, and disputes behind the scenes.
- Track record. A partner that has already distributed meaningful revenue back to software companies has proven the model works in practice, not just in a pitch deck.
Where to start
Becoming a payments company does not have to mean building one. For most software vendors, the sensible path is to keep the parts of payments that are strategic, meaning the customer relationship, the product experience, and the revenue, and to hand the rest to a partner that already carries the infrastructure, the compliance, and the operational weight.
If your company is part of the Constellation Software ecosystem, CSIPay was built for exactly this shift. Partners integrate once and keep their customer experience entirely their own, while processing, compliance, underwriting, settlement, and disputes run in the background. The platform is PCI DSS Level 1 certified, backed by a 99.9% uptime SLA, covers the US and Canada, and has distributed more than $40M to partners.
To find out how quickly your operating company could go live, reach out at [email protected].