Announcer: Welcome to Cents Chat, the podcast where payments meet personality. From tech trends to legal twists, compliance quirks to marketplace moves. Kitty is here to keep ISVs, PayFacs, and marketplaces ahead of the curve. Get ready for insights, a few laughs, and the occasional compliance scare. Let's dive in and make payments make sense.

Kitty: Today we're talking about a good idea that started getting weird. Embedded payments.

And to be clear, embedded payments are not the villain here. For a lot of ISVs, choosing a payments partner was a very practical move. You had software companies serving restaurants, salons, field service businesses, retailers, nonprofits, healthcare providers, gyms, franchise operators, and every other niche you can imagine. Their customers needed to take payments inside the workflow.

So the ISV said, great, instead of sending every merchant out to find a processor, a gateway, a terminal vendor, a support contract, a reconciliation process, we'll pick a partner, we'll integrate it, we'll make onboarding easier, we'll make the merchant's life better. That version makes total sense.

Jason: Yeah, Kitty, it really does. The original embedded payment story is very defensible. The ISV is already the system of record. It owns and operates the workflow. The merchant is already living inside that software ecosystem every day. So if payments are bolted on awkwardly, the merchant feels that pain immediately.

The card gets approved, but the invoice does not close. The refund happens, the report does not line up. The terminal batch settles, and the accounting export looks like it was assembled during a fire drill.

That is not a payments feature. That is an operational mess with the card brands involved.

So the ISV picks a payment partner. Maybe they get a revenue share. Maybe they become PayFac-like. Maybe eventually payments becomes a serious part of the company's revenue model. None of that is inherently bad.

Kitty: Exactly. We're very pro-ISV monetizing payments when it is done well. Have a preferred payments partner. Make money on payments. Build a better checkout experience. Reduce support friction. Give merchants modern hardware, better reporting, faster onboarding, cleaner reconciliation, and a partner who actually understands the vertical.

That is a very good payment strategy.

The problem starts when preferred quietly turns into mandatory.

Jason: And mandatory is where the incentives start getting weird. Once the merchant is fully operating inside the software, switching is not simple. It is not like changing your phone plan.

The merchant has trained staff on the system. They have menus, SKUs, customers, schedules, invoicing, accounting workflows, loyalty programs, terminal devices, technology integrations, and probably one person in the back office who knows exactly which report to pull at 11:47 p.m. every Friday.

So when the ISV says you have to use our processor, the merchant may technically have a choice, but practically, not really.

Kitty: And that's where this conversation gets uncomfortable.

Some platforms did not just say we have a preferred provider and it is the best-supported path. They said use our payment provider or lose functionality. Use our payment provider or pay extra fees. Use our payment provider or accept worse reporting. Use our payment provider or go through the operational joy of switching your entire software back.

That is not choice. That is a hostage note with a pricing table.

Jason: Yeah, Kitty, and the merchant eventually figures it out. Maybe the rates go up. Maybe support gets worse. Terminal options are limited. Maybe the processor does not want to support something the merchant needs. Maybe the merchant has a bank relationship they want to keep. Maybe their brother sells payments and they want to give the business to him.

The reason almost does not matter. At some point, the merchant says, wait, why am I being forced into this?

Kitty: And now there's another layer. The legal pressure may be changing.

We're not turning this into a law school seminar, mostly because Chris is not here and he would send us a strongly worded text if we started freestyling antitrust doctrine. Very fair.

But the Shopify and Sezzle case is worth watching. A federal judge in Minnesota allowed key parts of Sezzle's antitrust case against Shopify to move forward. Important nuance: this is not a final ruling. It also is not finding that Shopify broke the law. The court dismissed some claims, including the tying claim without prejudice, but the court allowed core monopolization, attempted monopolization, and restraint of trade claims to continue.

For ISVs and marketplaces that rely on forced or punitive payments economics, that should get attention.

Jason: Because this legal theory starts to sound familiar to anyone in embedded payments. You have a primary product, which is a software platform. Then you have the secondary markets around it: payments, buy now, pay later, terminals, gateways, tokens, reconciliation, reporting, all the things the merchant needs after they are already operating inside the platform.

If the merchant cannot reasonably understand the lifetime cost of payments when they choose the software, and later they cannot reasonably switch software when the payment economics get painful, you have ingredients for an ugly dispute.

