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: There was a time when payments felt almost simple. You had card present. You had card not present. The card was either there or it was not. A terminal was a terminal, a website was a website, and a wallet was something you carried, not something embedded in a phone, wrapped in tokenization, routed through five standards, and reviewed by Apple before it could even accept a sandwich payment.

That was cute while it lasted.

Jason: Yeah, Kitty, cute is exactly the way to describe it. Today, that clean little line between card present and card not present has turned into a very expensive gray area. We've got contactless, 3D Secure, Apple Pay, Google Pay, network tokens, wallet cryptograms, and whatever they dream up next. There's a pile of standards that all technically make sense until you try to build the thing.

Kitty: And that's where the story gets interesting for ISVs, because ISVs are building really good software: field service apps, healthcare apps, event apps, restaurant apps, retail apps, mobile checkout apps, all kinds of commerce workflows where the customer and the merchant are often standing right next to each other. But somehow the payment still gets treated like it is e-commerce.

Jason: And that's the problem Koard is going after.

Kitty: Welcome back to Cents Chat. Today we're talking about Koard and specifically what happens when the phone stops being just the checkout device and starts becoming the terminal. Jason is back with me for this one because this topic is technical in exactly the dangerous way payments topics love to be technical. The merchant experience looks simple: tap the card, approve the payment, move on. Underneath that tap, though, there's a whole machine running.

Jason: Yeah, Kitty, the clean user experience is doing a lot of hiding. When a transaction is card not present, an ISV can often get pretty far with a gateway API, some hosted fields, a little bit of tokenization, maybe some card on file, or a cute little payment link. That can still be complicated, but it is familiar software work. Card present is a different animal altogether.

Now you're dealing with EMV, contactless acceptance, device eligibility, terminal profiles, processor certifications, cryptography, app store requirements, wallet behavior, transaction messaging, and all the fun little details that appear after someone says the word seamless.

Kitty: And that's the core tension. ISVs are inventing awesome technology. They're putting payments into workflows that used to happen on paper, at a counter, or in a follow-up invoice. But for a lot of them, card-not-present payments are just easier to launch than card-present payments. No EMV certifications, fewer hardware decisions, fewer data points, less coordination with devices, processors, and operating systems.

So even when the customer is physically standing there, the platform ends up using an e-commerce-style payment because that's the path that does not derail the roadmap.

Jason: And the roadmap decision becomes an economic decision later. The card brands keep adding cost pressure around digital commerce and card-not-present activity. We've talked a lot about this on the Cents Chat blog: little network fees, digital commerce fees, token-related fees, card-not-present-specific fees. They just keep adding up.

Some of the newer fee updates around Visa and Mastercard digital commerce are a reminder that card not present is not just operationally different. It can be economically different too.

Kitty: Merchants do not care what the fee is called. They care that their costs went up. And platforms care because higher CNP cost pressure can squeeze merchant margin, platform monetization, and payment pricing strategy.

So if a transaction is truly remote, fine. The card is not present. But if the customer is physically present and the app is already part of the in-person workflow, it is worth asking why the payment is being treated like e-commerce.

And that brings us to Koard.

Koard is building infrastructure that helps software platforms bring modern card-present acceptance into mobile apps without asking every ISV to become an EMV certification shop, an Apple approval expert, and a cryptography team all at once.

Jason: Yeah, Kitty, and that's the part I want to underline. Koard is not just making a nicer checkout button. They're trying to make the acceptance layer more accessible. Tap to Pay on iPhone and Android, SDKs, white-label mPOS, processor routing, onboarding support, and the operational pieces around making a phone behave like a real acceptance device. The product story is simple. The infrastructure story, not so much.

Kitty: So today we're joined by Behailu from Koard on the technical side to talk about why this problem exists, what Koard is solving, and what it means for ISVs that are tired of treating in-person payments like remote checkout.

Behailu, welcome to Cents Chat. Before we get into the weeds, I want to start simple. Give us the quick version of what you do at Koard and what Koard is actually building.

