Announcer: Welcome to Cents Chat, the podcast where payments meet personality. From tech trends to legal twists, compliance quirks to marketplace moves, Kitty's 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: If you're a software company processing payments online today, adding card present can sound pretty straightforward.

Your customers want to take payments in person, so you add a terminal.

How hard could that be?

Well, apparently it's pretty hard. Because once a physical payment device enters the picture, you're not just dealing with an API anymore. You've got hardware, EMV certifications, encryption keys, PCI scope, deployment, provisioning, interchange data, and an actual box that somehow has to make it from somewhere in the supply chain to your customer's countertop and work when they turn it on.

So today we're talking about what really changes when an ISV or PayFac moves into the card-present world.

And Jason's joining me for this one because we're going to get a little more technical than usual.

Jason: We could go way down the rabbit hole on this one. It could get really, really scary.

Kitty: That's actually what I'm afraid of, Jason.

Our guest is Lori Rainery. Lori spent years working directly in EMV, POS, payment implementations, and card-present technology, including leadership roles at TSYS and First American.

And Jason, you and Lori actually go back a ways. Is that true?

Jason: Yeah. Lori actually was an EMV expert before I even cut my teeth doing terminal certification. So I learned a tremendous amount from her probably, what, 15 years ago at this point?

She can get about as far down in the technical weeds as anyone can and knows exactly how to turn a piece of hardware into something that a merchant can actually use.

Kitty: Well, Lori, welcome to Cents Chat.

Lori Rainery: Thank you.

Kitty: Before we drag you back into the world of terminals and EMV, give us the quick version of your payments background. You've been on the development side, the implementation side, product, sales. You've seen card present from a lot of different angles. What do you have?

Lori Rainery: Absolutely.

Starting at TSYS, I actually was the manager of our development team for Class B. And what that meant was truly working with those ISVs, implementing card payments or a POS into their payment solution.

Then, moving on to First American Payment Systems, I was not only the implementation director, but shortly after that I became senior director of sales. Inside of that, I worked with ISVs directly, making sure that their point-of-sale systems were card-brand approved to go out into the real world.

Kitty: Now you've moved into a completely different chapter professionally. And before we make you spend the rest of the episode talking about your former life, tell us what you're building now with Polaris Crescent.

Lori Rainery: Just like EMV, AI is not defined. It's being rolled out in organizations that know they need to adapt to AI and enable AI, and they really don't have that path to do so.

What we do is solve that transformation for companies to bring AI into their organization in a safe and ethical way.

We're really standing beside them, helping them understand the governance piece, the compliance piece, all the different pieces and parts they need to enable so that AI can actually affect their bottom line.

Jason: It's really interesting how many payments companies I talk to that are embracing AI and have yet to update their acceptable-use policies to even have any AI governance whatsoever.

They've got source code flying everywhere.

Lori Rainery: Yes. Subprocessor and EULAs are missed often.

So we really start with that assessment and say, “Hey, what do you have?” And then we come in and help with that transformation.

Kitty: All right. We've officially let you talk about what you're doing in 2026. Now we're going to send you all the way back to terminals.

I bet you're very excited for that one.

Lori Rainery: So excited.

EMV definitely was a huge part of my life for a very long time.

Kitty: Well, let's start with the assumption that gets companies into trouble.

You're an ISV. You already process card-not-present payments. Your customers start asking to accept cards in person. From the outside, the roadmap almost looks like “add terminal support.”

But that's not really what you're signing up for, is it?

Lori Rainery: No, not at all.

Wow. I don't even know where to start.

The first thing you should think about is PCI DSS, right? It's that full path of where that card information is starting from and then going to.

And then also, you need to look at your certifications. EMV certifications are still a thing.

When we were doing the first EMV certifications, for companies that were really just going out there and doing it on their own, you're looking at a two-plus-year roadmap.

And even when we had full-on experts, UL, Visa, all the issuers that were supporting this huge movement in the United States, I think the minimum certification time was like 10 months.

And that was with a whole team of people.

Jason: Let's dive into EMV because it's probably one of the first places that software companies start realizing that things work differently.

Online integrations are pretty JSON-based, RESTful APIs.

Then you start diving into the terminal world. You've got semi-integrated models, fully integrated models, certification paths everywhere that a transaction needs to go, fallback.

When I talk to a lot of software companies about expanding their stack into a card-present world from a card-not-present world, especially the ones that are already using a third-party vendor for their card-present piece but have aspirations of making the user experience slightly better or cutting their costs, I always say, “Hey, look, I'm going to rattle off 10 terms that have to do with card present. If you can define all of those, I'll give you the roadmap to doing this.”

