Your Software Already Runs the Business. Why Doesn't It Control the Payments?

There is something strange about a lot of B2B payment workflows.

The software knows almost everything about the transaction before money moves.

The ERP knows the invoice. The procurement system knows the supplier. Accounts payable knows who approved it. The platform may know the purchase order, the cost center, the spending limit, the due date, and the accounting treatment.

Then somebody leaves the system, opens a banking portal, finds the payment again, and manually finishes the job.

That separation has survived for a long time because payments and business software grew up as different systems with different owners, different credentials, and different infrastructure.

But the line between them keeps getting thinner.

On October 1, Mastercard and BMO announced a new embedded commercial payments capability that allows eligible BMO Corporate Card clients in Canada and the United States to initiate and manage virtual card payments directly inside participating enterprise software platforms. Mastercard says the capability is designed for ERP, procurement, accounts-payable, and travel-management systems and uses its Commercial Express framework to help platforms enable issuer-backed virtual card payments.

The announcement is interesting because it is not really about adding another payment method.

It is about moving payment execution into the software where the business decision already happens.

For ISVs, that could be a much bigger shift.

The Payment Is Usually the Last Disconnected Step

Software has spent years absorbing business workflows.

A modern platform might manage purchasing, approvals, inventory, scheduling, vendor data, expense policies, invoices, projects, payroll inputs, and reporting. Businesses increasingly expect those systems to become the operational source of truth.

Payments often remain one of the last disconnected steps.

The workflow can approve an invoice, but a user still has to log into a bank portal.

The procurement system can select the vendor, but payment instructions may be maintained somewhere else.

The AP platform can know exactly what should be paid, yet finance may still export a file, upload a batch, or manually create a payment through another interface.

That creates friction, but the bigger problem is context loss.

Every handoff creates another opportunity for data to be re-entered, changed, mismatched, or lost. The approval may live in one system. The payment status lives in another. The reconciliation data comes back later in a file. Support has to figure out which system is telling the truth.

The payment worked.

The workflow did not.

Embedded commercial payments are interesting because they attack the handoff rather than simply making the rail faster.

Virtual Cards Fit the Workflow Better Than They Look on Paper

Virtual cards are not new.

What is changing is how directly they can be created and managed inside business software.

Mastercard and BMO say their new capability lets eligible clients initiate, approve, and reconcile commercial virtual card transactions inside participating platform interfaces. They also highlight spending controls and automated reconciliation data as part of the model.

That matters because a virtual card can be more than a different credential for the same payment.

It can be generated around a specific business event.

A platform can know the approved amount. It can know the supplier. It can know whether the payment should be one-time or recurring. It can know what invoice the payment belongs to and what accounting data should travel with it.

In other words, the payment can inherit context from the workflow instead of asking the user to recreate that context somewhere else.

That is the part ISVs should pay attention to.

The real product opportunity is not "we added virtual cards."

It is "the payment now understands why it exists."

The Software Becomes More Important to the Financial Relationship

Once payment execution moves into the application, the software platform becomes more central to the customer's financial workflow.

That can be strategically valuable.

The platform is no longer only where a user decides what should happen. It becomes part of how the financial action gets executed.

That can improve retention because the workflow is harder to replace. It can create new payments economics. It can reduce the number of disconnected tools a customer needs. It can give the ISV better visibility into transaction status and reconciliation.

It can also change how customers think about the product.

A procurement system that helps choose suppliers is useful.

A procurement system that manages supplier selection, approval, payment, and reconciliation is much closer to operating infrastructure.

That is a more valuable position.

It is also a position with more responsibility.

You Cannot Embed the Payment Without Embedding the Controls

This is where the payments demo usually gets less exciting.

If a platform lets users initiate payments inside the application, the platform needs to understand who is allowed to do that.

If payments can be approved inside the workflow, approval permissions need to be correct.

If virtual cards can be created for specific amounts or suppliers, the rules around those credentials need to be enforced.

If a payment fails, the workflow needs to know what happened.

If supplier information changes after approval, somebody needs to decide whether the payment should still move.

If the transaction looks fraudulent, controls need to interrupt the experience before the money leaves.

Embedded payments can eliminate a portal.

They do not eliminate the reasons the portal had permissions, controls, limits, logs, and exception processes in the first place.

The better the integration becomes, the more those controls need to become part of the product design.

Reconciliation May Be the Bigger Win

Payments people spend a lot of time talking about how quickly money moves.

Finance teams spend a lot of time asking what the money was for.

That distinction matters.

A commercial payment is only useful if the business can connect it back to an invoice, supplier, purchase order, department, project, or expense. When those pieces live in separate systems, reconciliation becomes a reconstruction project.

Embedded payments create an opportunity to capture that context at the moment the payment is created.

The software already knows the business event.

If the payment is generated inside that same workflow, reconciliation data does not have to be bolted on later. It can be part of the transaction design from the beginning.

That could be more valuable than shaving a few seconds off payment initiation.

Nobody in accounts payable wakes up hoping for a faster mystery transaction.

They want a payment that arrives with enough context to close the loop.

This Does Not Mean Every ISV Should Become a Payments Company

There is an easy way to overread announcements like this.

Embedded commercial payments do not mean every enterprise software company needs to become a PayFac, issuer, bank, or payments infrastructure provider.

The Mastercard/BMO model itself demonstrates the opposite. The issuer-backed virtual card capability still depends on financial institutions, network infrastructure, and participating software platforms working together.

The opportunity for the ISV is not necessarily to own every layer.

It is to decide which parts of the customer experience should live inside the software.

That means asking practical questions:

• Does leaving the platform to pay create real customer friction?
• Does the software already have enough transaction context to improve the payment experience?
• Which partner owns issuance, payment execution, fraud controls, settlement, and regulatory obligations?
• Which controls need to exist inside the software?
• What payment status and reconciliation data needs to come back into the platform?
• Who handles exceptions when the payment and the software workflow disagree?
• Does embedding the payment materially improve the product, or are we just adding financial functionality because we can?

That last question matters.

Payments should make the software more useful.

The software should not become more complicated just to say it has embedded payments.

The Better Question Is Where the Workflow Should End

Mastercard and BMO are not the first companies to embed commercial payments, and they will not be the last.

What their announcement illustrates is the direction of travel.

Financial activity is moving closer to the software that creates the business intent behind it.

That is happening in consumer payments, embedded finance, lending, payroll, issuing, and now increasingly in commercial payment workflows.

For ISVs, the strategic question is not simply whether they can add another financial product.

It is where the software experience should stop.

If the platform already knows what should be paid, who approved it, which supplier should receive it, what limits apply, and how the transaction should be reconciled, forcing the user to leave the product to move the money starts to look less like a necessary boundary and more like leftover architecture.

The opportunity is to remove that boundary without removing the controls that made it safe.

The Takeaway

Embedded commercial payments are not interesting because they put a payment button inside an ERP.

They are interesting because they connect financial execution to the operational context that already exists inside the software.

For ISVs, that can create a better user experience, tighter reconciliation, more useful controls, and a deeper role in the customer's business.

But the more of the payment workflow the software owns, the more carefully permissions, approvals, fraud controls, exceptions, and reporting need to be designed.

The future of B2B payments may not be about making users better at moving between software and banking portals.

It may be about finally removing the handoff.

Want to get featured on the CentsChat podcast? Complete our survey.