Behailu: Sure. Hey Jason. Hey Kitty. Thanks for having me on. Happy to talk a little bit about what we're doing here at Koard. My role at Koard is I'm the CEO, but I do pretty much everything related to technology and product. With the original version of Koard, I managed our clients.

So in a nutshell, what Koard is, is we are a solution that enables merchants to accept payment on their phone without having to use dongles or an extra piece of hardware, treated as a card-present transaction end to end. And we provide SDKs that enable app developers or payment processors, saving them months to years of their time and helping them go to market in a matter of weeks.

Jason: Yeah, Behailu, and you have massively downplayed the amount of technical infrastructure you guys have had to build in that intro. I'm mostly going to play technical translator today. If something sounds easy on the surface, I'm here to point out the machinery underneath and make everyone slightly less relaxed.

Kitty: That's a valuable public service. Thank you, Jason.

Now let's start with the problem. A software platform has a mobile app. The merchant is using that app in the field, in a store, at an event, or at the end of a service call. The customer is right there. So in theory, that should be a great card-present moment. But in practice, a lot of platforms still send a payment link, key a card, store a card, or process through an e-commerce flow.

What makes true card-present acceptance so much harder for an ISV to build than a normal e-commerce payment flow?

Behailu: Yeah, that's a great question. There are actually several flavors to this problem. For an app developer or an ISV, someone who provides services to merchants, there's one problem where they're going to have to go through the process of integrating the solution into their app and offering Tap to Pay.

For a lot of these ISVs, they have multiple acquiring relationships. They have to go through the heavy lifting of actually going to market with Apple, getting the approval for Tap to Pay. They have to go through Apple's review process. They have to integrate an Apple and Android ecosystem into one unified platform with a shared experience across merchants who have both iOS and Android.

What we did is basically build a unified acceptance experience that is acquirer agnostic. They can integrate our SDK, board their merchants onto our platform, and go to market quickly.

There's a lot that comes with that advantage. It helps prevent the ISV from being locked into one singular platform and lets them get the optionality to move across different acquirers. They can focus on the best relationship they have. We also help with the whole process around entitlement across Apple and Google, and figuring out the user experience end to end to make sure that merchants, no matter how unsophisticated they may be, can actually run Tap to Pay end to end.

There's a second flavor to this as well where maybe you're not talking about ISVs, but you're talking about payment processors that want to offer Tap to Pay to their merchants or to their ISVs. Right now, if you do not have an existing relationship with Apple, you're going to have to go to a third party. We can help these payment processors get their L3 certifications end to end with Apple and Android seamlessly.

And if they do have an existing relationship with Apple, they're looking at anywhere from one to two years just to go through the process before they can even go live to offer their services as Tap to Pay for iOS and Android.

Jason: Yeah, Behailu, you really hit the key distinction here. Card not present is usually just software talking to payments infrastructure. Card present is a totally different ballgame. It's software, hardware, card network rules, processor specs, and a whole bunch of security requirements all meeting at the same exact moment the customer taps.

A normal developer integration can fail politely in a sandbox. A card-present integration can fail in front of the customer holding a phone over another phone while a merchant wonders whether the payment went through. That's an entirely different kind of pressure.

Kitty: And from the business side, that pressure does not stay in engineering. Where do you see this showing up most often? What kind of platforms or merchant workflows are running into this gap between what they want the payment experience to be and what they can actually launch?

Behailu: This is going to be applicable to any in-person service. You can have field service technicians who are going out to a household and they do not want to have to carry around a dongle. They can accept the payment from the homeowner right there.

Or you're in a healthcare office that's going to collect co-pays in person. You do not want to have to use a bunch of extra hardware. It is a fairly simple transaction.

Or a retail associate, let's say at Sephora or a luxury brand, where people do not want to have to go through a line with 50 other people in front of them. They have a singular person helping them through the process of purchasing, and they can just pay for their items right there and then get right on out.