But it's a magnitude of complexity greater than what you'd experience in a card-not-present world.

So Lori, at the practical level, as somebody who's done this a million times, what is an ISV actually having to certify? And why does that become such a big deal and such a time-consuming headache for them?

Lori Rainery: Absolutely.

When we first found out EMV was going to be implemented, the first thing we thought was from the time that the card number hit the point of sale to the issuer through all the gateways, right? That's what we needed to certify.

But then very quickly, we learned that you have to certify from the device all the way to the issuer.

What that means is if you change out that device—say you have an Ingenico one day and a PAX the other day—you now have to recertify your entire point-of-sale system using that next device.

And then don't even get me started on PINless debit and debit, right?

If you're going to be accepting those two, that's a whole other level of certification that's not included in your EMV certification.

And if 9F10, which is the tag that the issuers like to give everybody, isn't in alignment with the rest of the card message, it'll just go in circles at that point. You'll be QAing for probably two years.

Jason: You mentioned 9F10, and for those who don't know what that actually is, the card networks predominantly work under the hood on a spec called ISO 8583.

When we all adapted this concept for EMV, there's a plethora of new data points that there weren't enough fields in the existing message format to support.

So somebody came up with a brand-new format—or recycled a format that was already out there for the payment space—called TLV.

And now we've got wonderful old field 55, which is a concatenation of God knows how many parameters on top of the initial ISO 8583 spec.

So it's literally like we have a spec within a spec at this point when we're dealing with the card-present space.

Lori Rainery: Absolutely.

And if ISO 8583 isn't complicated enough as it already is, right?

In my implementation team, when I was leading it, we actually created an app that would help parse out field 55.

Otherwise, you were tapping your arrow on your keyboard going, “One, two, three, four, five, six, seven, eight,” trying to figure out how many characters were supposed to be a 9F10 based on a spec that we were given on paper.

So we quickly realized we had to create an internal app that would help us debug those things because 9F10 was our biggest concern as we were going through the EMV certifications.

Kitty: So when somebody says, “We want to support three terminals and maybe two processing relationships,” they may hear flexibility and you hear projects.

Lori Rainery: Yes.

Oh my goodness, that would probably take a team of about 15.

You'd have to have the relationship because you can't just walk into Visa and say, “I'd like to EMV certify.” That's not a thing.

Overall, I think going to an expert is super helpful because the expert has already done it multiple times. They have the lessons learned and they're able to guide you in the way that you need to be guided.

Because that is just a plethora of projects.

Kitty: And we don't need to turn this into an EMV certification school, but the important part for the software company is that there's a difference between technically integrated and ready to safely process transactions in production.

Jason: Yeah. And this is where architecture decisions start having a very real cost.

If you add another device, another processor, another route, depending on how that solution is designed, you're most likely just adding additional certification work.

Lori Rainery: Exactly.

When you're looking at your point of sale and you say, “Okay, I like this specific gateway because it's going to give my merchant, that I know is going to bring me X amount of dollars over the next five years, fewer points per merchant,” I'm now going to have to recertify that entire path from the device to the issuer.

So you're just in constant EMV certification.

Kitty: All right, let's talk about security.

An ISV that's been card not present may already have a PCI program and feel like they understand their environment.

Then physical devices arrive.

What changes then?

Lori Rainery: Oh, wow. There are so many things.

Where the device is sitting, how the device is secured, how often the device gets firmware updates.

If you have a software development kit between the device and your point of sale, and you're not going directly from the device to the issuer, then you also have to make sure that you have no vulnerabilities.

Jason: Yeah, and on top of that, for ISVs that are going from a card-not-present to a card-present world, there are controls around inspecting the device for tampering.

You're dealing with PIN blocks that you're not inherently dealing with in card not present.

Great segue into one of the most important business decisions when it comes to EMV certifications and card-present devices.

There are key-management protocols that really bind that device to a particular processor, on top of a whole slew of expanded scope that goes along with how you're dealing with cryptography.

Kitty: Let's get into something every executive understands, and that's money.

The payment went through. The customer got approved. Everything looks successful.

And you can still have processed that transaction badly.

Lori Rainery: When you're looking at liability from an ISV's perspective, there are multiple ways that you can think everything is working just fine, and then at the end of the month you could see fines or fees from the card brands.

What I mean by that is there's technical fallback, but then there's also another type of fallback where the data will go to the card brands. It will appear to have processed, but then on the back end it didn't get the correct tags in field 55 that we were just talking about.

