SPEAKER_01 0:00

Welcome to Sense Chat, the podcast where payments meet personality. From tech trends to legal twists, compliance quirks to marketplace moves. Kitty's here to keep ISVs, pay facks, 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.

SPEAKER_03 0:24

Today we're talking about a good idea that started getting weird. Embedded payments. And to be clear, embedded payments aren't 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.

SPEAKER_02 1:04

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 doesn't close. The refund happens, the report doesn't line up. The terminal batch settles, the accounting export looks like it was assembled during a fire drill. That's not a payments feature, that's 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's inherently bad.

SPEAKER_03 1:48

Exactly. We're very pro-ISV monetizing payments when it's 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's a very good payment strategy. The problem starts when preferred, quietly turns into mandatory.

SPEAKER_02 2:12

And mandatory is where the incentives start getting weird. Once the merchant's fully operating inside the software, switching is not simple. It's 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 1147 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.

SPEAKER_03 2:47

And that's where this conversation gets uncomfortable. Some platforms didn't just say we have a preferred provider and it's 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's not choice. That's a hostage note with a pricing table.

SPEAKER_02 3:11

Yeah, kitty, and the merchant, they eventually figure it out. Maybe the rates go up, maybe support gets worse, terminal options are limited, maybe the processor doesn't 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 doesn't matter. At some point the merchant says, wait, why am I being forced into this?

SPEAKER_03 3:33

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 isn't here and he would send us a strongly worded text if we started freestyling antitrust doctrine. Very fair. But the Shopify and Cezil cade is worth watching. A federal judge in Minnesota allowed key parts of Cecil's antitrust case against Shopify to move forward. Important nuance: this isn't a final ruling. It also isn't 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.

SPEAKER_02 4:14

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're 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's legal, maybe it's commercial, maybe it's a customer truth bomb, but it is a problem.

SPEAKER_03 4:51

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 gonna 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 isn't only legal, it's deeply technical.

SPEAKER_02 5:08

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

SPEAKER_03 5:14

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

SPEAKER_02 5:32

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 makes 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.

SPEAKER_03 6:05

Which brings us to Jordan Thaler. Jordan is the founder of Post and the author of Reforming Retail. Post 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. Post describes the problem as embedded payments convenience getting eclipsed by 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 gonna talk about how embedded payments got here, why merchants are pushing back, what Post is trying to change, and why ISV should pay attention before the market, the courts, or the technology stack forces them to. Jordan, welcome to SenseChat.

SPEAKER_00 6:50

Thanks for having me, Kitty.

SPEAKER_03 6:51

Before we get into Post 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?

SPEAKER_00 7:00

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. So a software would have been, I don't know, 10 to 12 years old, and you could tell their uh market position was slowing, and they needed to find additional growth to justify their valuations, and they would lean heavy-handed into the payment cookie jar.

SPEAKER_02 7:28

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?

SPEAKER_00 7:58

Yes, to all the above. I I think investors drove a lot of the decisions to find growth. And frankly, there's only so much TAM certain verticalized softwares can go after and acquire. Uh, and payments becomes a nice little honeypot because it's so hard to scrutinize the true cost of payments. Even on flat rate pricing, you've got 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're paying for payments, with the exception of a few people in these large enterprise brands.

SPEAKER_03 8:36

That last point is so important. Software pricing is usually annoying, but visible. It's a line item. Payment pricing is a fog machine with a statement attached. And when the merchant can't really see the total cost and can't easily leave the software, that's where the relationship gets lopsided. What does that look like in the real world? Not as a theory, but as merchant level. What are the complaints you hear?

SPEAKER_00 8:54

I think it's like kind of like used car salesman feedback where I was duped, right? I bought this good or this service. I thought it was getting X, and after driving it off a lot, I actually got Y. And so 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 they get their third statement, and they're now paying substantially more than they thought they were. They have limited access to certain features depending upon how much they're willing to pay for payments to the provider. There's just shortcomings in the payments themselves that are offered by the software, the ISV. So I'll give you like a quick example. There are a ton of B2B softwares that are out there that cannot even offer a surcharge or dual price pricing model to their own merchants, which I sort of view as like a standard feature in that segment of the market. But there are hundreds of thousands of merchants, if not more, that don't even have an ability to surcharge compliantly using the embedded payments from their software.

