On this sponsored episode, Ben and Ryan talk to Sunny Patel, Staff Software Engineer at PayPal, and Kyle Prinsloo, a developer and a PayPal partner, about all the ways that Fastlane by PayPal makes developers’ lives easier. They explore the needs that both merchants and consumers have for creating a seamless checkout experience, the importance of reducing friction in payment processes, and how documentation can directly assist the integration experience.
Fastlane by PayPal is an accelerated guest checkout experience. Visit theFastlane Resource Center for Developers to get started.
You can find Sunny Patel on LinkedIn and on GitHub.
Find Kyle Prinsloo on X and on LinkedIn.
Congrats to Lifeboat badge winner M.M who provided an answer to What does the "Expected '(' for function-style cast or type construction" error mean?
[intro music plays]
Ben Popper (BP) Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I'm your host, Ben Popper, Director of Content here, joined as I often am by my colleague and collaborator, Editor of our blog, maestro of our newsletter, Ryan Donovan. Hey, Ryan.
Ryan Donovan (RD) Hello, Ben. How’re you doing today?
BP Good, thanks. So today we have a sponsored episode from the fine folks at PayPal. We're going to be talking about a product called Fastlane, and this is very much in the world of e-commerce, explaining how it was built, the kind of problems it solves for merchants and for their customers, but then specifically, what did they have in mind in terms of making this easy for developers, making it flexible, making it accessible, and kind of digging into the nitty-gritty of some of the technology behind it and why it was architected the way it was. So our guests today are Sunny Patel, who is an engineer that was a leader on this Fastlane product, and Kyle Prinsloo, who is himself a developer and a PayPal partner spreading the word about Fastlane and learning about services like these. So without further ado, gentlemen, welcome to the Stack Overflow Podcast.
Sunny Patel (SP) Thank you, Ben. Thank you, Ryan, for having us here.
Kyle Prinsloo (KP) Pleasure. Great honor to be here, so thank you.
BP So Sunny, let's start with you. Just really quick, can you tell folks how you got into the world of software and technology and what landed you in your current role at PayPal?
SP Software and technology was something that was always a passion of mine. I was that kid that was tinkering with computers at an early age, trying to teach myself how to code. And so originally I’m from the East Coast, moved over here to Chicago, and got in touch with an EM at PayPal and joined the branded checkout team and then got pulled over into this small idea that we had that we wanted to start tinkering with, which has now become Fastlane.
BP And Kyle, how about yourself? Tell folks a little bit about who you are and how you got involved with the world of software and technology as well as with PayPal.
KP So I'm an agency owner, I'm a SaaS founder, PayPal partner, and I've also had e-commerce companies that I've sold and started sort of the general approach as an employee and then went full-time freelance from 2017, and then various different businesses. And then how I got in touch with PayPal was creating some content on YouTube for developers and freelancers, and PayPal reached out, and ever since then, we've been working together.
RD So Sunny, you're a man on the inside here. Can you talk a little bit about why PayPal created Fastlane? What were the problems you all were trying to solve?
SP So we were looking at some market research. We were testing with buyers and trying to explore some of the checkout pages. One of the things that we found was that buyers actually do want to use guest checkout. Another thing was that they do not, though, want to have to continuously keep entering their information on every checkout page. So the cornerstone that got the idea started was how do we solve this problem for a large portion of buyers on e-commerce sites?
BP I'm that customer. I'm like, “I don't want to log in. I don't want to give you too much information. I want to just check out as a guest,” but then it's like, “Oh God, I’ve got to fill out this form. I’ve got to pull out my credit card all over again.” I want to be anonymous, but also known. It's a tricky thing.
SP And the other thing is that your addresses update and your cards update. These things aren't always updated across the board. So seeing this need in the marketplace, we wanted to really try to address it by creating a different product than what PayPal offers. One of the key things I think that we wanted to make sure that we tackled is not taking the buyer off to a separate page. So branded checkout, you click a button and an iframe opens up. So we wanted a solution that's embedded onto a merchant's checkout page, something that kind of works and coincides with what's already there and what they've already fine-tuned, and so that's where Fastlane and that SDK kind of comes into play. So for developers and for merchants, one of the key things that we wanted to keep in mind while building that interface and that SDK is that we need this to be simple, easy to use, flexible, but then also it shouldn't force the merchant or the integration engineer to choose a path that kind of goes against everything else that they have on the page. So really trying to mesh and be a part of the checkout experience instead of trying to redirect the buyer into some different experience.
BP So Kyle, I know you attended PayPal's Developer Day and learned a bit about Fastlane there. Can you talk to us a little bit from your perspective as someone, like you said, who's founded and sold e-commerce companies, who now advises folks who are themselves getting into business or as content creators, what's your perspective on a product like Fastlane?
KP First of all, what PayPal Developer Day was was, in simple terms, a two-day event at the PayPal campus. The whole focus was on Fastlane, I would say how it works, why it works, and then just sort of the coding activities behind it. So in terms of from my side, and I told the team, I'm like, “Why did you only launch this now? Why didn't you launch this when I had my e-commerce business?” I think it's really a good product and a good solution. So I think the three things that stand out to me are, as a business owner or a small business owner, you want payment solutions that reduce friction. So every step of the way on the checkout process, everything that you can reduce or fields, that reduces friction. You also want reliable and trustworthy payments. I think that's a given, but that's not something that can easily be accomplished all the time. And finally, I think you simply want very good conversion rates and I think that is what Fastlane delivers on.
RD I think the focus on the small business owners is an interesting one because the big businesses, they have their teams to do their own integrations, they want all the flexibility, but the little guys, they don't always have the devs to do the integration. Can you talk about how you made the SDK easy for those folks?
SP I think one thing that we saw as soon as we started figuring out and thinking about this SDK interface and what should this thing be and how do integration engineers want to interact with it, immediately it's apparent that small to medium businesses have very different needs than your large enterprises. You start peeling back the onion there a little bit and you realize that small to medium business is exactly as you're calling out. They want something that's easy to use, something that they can just drop in. They don't need to handle all these different edge cases, they just want it to work. On the contrast, you have large enterprises that want the exact opposite. They fine-tune their checkout pages. They figured out exactly for their business, what works well, what their buyers are looking for. So they want the other end of that, which is they want all of the control, they want flexibility. And now we were tasked with how we come up with one SDK interface that kind of solves two ends of a different spectrum. And so we were thinking about this like, “How do we go about it?” Well, we started diving into what are the use cases that make up a checkout page? I’ll kind of take you on a little bit of a history journey here. What makes up a checkout page? We listed these things out. There's a ton of use cases. A lot of those are pretty common across the board for the majority of businesses. And then from that set of use cases, we were like, “Okay, what do we want to tackle?” And when you start dissecting the problem this way, you start to realize that there's things that are very common between SMBs and large enterprises, and then there's pieces where they do need that flexibility and they do want that control or the simplicity. And so our SDK interface approach we took was, all right, let's keep everything that's in common between the two simple and straightforward. Let's try to flatten the learning curve as much as possible. And then where the two kind of diverge, which is more towards the payment component now, that's where things start to diverge for both types of SMBs and LEs. You have a choice, you have a choice of which integration you want to choose. So that was the approach that we landed on and I think that works well, and we did some internal testing like, “Let's see how this works,” and we got some positive feedback on that so I think that's what's out there.
BP Kyle, I'm curious about your experience both with e-commerce companies and then also I know you did some training hands-on at Dev Day. Where do you see the most common areas of friction, like you mentioned, maybe either both from your experience working on this stuff or as a consumer? Like I said, as soon as Sunny started talking about this stuff, I personally relate to it across the board. Talk a little bit about those areas of friction and what you saw at Dev Day that maybe a light bulb went off in your head about, “Oh, okay. I see how they're trying to address this.”
KP Let's start with the friction I would say for the merchants. I think there are two main things that I've noticed. The first one is the time to integrate. I think as a business owner you want to know, here's a solution, how long does it take? So that's the first one. And then I think the main one that I've noticed is sort of a knowledge gap. So I was actually speaking to a client in the UK about two weeks ago, and I actually showed him that this is what we can do on the checkout and they were like, “Wow, when can we implement this?” And I think that a lot of e-commerce business merchants actually don't know that the solution is available, so hopefully we can bridge that knowledge gap from an education side and branding side. And then Sunny touched on it in terms of the customization, I think that's also important in terms of styling, brand guides, all of those types of things. When it comes to, I would say, friction for customers, I think you touched on it really well, Ben. We've all been there. I think we can all agree that we don't like long checkout forms. I’ve forgotten my password a couple of times on signing up to something and then you have to go through that whole process. Then you've got delivery details, you've got shipping details. And another, I'll say, friction point, maybe two, is the reliability of the brands that you see on the checkout process, specifically, and that I think is actually underrated. And also the lack of payment methods. All of a sudden if you've got more payment methods and reputable payment methods, that'll also help increase your conversions. And then when it comes to how Developer Day addressed these points, I wish I can say the whole event addressed it, but I think if I have to maybe highlight two or three of them, I think Mudita's overview, Sunny as well, with us, they had some great sessions. Mudita has a session on the PayPal Developer YouTube channel that I thought was really good from start to finish. Karen, her one was only three or four minutes, but it was so good because she just explained how Fastlane works for merchants and how it's built specifically with developers in mind. And then I think the highlight was the success stories, so you actually get to see it in the wild working because now you can see, “Hey, it's actually a product. People are saying good things about it.” But who actually really cares? What are the results of that? And it was amazing to see the results and the success stories of that.
BP Yeah, the proof points definitely validate it for you before you take the step of deciding, “Okay, I'm going to do this, or I'm going to spend the time on integrating it.” One thing you mentioned there, Kyle, that I did want to touch on, and which I'm sure we'll get to later, Sunny, as we talk through how all this works, is when things change, we had talked about who I am, my login, my password, my credit card, you mentioned your location, and then there's the billing location and the shipping location, and then I move and then all of a sudden those two things don't match up anymore. And I remember going through that for two or three months after I moved, like, “Okay, everybody thinks my billing address is this and my shipping address is that, but now my credit cards in the background, not even all at the same time, but the banks are changing the billing address as they figure out where I live,” and that stuff created a lot of friction for me.
SP Now imagine if you can just log into the Fastlane portal and you can change those places once, just change your billing address, change whatever card you have, your shipping address, update it once, and you have an access to all of the merchants that are integrated to Fastlane and they all have access to the latest data.
RD So I think with checkout as such an important part of the shopping experience, there's some temptation to get into manipulating the domain object model, the DOM or the shadow DOM or whatever other phantom DOMs folks have created, but I think it's interesting that you all did some work to really encapsulate these and stay out of the developer's way. Can you talk about that work?
SP I think we touched on it a little bit earlier. We were talking about kind of dividing the boundary between what do merchants have fine-tuned on their checkout page and what works well, and one thing we didn't want to do is get in the way of that. For things that are working well on your checkout page, we want to stay out of your way as much as possible. And so we were thinking about how we encapsulate these components in such a way that just provides the value without compromising what you already have, without making you make decisions that are kind of one-way doors. So where the shadow DOM kind of worked well for us was that we needed a way to, while living on your checkout page, not influencing other components and other elements that you have on your checkout page and vice versa. I think a good example of that is that we use obviously CSS styles internally. You have CSS styles on your page. We don't want them influencing each other or impacting each other. So this is where shadow DOMs work. That's the technology that all browsers in the JS spec deploy. So that's something that, out of the box, kind of just made sense for us. There are other measures that we kind of took into place, having our components just being accessed by a JavaScript interface so that you have a clean, well-defined interface where you can interact with our components in a well-defined way so that we know how to then respond to those actions. So all of these things kind of tie into us building a set of components that deliver that value without compromising what's already existing on your checkout page or impacting your checkout page too much. So that's where I think shadow DOMs came into play. There's other technologies that we also started using internally that also helped with that goal.
BP I watched your talk from the Developer Day and there was just this discussion of components and using those as a way to avoid messing with the DOM. There's these four key components you mentioned: lookup, authenticate, shipping, and payment. Can you just talk us through these four pillars and how they work inside of Fastlane?
SP The components are SDK modules. So as soon as you initialize Fastlane, you get access to all of these modules. There's more than four, but I think the four at minimum provide the accelerated checkout experience that you're kind of looking for. So the first thing that you want to do in order to accelerate a buyer through your checkout page is identify the buyer. You want to know if this buyer is someone that is recognized before. So if Ben's checking out on my page, I want to know, can I identify Ben? And the first module helps you with that, it's called ‘Lookup.’ So the first module gives you a method to look up the buyer based off of an email. And then if we identify that buyer and we let you know that, yes, we know who this buyer is, then you can use the other method called ‘Trigger Authentication Flow.’ So passing in the output of lookup customer by email, which tells you this is a customer ID that we have identified, you can pass that customer ID into Trigger Authentication Flow, which then we internally know how to authenticate this buyer and to verify that this buyer is in fact who we think they are and we're able to then trigger an OTP modal that sends an OTP to your phone, you can enter it into the site, and then we can authenticate you that way. The output of that method is the buyer's profile. So the key thing here is, while we offer the flexibility and the control to our merchants, we want to do it in a secure way. We want to protect the identities of our buyers. So the output of Trigger Authentication Flow is a JSON object that gives you access to one card, the preferred card of the buyer, and then a shipping address. And so now you have the name and also the phone number, so now you have data on the buyer that is checking out on your site and now you can go and render your own UI. So this is where you’ve got that separation of concerns. So we'll be able to look up the buyer, authenticate the buyer, provide you the profile data, but now it's up to you to go and hydrate your page and kind of render the page the way you like it, the way that works well for the merchant. That's the lookup and authenticate, and then we provide two other modules like shipping and payment, so that's off of the profile module that allows you to render a selector. So now we've given you one shipping address, we've given you one card. You can use the profile module to then also open up Fastlane modals that are presented now to the buyer to change their shipping address. Suppose you have some kind of button on your page and this button invokes this method off of our Fastlane module that opens up a shipping selector. So we handle that UI, we present a list of shipping addresses that the buyer can then choose from, they can add a new shipping address, and then same thing for your payment. You can select a card, you can also add a new card. So this is where we walk this fine line of providing the tools, providing the data, leaving it up to you to implement it and integrate it the way that you need to.
RD So we know that with any software development, errors are a part of life. How does Fastlane deal with errors and exceptions?
BP And before we get started, I just have to say, I don't know what it is, but I'm ordering a sandwich from my local deli on mobile in the browser, or I'm trying to buy a train ticket inside of their app, or I'm inside of a video game that's from a launcher, and there's payments for all these things. And I really feel like a lot of the time it's like I'm rolling the dice. I've saved cards in the browser, I've saved cards in iOS, and I hit a form fill and sometimes it gets it just right and sometimes it doesn't, and sometimes it seems to provide all the correct information from one of these vaults I have, and still, for whatever reason it just breaks down and then I select a different payment method or do the whole thing over again, or worse comes to worst, I actually pull out my credit card and do it all over again which is extremely frustrating. So yes, errors and exceptions. I want to know.
SP We've all been there. We've all experienced this. So for Fastlane, we want to accelerate the buyer as much as possible. That's the whole value prop. But the last thing we want to do is experience that pain that Ben just outlined. The last thing we want our buyers to experience is that. So for us, it was like, one, let's try to accelerate the buyer if we can. Two is, we do not block the checkout flow by any means. So if anything happens internally within our code, we try to identify and gracefully handle whatever use case that the buyer's trying to do. Maybe you're trying to add a card, maybe you're trying to select a different shipping address. We try to handle this gracefully internally first. That's first and foremost. If we can't do that, then that's where the exceptions come into play. So let me give you an example. Let's say you're trying to look up a buyer and the network call fails. For whatever reason, this happens. Internally, we are able to obviously detect that and we say, “Okay, we can't identify this buyer. Let's just assume they're a guest. Let's let them continue checking out as a guest buyer.” At least we are going to do some retry logics, but if all of that fails, the best thing that we can do at this point is then let the buyer continue the checkout flow. So that's something that we're doing internally where we're handling that ourselves. Now, if some other exception happens while you're invoking the methods, you're doing the integration and some other exception is happening in real time, we want to be able to let the integration engineer handle whatever use cases and whatever scenario. So the approach that we took with our exception handling is, one, we should throw exceptions that are meaningful, that give the integration engineer an opportunity to kind of recover the scenario and know exactly what's going on, and then if they know exactly what's going on, then they can build an integration around where I can now take this buyer into a different flow, or I can handle it at least for letting the engineer know what's happening internally within Fastlane. So the exception that's thrown kind of builds on top of the JavaScript error class. We added on a code property, so now this code identifies very specifically what is happening. There's a type that tells you how you classify this error. Also, there's another property that tells you where in the flow this error is happening. So the combination of all these should give an engineer everything that they need now to kind of go and handle the exception the way that they see best fit for their buyers. When we were thinking of these exceptions in the code, we were thinking of Stack Overflow. We were thinking about how we want these codes so that if someone drops in a code in Stack Overflow, it's searchable, it's indexable, people know and they can answer it and they can know exactly how to handle it.
BP This is clever. You've preceded. You go and ask and answer all those questions with the code, and then as soon as it hits search, they know where to go. That's very smart. So Kyle, I know you talked a little bit about this, but you were there at Developer Day and checking out the docs, which obviously is a really important thing when you're getting ready to choose what software you're going to use. Does it have great docs, can I understand it? I believe there was some interesting stuff there in terms of improving it or making it so that you could kind of almost have a conversation with it through AI. Can you tell us a little about that?
KP If the listeners have some experience with the previous PayPal docs, I think they would know the big difference because it was, let's say in a nice word, it was not ideal. It wasn't interactive, it was pretty difficult to understand, but now it's way clearer, a lot better UX. And maybe just to lay the level of the land before I get into the search AI, so let's say you're going through the integration guides, on the right hand side, you've got a code and a preview panel which is really helpful. So as you're going through the different steps, you would click on it to highlight the specific code that you're working on. At the bottom you've got a test panel, and that you can use for necessary troubleshooting like logs or API history or anything. And I think what's really underrated and this has been an awesome one, is the sandbox credentials on the same page. So previously you would have to log in, open it and everything, but now once you’re logged in, you've already got your different sandbox credentials. So effectively that just makes the whole integration process much smoother, much faster, and just a much better experience. And then obviously there's also resources that are easily accessible. Now in terms of the search AI, I think this is where it's really cool. So previously, I think we all know working on different docs, you've got a search section or a knowledge section where you would just type in something and then you'll get all this general fluff, whereas now it's a search AI and it not only summarizes what you should do, but I would say the answers are a lot more detailed and specific in terms of what you're searching for. So it's really custom, it's not really a fluffy different answer. It actually really helps you through.
BP This is one of the powers of LLMs and the Gen AI that we see, and we use this stuff inside of Stack Overflow, both the Public Platform and Teams now. You can ask it a question, it has these reasoning capabilities over text, and you can use retrieval augmented generation to say, “Look, read from this great set of docs,” and now instead of, like you're saying, before the flow used to be kind of like, “All right, I'm going to send you to the FAQ answer that's kind of close to one or two of these keywords, instead I read and understand all of these docs, I understand your question and I'm going to respond with a relevant synthesis and point you to the right place.” So that's a cool application of an LLM.
RD Sunny, I want to touch on the flexibility here. There's a bring your own processor feature. Can you talk a little bit about that?
SP So when you're trying to solve an e-commerce problem, also just part of that is trying to choose your payment processor. Your payment processor is who's actually going to be doing the money movements. So for Fastlane, we want to make sure that you can have any choice that you want. Again, this is where the separation of concerns comes in. We're not trying to force you down one path. The value of Fastlane I think can be provided to any processor that's out there that you choose to all merchants, regardless of where you're actually processing your payments. I think we're at a decent spot right now where we can start testing internally, and we should have a lot of exciting news coming into the next year in 2025.
BP That makes a lot of sense. I know that there's differences both in terms of what the merchant prefers for one reason or another, or also regionally. Across the globe, different payment processors are more popular or work within certain areas. So Kyle, have you set up Fastlane for yourself or helped some of your clients do this?
KP So unfortunately Fastlane is only available in the US for now. I'm waiting until it's available in other countries. But at the Developer Day experience, I had this one-on-one workshop with a guy named Omkar, a really awesome guy, so shout out to him. And literally we just walked through integration docs. It's really straightforward. Within about 25 minutes, we had everything ready to test and walk through. I think you've got two options– quick start and custom integration– and you can save so much time. First of all, with the GitHub Codespaces, I think it's actually a bit cheating, so we didn't go that route. We actually just downloaded some sample code, set up the front end and back end. I think there's about four steps, five steps, really simple and straightforward, really clean docs and good resources. So we got it set up and running and it’s a very nice experience. I think even people who are not too technical could actually get set up with quick start, especially.
BP Sunny, what's the cheat code here with the Codespaces?
SP So this is actually something we set up for Developer Day where we wanted to do kind of a competition, like, “Who can integrate Fastlane?” So instead of having to create your merchant account and all these things, we kind of did all that for you. For some of the internal plumbing that you would need to have in place, Codespaces was a way to do that. But then at that point it was a clean slate, so this is like, “Hey, a merchant that is already integrated with PayPal products and other processors, here's that clean slate. Now you're going to add Fastlane on top of that.” And the really cool thing that, thanks to Kyle for mentioning that, is I think everyone was pretty much able to go and integrate Fastlane and at least do the lookup call and get all that working, so that was cool to see.
RD So what's coming next in Fastlane? What are you excited about showing the people in the future?
SP I think it's three main things– three main things that really excite me. We talked about the four components and what's really neat and what is really cool about Fastlane is that each one of those components, because we own end-to-end the start and end of those flows, we can continue to keep optimizing those. We can know that this is causing a little bit of friction. This UI, the way that this is set up is causing a little bit of confusion for our buyers, and then we can keep tweaking that. So as we are scaling out and we continue doing this for all of the merchants that are using Fastlane, you're getting these benefits just out of the box as we're rolling them out, as we're tweaking things here and there. So that's one thing that I'm always excited about– using data to power the next features of Fastlane. I think the second thing is that we see the value of Fastlane really being completely agnostic. So we talked about processor-agnostic and how you can choose your own processor, it's also about platform. You can choose any e-commerce platform that you like and still try to get the value of Fastlane. Also checkout agnostic, you can build your checkout page the way that you like, the way that works well for your business. So I think these are the places where we want Fastlane to work, we want it to play, and that's what we're focused on so we know the road ahead of us and now we have our kind of marching orders of getting there. And then lastly, we also touched on this– international. So expanding Fastlane out to international markets, that's going to be really cool to see.
BP Sunny, I was just talking about how varied the experience is and how much of a crapshoot it sometimes feels like when you're going to a payment form. As a consumer, would I know if I was using Fastlane or not? Often would I not know? I could go and go through the experience, and like you said, it just feels like the merchants’ experience? As a consumer, am I going to be able to tell, “Oh, that was a good one. I know, because it was Fastlane,” or am I not going to know because it's kind of in the background?
SP This is one that kind of has two answers. One is that we want you to just have a great experience and get that feeling like, “Oh, that was cool. That was Fastlane.” But the second piece to that is that we also want you to know when we are sharing your data with that merchant. So there are logos and there is branding to let our consumers know that this is what's happening. So we don't want to be totally anonymous in the background because there is that aspect of data privacy that's always at the forefront when we're building some of these products.
[music plays]
BP All right, everybody. It is that time of the show. Let's shout out a Stack Overflow user who came on and shared a little bit of curiosity or a little bit of their knowledge and helped folks out. Awarded two days ago, a Lifeboat Badge to M.M who provided an answer for the following question: “What does the "Expected '(' for function-style cast or type construction" error mean?” And the question here is interesting because this person says, “I get these errors all the time,” and gives a bunch of different examples. “I know how to solve them. I can fix the specific bug in a code snippet, but I don't understand what this actually means.” So thank you so much to M.M for providing an answer on what this is. It's a syntax error. He's got a detailed explanation. And we've helped over 75,000 people understand this error a little better, so congrats on your badge. As always, I am Ben Popper. I'm the Director of Content here at Stack Overflow. Find me on X @BenPopper. You can get into my DMs. If you have a question or suggestion for the podcast, or you want to come on as a guest or listen to us talk about something specific, you can shoot us an email. It's just podcast@stackoverflow.com. And if you enjoyed today's episode, why don't you subscribe. You can check out more of us in the future.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. And if you want to find me on the internet, you can reach out to me on LinkedIn.
SP This is Sunny Patel. I am a software engineer at PayPal. You can find me on X @SunnyPatel and on GitHub, which is also @SunnyPatel. I was one of the lucky ones that got the full name. You can go to fastlane.paypal.com to learn more. You can also find our developer pages at, I think, developer.paypal.com/fastlane.
KP My name is Kyle Prinsloo, and I'm an agency owner, SaaS founder, and I'm a PayPal partner. You can find me on X and you can find me on LinkedIn. And I would recommend to at least check out Fastlane and see if it's good for you and the merchant.
BP All right, everybody. We will put those links in the show notes so you can check them out. Thanks so much for listening, and we'll talk to you soon.
[outro music plays]