Or restaurants or bars want to have tabs. Delivery services. It's everything.

When you have a situation where a person has their phone or has their plastic card and they tap it at the merchant's phone, or they have an Apple Watch with any sort of form factor, we're able to actually run those authorizations. There's a benefit to doing that for card present versus card not present.

As Jason mentioned, with card present, you also get the benefit of higher authorization rates. You're paying lower interchange. You get lower chargebacks because the verification check is actually a lot more strict for card present. You have to have the card with you rather than knowing what the card information is for card not present.

The real issue is that the commerce experience has become mobile, but the payment architecture has not really caught up yet.

Kitty: And that's such a clean way to say it. The commerce experience moved. The payment architecture stayed behind.

And when that happens, the workaround becomes normal. The technician sends a link, the front desk keys a card, the event seller uses a separate reader, the platform owns the workflow until the exact moment money needs to move, and then everything gets weird.

Jason: Yeah, and that weirdness becomes technical debt with interchange attached.

Kitty: Let's talk about what Koard does that makes this easier. Koard talks about Tap to Pay on iPhone and Android, an SDK, white-label mPOS, processor routing, and support around the Apple process. Those are a lot of words that sound simple only if you have never had to ship the thing.

When a platform integrates Koard, what are the big pieces they are not having to build alone?

Behailu: That's a great question. What Koard is at the heart is a singular mobile SDK that people can embed into their Android and iOS apps. What we cover is the process from enrolling and preparing the device to be ready to accept a card payment.

Then when someone taps their card, phone, or watch to the phone, we're able to re-encrypt that card data, take that card data, and send it to our servers, where we then decrypt it. We can decrypt PIN block for PCI PIN and PCI DSS compliance to do all of that. Then we take that and write the authorization to the gateway because we already have all the L3 certifications done.

Now what this means is all any of our customers have to do is they can take this boarding sheet, plug it into our portal, and the merchant can just start accepting payments within a minute without having to do any of the other stuff.

We also do processor routing under the hood. Your merchant can be boarded on any number of acquiring partners, and we're able to route all those authorizations to the right gateway. We handle all the kernel and terminal profile configurations.

Jason: Yeah, and this is where the word SDK can become very misleading. Developers hear SDK and think, install a binary, call a function, ship the feature. In payments, SDK is often just the visible edge of a much bigger operating model. The tap is in a moment. The acceptance stack is the system around that moment.

Kitty: That makes the Apple piece especially interesting because Tap to Pay on iPhone sounds like something that should be simple for an app developer, but Apple is not just handing out a magic NFC button and wishing everyone luck. What do platforms tend to underestimate about the Apple side?

Behailu: Typically, the challenges with the Apple integration are not necessarily just technical. There are a lot of fundamental problems that go beyond that, like operational support.

The entitlement request to Apple is manual. As a payment processor, you have to go to Apple directly and get a payment processing agreement with them, which can take several years if you do not have someone handholding you through the process.

Then you have to conform to Apple's UX requirements and the human interface guidelines. You have to have a very clean and distinct way of messaging around Tap to Pay on iPhone. Apple is incredibly strict about that. You also have to embed merchant education into the app. All of the merchants have to accept the terms and conditions set by Apple. There needs to be a very clear flow for how you do that.

Then there are all the things around the App Store submission. You have to submit a video of the merchant being onboarded. You have to submit a video of a transaction and the merchant education. Once you get through all of that, then you have to go through the App Store submission review process.

There are a lot of steps that Apple provides as part of this, and we have seen a lot of partners struggle to make it through end to end, even if they're just an individual app developer. The amount of details required on the Apple side are pretty intense. A lot of the technical details are also similar to how Android handles things as well.

Part of our value prop as a company at Koard is not only that we provide the technology, the end-to-end acquiring relationships, the SDKs, and the product operations. We also help our partners identify blockers and issues before their submissions so they do not have to go back and forth with Apple. We help them figure out their press release, their messaging, how they can design their websites to conform to Apple's Tap to Pay readiness guidelines, and what their payments experience is going to be so it does not become a fire drill.