Maybe it is legal. Maybe it is commercial. Maybe it is a customer truth bomb. But it is a problem.

Kitty: And this is why we wanted Jason in the chair for this one.

Because yeah, if you hear litigation, you might think, shouldn't Chris be here? And that's a fair question. We're absolutely going to get Chris's opinion as some of these cases develop. He's our contract, compliance, and legal architecture brain for a reason.

But this conversation is not only legal. It is deeply technical.

Jason: Yeah, and Chris worked really hard on the last episode, so we figured we'd give him the week off from antitrust vocabulary.

Kitty: One week. Very generous of us.

But seriously, Jason is here because today's guest is someone he has worked with for years on technical payment deep dives. This episode is going to get into payment flows, gateways, acquirers, tokens, software control points, and what actually happens when a platform tries to prevent merchants from using alternatives.

Jason: And that is the key point.

ISVs can keep changing the payment flow. They can move the checkout logic. They can change how terminals connect. They can alter the token path. They can make reconciliation harder. They can create new certification gates.

But every defense change creates operational risk. And now the workaround side is getting smarter too. AI automation, better monitoring, adaptive tooling, and faster testing make it easier to understand what changed and respond faster.

So if your strategy is, we'll just keep breaking the workaround, you might be starting a cat-and-mouse game against your own merchants.

Kitty: Which brings us to Jordan Thaeler.

Jordan is the founder of POS+ and the author of Reforming Retail. POS+ is built around a simple but very disruptive idea: merchants should have payment choice, even when the software they use would prefer to make that choice disappear.

POS+ describes the problem as embedded payments convenience getting eclipsed by the control software companies exert over their customers. This is the entire tension of the episode in one sentence.

Jordan and Jason go way back, and Jordan has leaned on Jason for the kind of technical payment plumbing conversations most people in the industry either avoid or pretend are simpler than they are.

So today we're going to talk about how embedded payments got here, why merchants are pushing back, what POS+ is trying to change, and why ISVs should pay attention before the market, the courts, or the technology stack forces them to.

Jordan, welcome to Cents Chat.

Jordan Thaeler: Thanks for having me, Kitty.

Kitty: Before we get into POS+ specifically, take us back to the market problem. When did you start seeing embedded payments shift from convenience for the merchant into control over the merchant?

Jordan Thaeler: I think it was when the early adopters of embedded payments started to go public and you could scrutinize the financials of some of these companies in a very transparent way.

A software company would have been, I do not know, 10 to 12 years old, and you could tell their market position was slowing. They needed to find additional growth to justify their valuations, and they would lean heavy-handed into the payment cookie jar.

Jason: Yeah, Jordan, I think that story matters because a lot of people hear this conversation and assume the argument is embedded payments is bad. And that's not the argument. Embedded payments solved real problems. The issue is what happened once the software companies realized payments could become the margin engine.

Jordan, from your perspective, what changed inside the market? Was it investor pressure? Was it the PayFac model becoming popular? Was it software companies seeing that payment pricing is harder for merchants to audit than software pricing?

Jordan Thaeler: Yes, to all the above. I think investors drove a lot of the decisions to find growth. And frankly, there is only so much TAM certain verticalized software can go after and acquire.

Payments becomes a nice little honeypot because it is so hard to scrutinize the true cost of payments. Even on flat-rate pricing, you have all sorts of malfeasance with interchange, refunds not happening, etc. And so nobody really knows.

I guess I'll contend, nobody really knows how much they are paying for payments, with the exception of a few people in these large enterprise brands.

Kitty: That last point is so important.

Software pricing is usually annoying, but visible. It is a line item.

Payment pricing is a fog machine with a statement attached. And when the merchant cannot really see the total cost and cannot easily leave the software, that is where the relationship gets lopsided.

What does that look like in the real world? Not as a theory, but at the merchant level. What are the complaints you hear?

Jordan Thaeler: I think it is kind of like used car salesman feedback where I was duped, right? I bought this good or this service. I thought I was getting X, and after driving it off the lot, I actually got Y.

A lot of times merchants will say, hey, I was going to pay X, my rate was going to be matched, and they get their first statement or their third statement, and they are now paying substantially more than they thought they were.