SPEAKER_02 9:58

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, counting, reconciliation, and support workflows, and probably a dozen other things I didn't mention. So when the ISV controls the payments, it's controlling a lot more than just the processor relationship. It's controlling the operating rails of the business.

SPEAKER_03 10:28

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?

SPEAKER_00 10:41

No, they're 100% trapped. I mean, I think the heavier the software, the more embedded it is. Like it's a system of record, the worse the merchant feels. They empathize that, you know, I'm a hostage. I I can't get out of this thing. It'd be like, you know, you bought a house, you know, material investment for your personal life, and all of a sudden you get a knock on your door and it's 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 gonna do? Sell your house? Like that's a huge decision, right? It's it's not like uh buying a new mustache comb. Like it's a real business decision and it's very painful, frankly.

SPEAKER_03 11:19

Now, let's pivot a bit and talk about the ISV side for a minute, because we should be fair. If you're 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's 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.

SPEAKER_02 11:45

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, they wanted lower support load, they wanted more control over chargeback handling, refunds, card on file, device behavior, ledger posting. All of this is real stuff. But then the model can drift. The payments partner stops being selected because it's the best merchant experience and starts being selected because it produces the best economics for the software platform. That's where the slope starts getting really slippery.

SPEAKER_03 12:22

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's happening here. That's the trust break. Jordan, what's the line between a healthy preferred payments program and abusive lock-in?

SPEAKER_00 12:42

Well, I think table stakes are you need all the features that matter to your business are the merchants you support in that segment that they're in. I mean, that's kind of a no-brainer. And look, let's be honest, like there's a real cost to support third-party payment providers. And I know we'll get into that, but you can't make that argument that, hey, the cost to support a third-party payment provider is so expensive that our own payments are gonna be three, four, five times market rates. So there's like 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, like what's fair and what is beyond reproach, and clearly just taking advantage of the merchant.

SPEAKER_02 13:27

Yeah, I want to call out that phase, 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 looks like it escaped from 2009. That's not really choice. That's a compliance safe way to say no.

SPEAKER_03 13:52

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 partn doesn't. Their brother works at Chase and they want to give him the business. The ISV may think that's not our problem, but it becomes the ISV's problem when the merchant starts blaming the software for taking the choice away.

SPEAKER_02 14:13

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

SPEAKER_03 14:19

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

SPEAKER_00 14:26

Oh, I mean, they they almost always blame the software, even if it's like not mandated. I remember NCR, they ran a survey that said, hey, they called a bunch of merchants and said, Hey, merchants, you know, who who's responsible for your payments, right? 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, right? They confuse the different sides of the equation and they always blame the software for the payments.

SPEAKER_02 14:52

Yeah, and that's the big hidden cost to ISVs and a lot of these programs. The spreadsheets say you're earning basis points, but the support cues tell you you're sacrificing your merchant trust.

SPEAKER_03 15:03

And customer trust has a very annoying habit of turning into churn leader. Now, Jordan, let's bring Post into this. Post 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 won't give us a choice, we're gonna build choice around the software. And for listeners who haven't seen it, Post is framed around payments choice. The site talks about integrating workflows between a merchant's software and preferred payments partner, choosing the support features, pricing that works for the business, and maintaining PCI compliance. It's very clearly aimed at the pain point of software companies limiting payment provider choice. So, in plain English, what does Post do?

SPEAKER_00 15:36

Post is an agent that works on your behalf like a robot that says, hey, when it comes time to paint, instead of using the payments that are natively supported with my software, have the agent grab the relevant payment information. So for instance, like cardholder name, amount, et cetera, and plug that into my preferred payment partner, and then run that payment and then have that same agent write that data back into my software ledger. So everything is reconciled. So like you get the best of both worlds when 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.