So when the card either tapped or inserted, something went awry.

The other thing is if you have two or three technical fallbacks, I believe, you then have to swipe, which is a whole other process of that certification.

Because when you swipe, you have to make sure that the issuer knows that it's coming from a technical fallback and not just a swiped card that doesn't already have a chip.

And every single card pretty much has chips nowadays. Even more today, that would be harder not to get hit with fines.

Jason: Yeah, and this is one of my favorite examples of hidden cost and scope creep when it comes to payments.

A lot of organizations will look at how much they think the project is going to cost them, and they pay a team to get the integration done.

The team comes back and says, “Hey, it works, right? We're good to deploy.”

And months later, you've got the finance folks saying, “Hey, this is costing us way more money than what we modeled,” from an interchange perspective, from a downgrades perspective.

I think there's a drastic misunderstanding and oversimplification about the amount of data that is actually going along with the card-present transaction compared to a card-not-present transaction.

And if that messaging format isn't correct, it opens up all of the scary things that you were scratching the surface on.

The other thing I just wanted to jump back to, because I think it really deserves a little bit more time in this conversation, is the key-injection process and what that actually looks like.

It's one of those topics that doesn't come up until you've perhaps done your EMV certification. Your initial device is injected with a test key, and now it comes time for deployment and hardware fulfillment.

Let's just focus on the key-injection side of things.

Every one of these devices that's going out the door is injected with a unique key for that specific device that's derived from what's called the base derivation key.

And he who holds the BDK is the only one who can do the mathematical calculations to decrypt that encrypted payload.

I feel like ISVs and people who are doing this for the first time don't understand that complexity, and also don't understand the shortcomings of the “who owns that BDK?” decision.

Let's say they've got 5,000 devices deployed and they want to change from processor A to processor B.

What does that look like?

Lori, if you could shed some light on some of those topics.

Lori Rainery: Oh my goodness. That brought back such a crazy memory, Jason.

Kitty: I don't know if you saw my face, but I did. I was waiting for it. I was like, what is she thinking about right now?

Lori Rainery: Oh my goodness.

Okay. Do you remember Dejavoo devices?

We had put them in—I don't remember if it was laundromats or car washes—and the BDK changed.

Somehow, we figured out how to update that with Monty specifically. He was the C-level at Dejavoo.

He and I, and I believe there was one other gentleman on my development team, came up with a way that he could go to every individual device and update that key physically.

So he had to go to seven states because otherwise they would have had to remove all those devices, bring them back in-house, update that BDK, and then redeploy them.

It was actually a funny thing. He sent me a picture of my picture hanging up in their lobby because after we were able to solve for that, he blew up my LinkedIn picture and put it up in their lobby in their office to show his appreciation.

Because you're so right, Jason.

Oh my gosh, I had totally forgotten about the fact that that was a test key when you're certifying and then you have that immediate production key.

And then if you skip that whole step—and then when you certify, you have—oh my goodness, there's so much paperwork too.

It's all coming back to me now.

Kitty: Now let's talk about the least glamorous part of card present, and that's the box.

Software companies are used to deployment meaning you push code, enable a feature, or tell somebody to download an app.

But now you've got a physical device.

Walk us through what has to happen between an ISV saying, “This merchant needs a terminal,” and that merchant actually taking their first payment.

Lori Rainery: That's a great subject to talk about because when EMV first hit the country, you know what the least glamorous conversation I had was?

“Do you have a power strip near where we can put a device?”

Right?

Because many ISVs have these very beautiful tablets. They have software on them. They can tap and go. We can move on with our lives.

But now you have a device. Now you need a power cable. Now you need internet access.

Do you have that?

And I feel like once we started that conversation, we then went down the rabbit hole.

When you purchase devices from a payment-device company such as PAX or Ingenico, you have a chain of custody from the time that it leaves the manufacturer to the time it hits your hand.

Then once you get the device plugged in and you have everything where you think you're set up, you now have to do test transactions.

Kitty: I was going to say, you get your box, that arrives, and that's not going to work perfectly forever.

You're going to have to troubleshoot. You're going to have to set it up. You're going to have to make sure you know what you're doing and everything reflects what it should.

Lori Rainery: Exactly.

Jason: Let's not discount that the average merchant, depending on what vertical they're in, might not be technologically sophisticated.

On top of them opening the box, there's a support team that needs to answer the phone when they say it's not working.

Somebody has to support that.

Somebody has to support the Bluetooth pairing of the device to the iPad, or whatever device the ISV is deploying for the POS solution.