They have limited access to certain features depending upon how much they are willing to pay for payments to the provider. There are just shortcomings in the payments themselves that are offered by the software, the ISV.

I'll give you a quick example. There are a ton of B2B software platforms out there that cannot even offer a surcharge or dual-price pricing model to their own merchants, which I view as a standard feature in that segment of the market. But there are hundreds of thousands of merchants, if not more, that do not even have an ability to surcharge compliantly using the embedded payments from their software.

Jason: Yeah, Jordan, and as we start to touch on the technical side, payments go way beyond just the checkout button.

They touch authorization, capture, settlement, refunds, voids, chargebacks, tokens, recurring billing, stored credentials, reporting, accounting, reconciliation, support workflows, and probably a dozen other things I did not mention.

So when the ISV controls the payments, it is controlling a lot more than just the processor relationship. It is controlling the operating rails of the business.

Kitty: Which is why forced payments feel so personal to merchants.

The ISV may think, we're just monetizing payments. The merchant thinks, you're now interfering with how I run my business.

Jordan, is that the emotional piece real? Do merchants feel trapped, or are we overstating it?

Jordan Thaeler: No, they are 100% trapped. I think the heavier the software, the more embedded it is, like a system of record, the worse the merchant feels. They empathize that I am a hostage. I cannot get out of this thing.

It would be like you bought a house, a material investment for your personal life, and all of a sudden you get a knock on your door and it is someone saying, hey, you have to buy all your house repair goods through me. And those home repair goods are 10 times the price you could get from Lowe's or Home Depot.

So what are you going to do? Sell your house? That is a huge decision. It is not like buying a new mustache comb. It is a real business decision, and it is very painful, frankly.

Kitty: Now, let's pivot a bit and talk about the ISV side for a minute, because we should be fair.

If you are a vertical software company, payments revenue can be very meaningful. It can fund product development. It can make your unit economics better. It can help you support the platform. It can increase enterprise value. And if you have a good partner, it can make the merchant experience better. There is nothing wrong with that.

The mistake is assuming that because payments revenue is valuable to the ISV, the merchant should just accept whatever economics the ISV picked.

Jason: Yeah, exactly, Kitty. Revenue share is not the whole deal.

A lot of ISVs originally picked a payments partner for good reasons. They wanted one integration of support. They wanted clean onboarding flows, less chaos from random processors, lower support load, more control over chargeback handling, refunds, card on file, device behavior, and ledger posting.

All of this is real stuff. But then the model can drift.

The payments partner stops being selected because it is the best merchant experience and starts being selected because it produces the best economics for the software platform. That is where the slope starts getting really slippery.

Kitty: And the merchant can feel the difference immediately.

When the preferred payments partner is good, the merchant says, fine, this works. I can see why they recommend it.

When the mandatory payments partner is expensive, thin on features, hard to support, and still non-negotiable, the merchant says, oh, I see what is happening here.

That is the trust break.

Jordan, what is the line between a healthy preferred payments program and abusive lock-in?

Jordan Thaeler: Well, I think table stakes are that you need all the features that matter to your business or the merchants you support in that segment that they are in. That is kind of a no-brainer.

And look, let's be honest, there is a real cost to support third-party payment providers, and I know we will get into that. But you cannot make the argument that the cost to support a third-party payment provider is so expensive that our own payments are going to be three, four, five times market rates.

There is a level of reasonableness, if I can use that word, that the ISV or the software needs to have when they approach the pricing for the payments. Everyone on this call could agree we understand with our payments expertise what is fair and what is beyond reproach and clearly just taking advantage of the merchant.

Jason: Yeah, I want to call out that phrase, taking advantage of the merchant.

A platform can say we allow third-party providers and still make that choice meaningless. If the alternative requires extra fees, degraded functionality, manual processes, missing orders, subpar support, and terminal workflows that look like they escaped from 2009, that's not really choice.

That is a compliance-safe way to say no.

Kitty: Exactly. And sometimes the merchant has a very normal reason for wanting another payments provider.

Their local bank has supported them for 20 years. Their franchise group has a national deal. Their processor supports a feature the preferred partner does not. Their brother works at Chase, and they want to give him the business.