Kitty: Now let's get into the economics and risk side. One of the reasons this matters is that some transactions sitting in card-not-present flows may not really belong there. The customer is present, the merchant is present, that app is present, but because card-present acceptance was too hard to integrate, the platform used an e-commerce-style path.

Behailu, where does it make sense to shift those payments into a Tap to Pay or card-present flow?

Behailu: That's a great question. These are going to be scenarios that are essentially attended terminals. The customer and the merchant are both together. They're in the same room. The merchant already has a mobile app or they have their phone with them.

Payment can be done when the person checks out for retail or at the completion of a service, picking up delivery, the end of an installation sale, or some sort of tableside or barside interaction.

That's where you go into the scenarios around a skilled service technician, a healthcare office receptionist, a retail associate, delivery, installation, restaurant, or closing out a bar tab. Card present really fits because in those scenarios, the customer is obviously going to have their phone, card, or watch. They're not going to need to read their card number over the phone or type it into a form.

The goal is the correct classification. We're not forcing every payment into one model or card not present.

Jason: Yeah, Behailu, that caveat matters. The trick is not pretending remote payments are card present. That would be a compliance bonfire with nicer branding. The legitimate opportunity is when the real-world transaction already has the ingredients of card present: customer, merchant, device, and payment instrument all in the same place at the same time.

In those cases, using a card-not-present flow just because it was easier to integrate can create avoidable costs, risks, and experience problems.

Interchange is not one simple number. It depends on card type, region, MCC code, the network, transaction data, authorization method, and program rules. But the basic point stands: card present and card not present are treated differently, and that classification has real business consequences.

Kitty: Now let's zoom out. Tap to Pay is interesting on its own, but it also points to something bigger. For a long time, the point of sale was a place. Then it became a system. Now it's becoming capability inside software.

The same phone can be the merchant interface, the checkout device, the acceptance device, the receipt tool, and part of the operating workflow.

Behailu, where do you see this going over the next few years?

Behailu: Over the next few years, we're going to see point of sale become more software-defined. Hardware is obviously never going to completely disappear, but most use cases are going to be solved by the phone-first scenario.

Platforms are going to expect acceptance inside the tools merchants already use. We're going to see Tap to Pay expand access across small merchants, mobile sellers, field teams, events, ticketing, line busting, and service-based businesses.

As a result, the infrastructure is going to need to grow for cross-platform support, processor flexibility, security and compliance, better reporting, reconciliation, and cleaner and more well-defined embedded risk controls.

Our long-term vision at Koard has always been to make in-person acceptance more programmable and easier for platforms to launch.

Jason: Yeah, that's the takeaway for the technical audience. The phone is becoming the terminal, and that does not just make the stack disappear. It moves the stack closer to the software product. That is the good news if the platform has the right infrastructure. It is the painful news if the platform treats it like a checkout shortcut.

Kitty: And that's really the whole story. The line between card present and card not present did not disappear. It just got more complicated.

Koard is interesting because they're helping platforms deal with the complexity without making every ISV build the full acceptance stack themselves. For merchants, the experience can be simple: open the app, tap the card, finish the sale. For platforms, the strategic question is bigger.

Are you processing the payment in the way the commerce actually happens?

Behailu, thank you so much for joining us.

Behailu: Thank you guys both for having me. Tap to Pay is super powerful, but the infrastructure behind it is going to be what really matters and how you differentiate in the market. We're going to be helping everyone launch faster and hopefully be a part of what the future of payments is going to be. We're super excited about it. Thank you guys.

Kitty: And to everyone listening, the next time someone says, can we just add payments, maybe send them this episode before the roadmap meeting gets expensive. This is Cents Chat, and I'm Kitty.

Jason: And I'm Jason.

Kitty: Thanks for listening.

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