So there's a tremendous amount operationally that, again, much like key injection, I feel is underestimated and understated when groups say, “Hey, we're going to go do this EMV thing and deploy our own terminals.”

Lori Rainery: There are just so many boxes you have to check.

When you go from card not present to card present, you really need a team to support you.

Kitty: Well, let's end it there because I'm sure we've absolutely scared a few software companies already with that one.

The point of this episode isn't that an ISV shouldn't bring card present in-house. There are some very good reasons to want more control over the experience.

But if a founder, a product leader, or payments leader is listening and considering it right now, what would you want them to figure out before they make that decision for themselves?

Lori Rainery: Know your customer.

Make sure that your customer is on the same page as you and has the same education as you.

That was a huge lesson learned.

We were shipping devices, ISVs were shipping devices out to customers, and customers had no clue what they were doing.

They were going from tapping on an iPad to now having a complete device sitting on their counter, which you couldn't take to a table.

Understand the certification responsibilities. Understand your security responsibilities.

You have chain of custody. You have firmware updates. You have security updates.

Not only does your point of sale have to have all of that, but now your devices have to have that.

Design for long-term flexibility.

You're not always going to want to go through the same gateway. Other gateways are going to have better incentives for those specific customers.

And when you think about that, you're going to now go through an entire program of EMV certification from the time that the card touches the device until it gets to the issuer.

It doesn't matter if there are seven gateways in between. You have to call all of them.

So you have to think about, before you jump into this world, how much you're willing to take on, how much you're actually able to take on, and then how that cadence is going to work year over year.

Jason: Yeah, and Lori, I'll add one thing.

The thing I hear the most when somebody approaches me about the consideration of doing this in-house is, “Hey, I heard from XYZ that if I convert these in-person transactions from a card-not-present rate to a card-present rate, I'm going to save 50 basis points over what I'm paying today.”

And that may be totally accurate.

But you've got to be processing tens of millions, hundreds of millions of dollars for that 50-basis-point savings, and you have to be able to convert all of that volume from card not present to card present for that 50 basis points of savings to actually offset what the cost of doing this in-house is.

So my message to the ISV community would be: really put a lot of thought into understanding this decision before you get married to it.

Because card present has a way of turning a business decision that looks like a project into lifetime infrastructure.

Lori Rainery: Agreed.

Infrastructure is key to that too.

You have to build for the future. You can't just build for now.

Kitty: And I think that may be the big takeaway from this whole conversation.

When everything's online, payments can feel like software.

And card present reminds you very quickly that payments are actually infrastructure.

There are devices. There are keys. There are certifications. There are security requirements. There are so many logistics.

And if you want to own the customer experience, you need to understand which pieces of that infrastructure you're signing up to own with it.

Now Lori, before we let you go, I want to bring this back to what you're doing now.

A lot of the ISVs listening are also trying to figure out where AI and automation can actually make their business better, not as a shiny new demo, but in the workflows that eat up time every day.

Where does Polaris Crescent come in? And how are you helping companies make that practical?

Lori Rainery: That's a great question.

Currently, we're helping companies understand what AI is.

So that education of understanding what agentic AI is versus machine learning versus autonomous AI—there are multiple buzzwords roaming around.

Many companies are like, “Oh, well, I'm just going to layer AI over top of my unstructured data.”

We have to look at that infrastructure. We have to look at that enterprise architecture and then help transform that data into something the AI can use.

So really, Polaris Crescent is looking at that transformation piece and sitting alongside organizations to help build that foundation, then layer AI in and see if AI is what is necessary.

Just like card present versus card not present: is it necessary?

Do your customers expect you to have AI in your product? If yes, why?

Is there machine learning? Is there a bot that we can bring in—an agentic bot—but not truly AI?

That's really where we're helping them identify those high-friction workflows.

Does it make sense to layer AI?

And then, how do we layer AI?

Kitty: So if you're an ISV trying to automate the messy parts of your business, give Lori a call.

And if you're trying to get your EMV certification done, maybe don't call her for that anymore.

Jason: Yeah, I'm pretty sure she's retired from that chaos.

Kitty: We dragged her back for this one episode.

I want to say thank you both so much for being on Cents Chat with us today. It was awesome having you guys.

Lori Rainery: Thank you.

Jason: I'm just disappointed I didn't get to bust out the cryptography diagrams.

Kitty: I know you're disappointed, but I think everybody else at home is going to be thanking me for it.

Thank you so much, Lori.

And everyone, thank you for listening to Cents Chat. We'll see you guys soon.

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.