The ISV may think that is not our problem, but it becomes the ISV's problem when the merchant starts blaming the software for taking the choice away.

Jason: Which they absolutely will. If the platform owns the experience, the merchant will hold the platform responsible.

Kitty: Jordan, how often do merchants blame the processor versus blaming the software platform that forced them into the processor?

Jordan Thaeler: They almost always blame the software, even if it is not mandated.

I remember NCR ran a survey. They called a bunch of merchants and said, hey, merchants, who is responsible for your payments? They did it as a secret shopper, if you will. And the merchants would just look down at the Aloha register, see the logo, and say, oh yeah, this is Aloha's problem.

So they have no idea. They confuse the different sides of the equation, and they always blame the software for the payments.

Jason: Yeah, and that is the big hidden cost to ISVs in a lot of these programs. The spreadsheets say you are earning basis points, but the support queues tell you that you are sacrificing merchant trust.

Kitty: And customer trust has a very annoying habit of turning into churn later.

Now, Jordan, let's bring POS+ into this. POS+ is interesting because it feels like a direct market response to the behaviors we're talking about. The market basically said, fine, if the software will not give us a choice, we are going to build choice around the software.

And for listeners who have not seen it, POS+ is framed around payments choice. The site talks about integrating workflows between a merchant's software and preferred payments partner, choosing the support features and pricing that work for the business, and maintaining PCI compliance. It is very clearly aimed at the pain point of software companies limiting payment provider choice.

So in plain English, what does POS+ do?

Jordan Thaeler: POS+ is an agent that works on your behalf like a robot that says, hey, when it comes time to pay, instead of using the payments that are natively supported with my software, have the agent grab the relevant payment information.

So for instance, cardholder name, amount, etc., and plug that into my preferred payment partner, then run that payment, and then have that same agent write that data back into my software ledger so everything is reconciled.

So you get the best of both worlds. You get to keep a software that you probably like a lot, but you have total control over the payments that come with that software.

Jason: Yeah, Jordan, I have talked to a handful of ISVs about this concept, and the word that commonly comes up is hijack, which is funny because payments people apparently cannot describe infrastructure without making it sound like a felony.

But technically, there is a real pain point there. POS+ is trying to intercept or reroute the payment experience in a way that preserves the merchant's operational flow.

Can you talk about the kinds of payment flow control points that matter?

Jordan Thaeler: It is kind of all of it. There are clearly discrete payment flows. There is synchronous stuff like terminal payments. There is async. We have recurring and things like that.

All we do is read the information in the software and point it to a gateway. The gateway handles the PCI certifications, the device certs, and we are gateway neutral. We do not care. We just point the data from the software to that gateway.

The gateway runs a transaction through whoever the gateway is connected with on the back end, Fiserv, TSYS, etc. And then we write that data back from the gateway into the software to close it out in a ledger.

Jason: Yeah, and that is really the key part.

This is the part that people outside of payments underestimate. The hard part is not just getting an authorization. Anyone can swipe a card in a non-integrated terminal or use a standalone gateway. The hard part is making the business workflow still make sense afterward.

The staff cannot be forced into three different browser tabs and a prayer ritual every time a customer wants to pay.

There is a pretty clear message to the old acquiring world. Software companies tried to close the door, and POS+ is selling a new door.

Kitty: Which brings us to the ISV reaction because some ISVs will hear this and say, absolutely not. We control the product, we control the workflow, we control the integration, and we are not letting someone route around our payment program.

Jordan, what do you say to an ISV that sees POS+ only as a threat?

Jordan Thaeler: There are kind of two camps.

One camp: you actually have a number of ISVs that do not want to spend the engineering time building their own integrations to a payment provider. Maybe they have a partnership, and POS+ says, hey, we will just enable the payment integration for you in a no-code way. So you can get up and running in 10 or 15 minutes instead of spending weeks or months, depending who the gateway is.

And then you have merchants that are just going to leave. They are going to straight up leave the software because it has become so torturous.

We say, hey, we can save this merchant for you, Mr. ISV, and we can allow them to process somewhere else and still have them as a revenue line item in your income statement because they are going to keep your software.

So it just depends on the positioning and the framing from the ISV's perspective.

Kitty: The ISV may make less on payment volume, but it may keep the customer. And keeping the customer is also monetization.

