SPEAKER_03 0:00

Welcome to SpenceCat. The podcast where payments meet personality. Protect trends to legal twist. Compliance quirks to marketplace moves. It is here to keep ISVs, PayPal's, and marketplaces ahead of the curve. Get ready for insights, a few laps, and the occasional compliance gear. Let's dive in and make payments make sense.

SPEAKER_00 0:23

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 wasn't. 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.

SPEAKER_02 0:43

Yeah, Kitty, cute's 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.

SPEAKER_00 1:10

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's e-commerce.

SPEAKER_02 1:30

And that's the problem Cord is going after.

SPEAKER_00 1:33

Welcome back to Sunshine. Today we're talking about Cord 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 technically and 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.

SPEAKER_02 1:55

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's familiar software work. Card present is a different animal altogether. Now you're dealing with EMV, contact list 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.

SPEAKER_00 2:36

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 doesn't derail the roadmap.

SPEAKER_02 3:04

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 SenseChat 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 the Vista and MasterCard digital commerce are a reminder that card not present is not just operationally different, it can be economically different too.

SPEAKER_00 3:34

Merchants don't 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's worth asking why the payment is being treated like e-commerce. And that brings us to Court. Court 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.

SPEAKER_02 4:11

Yeah, Kitty, and that's the part I want to underline. Court is not just making a nicer checkout button. They're trying to make the acceptance layer more accessible. TAF to pay on iPhone and Android SDKs, white label MPAs, 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.

SPEAKER_00 4:37

So today we're joined by Bahailu from Cord on the technical side to talk about why this problem exists, what Cord is solving, and what it means for ISVs that are tired of treating in-person payments like remote checkout. Bahailu, welcome to Sunshot. Before we get into the weeds, I want to start simple. Give us the quick version of what you do at Cord and what Cord is actually building.

SPEAKER_01 4:55

Sure. Hey Jason. Hey Kitty, thanks for having me on. Happy to talk a little bit about what we're doing here at Cord. So my role at Cord is I'm the CEO, but I do pretty much everything related to technology and product, without the original version of Cord, you know, managed our clients. So it says in a nutshell, what Cord is, is we are a solution that enables merchants to accept payment on their phone without having to use dongles or 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, you know, months to years of their time and going to market in a matter of weeks.

SPEAKER_02 5:29

Yeah, Bahailu, 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.

SPEAKER_00 5:49

That's a valuable public service. Thank you, Jason. Thanks, 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?

SPEAKER_01 6:17

Yeah, that's a that's a great question. There are actually like several flavors to this problem. So for an app developer or an ISP, right, someone who provides services to merchants, there's one problem where they're gonna 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 Tap2Pay. They have to go through the process of getting through Apple's review process. They have to go through the process, you know, integrating an Apple and Android ecosystem and one unified platform with a shared experience across merchants who have both iOS and Android. And what we did is we basically built a unified acceptance experience that is acquire agnostics and integrate RSDK or their merchants and bar sheets onto our platform and just go to market within a matter of minutes. There's a lot of things that come with that advantage, right? Sort of preventing the ISP from being locked into one singular platform, but let they get the optionality to move across different acquirers. They can focus on a the best relationship that they have. We also help with the whole process around entitlement across Apple and Google, figuring out the user experience end-to-end to make sure that the merchants, no matter how unsophisticated they may be, can uh 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 taking talking about painter processors, right, that want to offer tap to pay to their merchants or to their ISVs. Right now, if you don't have an existing relationship with Apple, you're gonna have to go to a third party. We can help these painter 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 to have to pay for iOS and Android.

SPEAKER_02 8:08

Yeah, but Hyli, 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.

SPEAKER_00 8:46

And from the business side, that pressure doesn't 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?

SPEAKER_01 8:58

This is going to be applicable to any in-person service, right? So you can have field service technicians who are going out to the household and they don't want to have to carry around a dongle. They can accept the payment from, you know, the house owner right there. Or you're in a healthcare office, right? That's going to collect co-pays in person. You don't want to have to use a bunch of extra hardware. It's a fairly simple transaction. Or a retail associate, uh, let's say like a Sephora luxury brand where people don't want to have to go through lineup to fifty other people in front of them. Right? 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. And so when when you have a situation where you have a person who has their phone or has their plastic card and they tap it at the merchant's phone, or they're they have an Apple Watch, right? With any sort of form form factor, we're able to actually run those authorizations, right? There's a benefit to doing that for card present versus card not present, right? As Jason mentioned. With card present, you also get the benefit of higher authorization rates. You're paying lower interchange, you get lower charge back just because the the verification sheet is actually a lot more strict for card present. You have to have the card with you rather than uh knowing what the card information actually is for a card not present. And the real issue is that the commerce experience has become mobile, but the payment architecture hasn't really caught up yet.

SPEAKER_00 10:22

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

SPEAKER_02 10:41

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

SPEAKER_00 10:45

Let's talk about what Cord does that makes this easier. Cord 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 simply, only if you have never had to shift the thing. When a platform integrates Cord, what are the big pieces they're not having to build alone?

SPEAKER_01 11:06

