Your Payments Provider Is Becoming Infrastructure. Do You Know What You Actually Own?

For a long time, the standard software-company payments strategy was pretty easy to explain.

Find a processor. Integrate the API. Send transactions into the box. Receive money out the other side. Try not to think too hard about everything happening in between.

That model was never actually simple, of course. Payments people have spent decades turning the phrase "it's handled by the processor" into an impressive collection of contracts, certifications, settlement files, network connections, sponsor relationships, fraud systems and operational procedures.

But from the ISV's point of view, much of that machinery could remain somebody else's machinery.

That line is starting to move.

In August, REPAY announced a reseller agreement with Visa that will bring Visa Platform Connect to ISO and ISV clients. Under the arrangement, REPAY serves as the clearing and settlement backend while eligible clients can build processing solutions with access to Visa's infrastructure.

For technology-forward payments companies, that's interesting.

For software companies that have spent the last decade trying to own more of the payment experience, it's also a warning label disguised as an opportunity.

Because the closer your technology gets to the payment rails, the harder it becomes to say payments are just something your provider handles.

The Processor Used to Be the Box

Traditional processing relationships created a fairly obvious architectural boundary.

Your application collected the information it needed, passed payment instructions to a processor or gateway, and depended on that provider's stack to do a lot of the heavy lifting underneath.

That could be frustrating.

The provider's capabilities influenced what you could build. Its APIs influenced your development roadmap. Its reporting shaped your reconciliation process. Its supported transaction types, tokenization tools, fraud products and downstream connections could become product constraints even though your customers had no idea the processor existed.

If something didn't work, the customer still called you.

That's the uncomfortable reality of embedded payments: customers experience the platform, not the vendor diagram.

So ISVs naturally started asking for more control.

They wanted better APIs. Better data. More portable tokens. More configurable risk tools. More flexible routing. More ownership over authorization logic. Better visibility into settlement. More freedom to switch partners without rebuilding the entire payments product.

Those are reasonable demands.

Infrastructure like Visa Platform Connect pushes that evolution further. Visa describes the platform as a single connection into Visa Acceptance Platform capabilities, with access to VisaNet for authorization and capture services. REPAY says its arrangement can support ISOs and ISVs that have already built sophisticated authorization capabilities while REPAY handles the clearing and settlement backend.

In other words, the processor doesn't necessarily have to be one giant box anymore.

The box can be broken into pieces.

That's where things get interesting.

Modular Payments Means Modular Responsibility

The payments industry loves modularity because modularity sounds like freedom.

Pick the components you want. Replace the ones you don't. Build differentiated technology where it matters. Let specialized partners handle the commodity pieces.

That's good architecture.

But payments architecture isn't only a technology decision. Every module has an operational owner.

Authorization has an owner.

Clearing and settlement have an owner.

Fraud management has an owner.

Tokenization has an owner.

Disputes have an owner.

Merchant onboarding has an owner.

PCI responsibilities have an owner.

EMV certifications, if you're supporting card-present acceptance, have an owner.

Reconciliation has an owner.

Monitoring has an owner.

Support has an owner.

And when the architecture gets more modular, those ownership boundaries can become less obvious rather than more obvious.

REPAY's announcement is useful precisely because the company is explicit about some of those lines. REPAY says it will provide the clearing and settlement backend. It also describes compliance offload that includes management around EMV and PCI DSS/PIN Transaction Security, while the platform provides access to capabilities such as fraud management, tokenization and dispute resolution.

That doesn't mean every ISV suddenly owns all of those functions.

It means the industry is getting better at separating the layers.

And once the layers are separated, ISVs need to get much better at deciding which ones belong inside their company.

More Control Is Not the Same Thing as Less Complexity

This is where payments strategy can get seduced by the architecture diagram.

A direct-looking connection is visually satisfying.

Fewer boxes. Fewer arrows. Fewer mysterious processor acronyms between the platform and the network.

It feels cleaner.

Operationally, however, removing an intermediary doesn't automatically remove the work that intermediary was doing.

Sometimes the work gets automated.

Sometimes a different provider takes it over.

Sometimes it becomes your work.

That distinction matters.

An ISV that owns sophisticated authorization logic may gain meaningful advantages from controlling that layer. It can potentially make product decisions faster, create differentiated transaction logic, improve data visibility and avoid waiting for a legacy processor to support every new idea.

But the business should know why it wants that control.

"We don't like our processor" is not an architecture strategy.

Neither is "we want to own payments."

Own what, exactly?

If authorization is strategically important to your product, owning more of that layer may make sense. If clearing and settlement aren't where you differentiate, keeping a specialized backend partner there may make more sense. If your team has no desire to become experts in EMV certification or PIN security, offloading those responsibilities may be worth more than theoretical architectural purity.

The goal shouldn't be to own the maximum possible amount of payments infrastructure.

The goal should be to own the parts that create strategic leverage and understand the dependencies around everything else.

Your Customer Does Not Care Where the Boundary Is

There is another reason this matters for ISVs.

Customers don't know which company owns authorization.

They don't know who generates the settlement file.

They don't know which provider hosts the token vault or which contract determines who handles a particular compliance obligation.

They know the payment button was inside your software.

So when a payment fails, a refund disappears, settlement doesn't match the report or a dispute workflow makes no sense, the architectural ownership boundary isn't necessarily the customer-experience boundary.

That's why platforms need two maps.

The first is the technical map: which systems perform which functions.

The second is the responsibility map: who is accountable when each function doesn't work.

Those maps should line up.

If they don't, support becomes escalation theater.

Your customer calls your support team. Your support team calls your payments team. Your payments team opens a ticket with a provider. The provider identifies another provider. Somebody eventually finds the problem three business days later while everyone involved insists the issue technically belonged to someone else.

Technically correct is not especially comforting when the merchant is missing money.

The Contract Has to Match the Architecture

As payment infrastructure becomes more composable, the commercial and compliance structure has to keep up.

If your company is changing how transactions are authorized, routed, cleared or settled, somebody needs to understand how that affects the agreements underneath the product.

What does your provider actually promise to do?

What are you required to do?

Which certifications are being managed by a partner?

Which controls remain your responsibility?

Who owns incident response?

Who is responsible for reconciliation breaks?

Who communicates with merchants when something goes wrong?

What happens if you decide to replace one component later?

Can your data and tokens move with you?

None of those questions are as exciting as a modern API.

They are also the questions that determine whether a modular payments stack actually gives you leverage or just gives you a more complicated collection of dependencies.

The New Payments Strategy Is Choosing What Not to Own

The REPAY and Visa announcement isn't interesting because every ISV should suddenly rethink its processor and build directly toward network infrastructure.

Most shouldn't.

It's interesting because it shows where the market is going.

Payment infrastructure is becoming more accessible, more API-driven and more modular. Technology companies that once had to accept a processor's entire stack can increasingly make more deliberate choices about the layers they use, the partners behind them and the capabilities they build themselves.

That's a big opportunity for sophisticated ISVs.

But sophistication isn't measured by how many pieces of the payments stack you can pull in-house.

It's measured by knowing which pieces are worth owning.

The best payments architecture may not be the one with the fewest vendors or the most direct network connection. It may be the one where every critical function has a clear owner, every dependency is understood, and the platform has control exactly where control creates an advantage.

Payments providers are becoming infrastructure.

That gives software companies more choices than they used to have.

Just remember: every time you move the line between your platform and your provider, responsibility moves with it.

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