Now let's make this useful for ISVs. The practical advice is not do not monetize payments. That would be silly.

Please monetize payments. If you are an ISV, payments can be one of the most important revenue lines in the business. It can support the product, deepen the customer relationship, improve workflows, and create real enterprise value.

But monetize it like an adult, please.

Jason: Pick a great default partner. Not just a partner with the biggest rev share on the slide. A partner that can actually support your merchants.

Partner with the right devices, the right gateway capabilities, the right reporting, the right risk posture, the right onboarding processes, and the right vertical knowledge.

Build the integration well. Make the default path excellent. Then give your merchants options.

Kitty: Exactly.

Most merchants probably will choose the preferred provider if the pricing is fair and the experience is good. They do not want to create extra work for themselves. They do not want to solve payments headaches for sport.

But the existence of an alternative changes the emotional temperature of the relationship. The merchant no longer feels cornered. They feel like they have a choice, and that matters.

Jason: Yeah, there is a huge difference between preferred and prison.

Preferred means this is the path we recommend because it works well. It is deeply integrated. It is fairly priced.

Prison means this is the path you are taking because the exits are welded shut.

Those are not the same strategy.

Kitty: And merchants know the difference.

The best ISV strategy is to make the preferred option so good that merchants choose it willingly. Good pricing, good support, good devices, good reporting, clean onboarding, useful payment methods, strong reconciliation, a partner that understands the vertical.

If you do that, you will win a lot of payment volume. But if your strategy depends on the merchant not being able to escape, that is not a durable strategy. That is a countdown.

Jordan, final question for you. If you had five minutes with an ISV executive who is currently deciding whether to double down on exclusive payments or open up a structured choice model, what would you tell them?

Jordan Thaeler: It depends on the segment they are going after, and it depends on what their economic model is.

If maximizing the long-term success of their business and the viability of their growth is the goal, then it is a better conversation to say, hey, here are the processes that we have seen work. Here is how you can still make money and monetize payments, but also not be seen as a greedy pig that will get slaughtered in court someday.

It is having an open mind and understanding that you do not have to know everything. There are people that know a lot about payments that can provide you value and frankly help you succeed in your payments program way more than just cranking the rates as far to the right as they will go.

You can get better penetration and better word of mouth if you do things in a sensible way.

Jason: Yeah, that is great advice, Jordan.

Here is my technical takeaway: lock-in is becoming harder to maintain. Not impossible, but harder.

Software platforms still have power. They control the workflows, data, interfaces, APIs, tokens, and support paths. But AI and adaptive tooling are changing the economics of routing around friction. They make it faster to understand a workflow, detect changes, test new paths, and keep alternatives alive.

So if the ISV strategy is just keep changing the flow until the workaround dies, that is not a strategy. That is an arms race against your own customers.

Kitty: And my strategic takeaway is this: payments monetization is not the villain. Captivity is.

If your payments program is good, merchants will use it because it works, because the pricing is fair, support is better, reconciliation is cleaner, the integration saves time, and the experience is actually superior.

But if merchants are using it only because you trap them, eventually someone is going to build a door.

POS+ is a reminder that the door is already being built.

Jason: And the more you try to weld it shut, the more valuable that door becomes.

Kitty: Exactly.

So for ISVs, the advice is not complicated. Pick a great payments partner. Make the default path excellent. Get your revenue share. Support the merchant well. Then create a reasonable alternative path for merchants who need it.

Most merchants will probably still choose the default if it is fair and functional. But the option matters. The trust matters. The posture matters.

Because in payments, people like choice.

And when you take choice away, somebody else will eventually find a way to sell it back to them.

Jordan, thank you so much for joining us.

Jordan Thaeler: It is always great to talk with you guys.

Kitty: Thanks for listening to Cents Chat. We'll see you next time.

Announcer: Thanks for tuning in to Cents Chat. Got questions? Got ideas? Got payment problems keeping you up at night? We've got you covered. Head over to our website to take our quick survey. You might just land a guest spot on the pod.

Don't forget to subscribe, share this episode with your favorite ISV, and follow us on all social for the latest trends, tips, and debates. We promise no boring slideshows. At Cents Chat, we're here to make payments make sense and make it fun while we're at it. See you next time.