That's a great question. You know, what Cord is at the heart a singular mobile SDK that people can embed into their Android and iOS apps? And what we cover is process from enrolling and preparing the device to be ready to accept a card payment. And then when someone taps their card or their phone or their watch to the phone, we're able to re-incrypt that card data, take that card data, send it to our servers, where we then decrypt it. We can decrypt pin block for PCI pin, PCI DSS compliant to do all of that. And then we take that and then write the authorization to the gateway because we already have all the L3 certifications done. Right. So now what this means is all any of our customers have to do is they can take his bar 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 actually route all those authorizations to the right gateway. And we handle all the kernel and terminal profile configurations.

SPEAKER_02 12:07

Yeah, and this is where the word SDK can become very misleading. Developers hear SDK and think, eh, install a binary, call a function, chip 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.

SPEAKER_00 12:27

That makes the Apple piece especially interesting because Tap2Pan iPhone sounds like something that should be simple for an app developer, but Apple isn't just handing out a magic NFC button and wishing everyone luck. What do platforms tend to underestimate about the Apple side?

SPEAKER_01 12:41

Typically, the the challenges with the Apple integration isn't necessarily just technical, right? There's a lot of fundamental problems that go beyond that, from like uh, as I was saying about the operational support, right? The the entitlement request to Apple is manual. As a payment processor, you have to go to Apple directly, get a payment processing agreement with them, which can take several years if you don't have someone handholding you to the process. Then you have to have conform to Apple's UX requirements, the human interface guidelines. You have to have like a very clean and distinct way of the messaging around to have to pay on iTunes. Apple's incredibly strict about that. And then you have to embed merchant education into the app. You have to have uh all of the merchants accept the terms and conditions set by Apple. There needs to be very clear flow on how you do that. And then there's 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, the merchant education. Once you get through all of that, then you have to go through the app store submission review process. There's a lot of steps that Apple provides as part of this, and we've seen a lot of partners struggle to make it through end-to-end, even if they're just uh an individual app developer. The amount of details that are required on the Apple side are pretty pretty intense. You need to make sure that you handle all of that. And a lot of the technical details are also similar to how Android handles things as well. But uh yeah, like there's a lot of uh things that need to be done. Part of the our value prop as a company accord, right, is not only do we provide the technology, not only do we provide the uh end-to-end acquiring relationships, the SDKs and all the product operations that we do. We do help our partners identify blockers, identify issues, you know, before their submissions so they don't have to go through back and forth Apple. We help them figure out their press release, we help them figure out their messaging, how they can design their websites to conform to Apple's top-to-pay readiness guidelines. We help you guys figure out, you know, what your payments experience is going to be, and it's not going to be a fire drill.

SPEAKER_00 14:39

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. But Hailu, where does it make sense to shift those payments in a to a tap to pay or card present flow?

SPEAKER_01 15:03

That's a great question. So these are going to be scenarios that are essentially attended terminals. So 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. And payment can be done either, you know, when the person checks out for a retail or at the completion of a service, you know, picking up delivery, the end of an installation sale, or some sort of table side or bar side interaction. So that's where you go into the scenarios around, let's say, skill service technician or healthcare official, receptionist, retail associate, uh delivery, installation, restaurant, closing out a bar tab. And card presence really just fits because in those scenarios, the customer is obviously gonna have their phone or they're gonna have their cards, they're gonna have their watch, they're not gonna need to read their card numbers over their phone or type in a form. And the goal is uh the correct classification. We're not forcing every payment into one model or card not present.

SPEAKER_02 16:01

Yeah, by when 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, auth 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.

SPEAKER_00 16:56

Now let's zoom out. TapsiPay 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 the part of the operating workflow. Bahilu, where do you see this going over the next few years?

SPEAKER_01 17:17

Over the next few years, we're gonna see point of sale become more software-defined. Hardware is obviously never going to completely disappear, but the most use cases are going to be solved by the phone first scenario. Platforms are gonna expect, you know, acceptance inside the tools merchants already use. And we're gonna see Tap to Pay expand access across small merchants, mobile sellers, field teams, events, ticketing, line busting, service-based businesses. And 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 CORID has always been to make in-person acceptance more programmable and easier for platforms to launch.

SPEAKER_02 18:05

Yeah, that's the takeaway for the technical audience. The phone is becoming the terminal, and that doesn't 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's the painful news if the platform treats it like a checkout shortcut.

SPEAKER_00 18:23

And that's really the whole story. The line between card present and card not present and disappear. It just got more complicated. Court 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 and the way the commerce actually happens? Bahilu, thank you so much for joining us.

SPEAKER_01 18:50

Thank you guys both for having me. Tapit Pay is super powerful, but the infrastructure is behind it's gonna be what really matters and how you differentiate in the market. And we're gonna be helping everyone launch faster and hopefully be a part of what the future of payments is gonna be. And we're super excited about it. Thank you guys.

SPEAKER_00 19:05

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 SenseChat, and I'm Kitty.

SPEAKER_02 19:14

And I'm Jason.

SPEAKER_00 19:15

Thanks for listening.

SPEAKER_03 19:16

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 out a quick survey. You might just land a guest spot on the pod. Don't forget to subscribe, share this episode with your favorite ISP, and follow us on all socials for the latest trends, tips, and debates. We promise no boring slideshows. At FenseChat, we're here to make payments and make sense. And make it fun while we're at it. See you next time.