SPEAKER_02 16:10

Yeah, Jordan, I've 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 can't describe infrastructure without making it sound like a felony. But technically, there's a real pain point there. Post 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?

SPEAKER_00 16:37

It's kind of all of it. I mean, there are clearly discrete payment flows, right? There's synchronous stuff like terminal payments, there's async we've got recurring and things like that. All we do is we read the information in the software and we point it to a gateway. And a gateway handles the PCI certifications, the device certs, and we're gateway neutral, we don't 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, FiSerf, T Sys, et cetera. And then we write that data back from the gateway into the software to close it out in a ledger.

SPEAKER_02 17:07

Yeah, and that's really the key part, right? This is the part that people outside of payments underestimate. The hard part isn't 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 afterwards. The staff can't be forced into three different browser tabs and a prayer ritual every time a customer wants to pay. There's a pretty clear message to the old acquiring world. Software companies tried to close the door, and Post is selling a new door.

SPEAKER_03 17:37

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, we aren't letting someone route around our payment program. Jordan, what do you say to an ISV that sees Post only as a drive?

SPEAKER_00 17:52

Uh kind of like two camps. One camp, you actually have a number of ISVs that don't want to spend the engineering time building their own integrations to a payment provider. And so maybe they have a partnership and Post says, hey, we'll just enable the payment integration for you in kind of like a no-code way. So you can get up and running in 10, 15 minutes instead of spending weeks, months, depending who the gateway is. And then you have merchants that are just gonna leave. They're gonna straight up leave the software because it's become so tortuous. We say, Hey, we can save this merchant for you, Mr. ISV, and we can allow them to process somewhere else and have them still as our revenue a line item in your income statement because they're gonna keep your software, right? So it just depends on the positioning and the framing from the ISV's perspective.

SPEAKER_03 18:32

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're 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.

SPEAKER_02 18:56

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.

SPEAKER_03 19:18

Exactly. Most merchants probably will choose the preferred provider if the pricing is fair and the experience is good. They don't want to create extra work for themselves. They don't 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.

SPEAKER_02 19:36

Yeah, there's a huge difference between preferred and prison. Preferred means this is the path we recommend because it works well. It's deeply integrated, it's fairly priced. Prison means this is the path you are taking because the exits are welded shut. Those are not the same strategy.

SPEAKER_03 19:51

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'll win a lot of payment volume. But if your strategy depends on the merchant not being able to escape, that's not a durable strategy. That's 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?

SPEAKER_00 20:23

It depends on the segment they're going after and it depends on what their economic model is. If maximize the long-term success of their business and the viability of their growth, then it's it's a better conversation to say, hey, here are the processes that we've seen work, right? Here's how you can still make money and monetize payments, but also not be uh seen as a greedy pig that will get slaughtered in court someday. So it's just having an open mind and understanding that you don't have to know everything. There are people that know a lot about payments that can provide you value and frankly help you really succeed in your payments program way more than just cranking the races as far to the right as they will go. Right? You can get better penetration, better word of mouth if you do things in a sensible way.

SPEAKER_02 21:02

Yeah, that's great advice, Jordan. And here's my technical takeaway on this 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 is 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 ISB strategy is just keep changing the flow until the workaround dies, that's not a strategy. That is an arms race against your own customers.

SPEAKER_03 21:38

And my strategic takeaway is this payments monetization isn't 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, because the integration saves time, because the experience is actually superior. But if merchants are using it only because you trap them, eventually someone's gonna build a door. Post as a reminder that the door is already being built.

SPEAKER_02 22:00

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

SPEAKER_03 22:04

Exactly. So for ISVs, the advice isn't 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's 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.

SPEAKER_00 22:30

Oh, it's always great to talk with you guys.

SPEAKER_03 22:32

Thanks for listening to SenseChat. We'll see you next time.

SPEAKER_01 22:34

Thanks for tuning in to SenseChat. 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 SenseChat, we're here to make payments make sense and make it fun while we're at it. See you next time.