 We're from Seakeek. Thank you for the intro. And we are here to talk about scaling payments with your growing business. So we are going to just talk about ourselves and what we've done for the next 20 minutes or so. It's a pretty interesting ride and we think that... So first, some quick introductions. My name is Nicole. I'm the director of the payments and risk team at Seakeek. I have worked here for about two years. Prior to that, I worked at Etsy for five years doing payments there as well. My name is Bebev. I go by V, so that's fine. I joined Seakeek towards the end of 2014, early 2015. And I now lead the engineering team that takes care of all payments and risk to Seakeek. Cool. We'll do a quick plug for Seakeek. We have an app. We have a website. You can buy tickets to live events. And we've been around since about 2010. Nine, technically, but let's go with 10. All right. So why do we want to do this talk? Since you're all working in payments or around payments, everyone knows that the opportunities and challenges that you face when you accept your first order are very different from the challenges and opportunities that you have when you're accepting your millionth order. So we wanted to just take you for a little ride about what was interesting in our journey doing this and some scary and cool things that happened. From an engineering perspective, you accept that there's going to be challenges. There's going to be scalability and servers and AWS and all the other stuff that we all work with. But Justin set this up pretty well for us. When you're a really small person in this place, you don't have a lot of control. You might have the best standards, but you can't enforce them. You have to be very flexible in how you process payments. Just like a 10,000 ticket, if you just go and buy 10,000 tickets for one, it's very easy to have a nice chase on API. But then when you need those Broadway tickets, you're working with the XML and XML and XML partners as well. So having a flexible partner that allows us to do a lot of this stuff is how we've been able to do it. So that's what we're going to talk about. So we're going to talk about this now as we journey through the business models that we've worked with over time. We started as a search engine. Then we moved to a native checkout experience still sending the payment to our partners. Then we became merchant of record for transactions. We built a marketplace to accept inventory from consumers and smaller professional ticket sellers. And most recently, we've gotten into enterprise. So let me take you through this journey as we saw it. So when we were a search engine, we dealt in this idea of clicks. What was important to us was this idea of building a kick-ass interface, running our scrapers at night, going out there, getting all the events that were on the internet, getting all the tickets for them with permission from our partners. We were not creating people without their permission. Well, in some cases, we might have been. But we were essentially getting every event, every ticket we could find on the internet and putting them on Seed Geek with a kick-ass UI, assuming that our partners that actually sell these tickets will be able to handle the checkout process of this. So this is what it looked like. We had this nice map that we built. This is a recent speech on this map, a vector map style, you can zoom in, zoom out, whatever you want. We developed this idea of these numbers that we see, which is deal quality, where we look at six or seven years of data about transactions and how they work. What I'm going to detail is one of the interview questions we asked, how do you sell my tickets? I'm going to tell you a lot. We had nice, great amount of tickets, and this blue button. And when somebody clicked on that blue button, that was a click. And that's how we were going to get paid. Get people to click on that button, go to a partner website, have them do checkout, and we'll be fine. And then that's when we started realizing that, well, it's not that easy because. People aren't checking out. They get to the partner website, and that's a speech of 2018, yesterday. So I just want to make sure that this is not 2030, this is 2018. And a lot of times, people were sort of ending up with these checkout forms, and just had to go through six different steps to do this. None of the information was going to be saved. We could do this every time they wanted to get from us. On the left, that is a mobile checkout form that we come on. And it was just like looking at that on your iPhone screen wasn't ideal. If this is 2018, five years ago, things were not this good. Nothing was going to go along the lines. And around 2013, 2014, we started noticing this trend where a lot of traffic that we were getting was immobile. So we got our Android app, we got our native iOS app. And we were having people sort of do all the map stuff or selection to get everything on native apps. And then with the click, the thing that was so holy to us, we were just sending them over to a website like that. We just wasn't working. So that's, yeah, so we decided to build native checkout. And why did we want to do this? Like I said, beginning companies were not doing mobile well. It was just not a thing that people were able to do. And this great checkout experience that we'd built of this great idea of how you look for tickets, how you select things on a map, how you do deal quality, none of that was worth it if you're not going to make any money in the end because people just weren't checking out. It was obvious that we needed to build native checkout on SeatGeek, but then we were thinking about, wait, we're a very small company. We don't even have a lot of engineers. And this is around, we had like maybe five engineers at this point, so we were thinking about, wait, how do we even get payment information securely to our partners? Some of these guys were PCI compliant. They were like, send us a 16-digit bin, send us your CVV, and we'll take care of this. And then other partners were telling us, well, we are not PCI compliant. We use this payment service provider, whether it's BrainTree or Stripe, or something. One of them was actually a Swedish customer. So we have a bunch of this stuff, but they wanted us to do the heavy lifting. So vault our credentials, just give us the token, and we'll do the rest. And one of the issues that we were also having was, this is how fragmented the marketplace was. So each one of those colors is one of our partners doing that percentage of transactions. So we couldn't have just picked one partner. We were like, OK, we'll go with how these guys do it, and we'll just enforce. We had no power to enforce any. We still don't, in a way. But we couldn't have just picked one thing, and we were sort of thinking about this whole idea of, how do we even do this? Which is when we wrote this email to Spreedly. I'm actually going to try to read this. It's very interesting. It says, hey, Spreedly, I'm writing from a company called SeedGeek. We're considering a new feature with some complex vaulting needs. And by complex, I mean potentially impossible. Based on some looking around, it seems that you guys are the expert when it comes to this sort of thing. So I figured if you would help. So this is an email that was written in 2013. I think there was some back and forth for about eight months, and it wasn't like we didn't have a solution still. So we were kind of just building the still, the amazing apps, and sort of going through designs. But we just didn't have native checkout until someone who started us and said, hey, you can now use Spreedly as this proxy, and you can sort of deliver these payment methods into your partner. We were like, yes, let's do this. So here's just a few samples that I pulled out. Someone, I think you all was talking about X and L, and X and L, but is there X and L, and X and L? Right over there. You guys can see this part. There were some APIs that were just nice. There were JSON that we could just easily put our little mustache variables in and just deliver information to them, and it just worked. And people would reach out to us, and everything was fine. And then you had the legacy, the Broadway partners, as you call them, that had these old SOAP APIs where we had to escape XML inside XML. Sometimes there was another layer of XMLs. So just to share, these were some of the good partners, honestly. The people that had SOAP or had a WSDL, these were people that I liked working with. There were other API partners where there was no response. The response used to be a URL, and you had to keep polling the URL for a zip file, and then open the zip file, and then that's where the text file with the response was. So it's like one of the things that you'll notice is as you get closer to the source of the tickets in the ticketing industry, that level of technology actually goes down. It doesn't go up. Anyway, so we were able to use freely as a proxy, and that led us to be able to build a native checkout experience in SeedGeek, where a SeedGeek user never had to leave SeedGeek. They could buy their tickets, and tickets, unlike a lot of the other sort of commercey things, is something that you can buy on a phone and then use it on a phone. So we built this idea of just mobile entry. So you could literally buy your tickets on a phone and just scan your tickets in. And I've used that feature so many times as a Nix fan because tickets are really expensive. So what I would do is just wait till the last minute when all the sellers would drop their prices, because no one was going to go buy a ticket and go print it out. So I would just stand outside Madison Square Garden for a while, buy a ticket with five minutes left, or sometimes after the game started, and just sit in one of the seats for $10. Anyway, that was a big win for us. So the next step in our evolution was becoming merchant of record ourselves. So all this work that the team had put into building native checkout, we were still sending the payment credentials out to third parties. And so the rest of the transaction that a customer was experiencing, the end of that was with somebody else. So if they had problems, if they had issues, they couldn't tell us. We would have to redirect them. And that just wasn't a great experience for them. So we knew our customers better than anyone else. So we figured, let's keep them inside our system for that entire lifecycle of the transaction. We wanted to do that. We knew we wanted to have more control. We knew that would be a better experience. And if we were charging the cards ourselves, it meant that we would be able to get to work with some of the more professional sellers that existed in the ecosystem so we could get better inventory. We also wanted to have better pricing. So if we're negotiating a wholesale rate for tickets from the source of those tickets, that means that we can do things like dynamically price tickets because we know the event is popular or it's close to the start time or whatever is happening in the market. We get to decide how much we want to sell that for. And we wanted to have more ways for customers to pay. This was back in 2013, 2014. Apple Pay had recently launched. And we wanted to be on the forefront of adopting these new technologies. And we just couldn't do that if we were still relying on third parties to process payment. So all we needed was a merchant account, right? So we went to a web form, sort of like this. Didn't really look at any of the bells and whistles. Just sort of knew what we needed, signed up, and we were on our way. Dollar signs. Anyway, once that easy part was done, some of the other people that worked at CT had to look into how this would actually be done. So one of the cool things that we already were seeing, we didn't understand what a speed leak gateway was. I have to admit at that point. All we knew was we have these receivers. And I was looking at the Braintree API integration and all that stuff. And I stumbled upon this idea of speed leak as a gateway. And I was like, wait, they already did all the work for us. This could literally be the last API that we ever work with. That's exactly what I'm saying. So we were already, because we were delivering information to our partners securely through speedly, the receiver delivered product, as we all call it that now. We realized that, oh, wait, all of our banking payment methods are already in abort. So all we really have to do is deliver them now to a gateway, and then everything would just work. So as Nicole talked about building the merchant of record experience was so much more than simply charging credit cards, we were able to actually spend more time doing those things. And the speedly integration kind of just worked out of the box. We didn't have to do much there. So we were already calling. I think we were already vaulting things. All we had to do was start authorizing cards through speedly, calling the settle method on speedly, in some cases having a void or a refund. But everything was essentially going through speedly. And we were like, wow, this is awesome. We don't have to worry about this at all. And then Apple Pay was, I think we worked with speedly, if I remember correctly, when we were doing Apple Pay. It was a complex process of uploading a certificate. But once you were done with all of that stuff, Apple Pay suddenly started working. I remember that day when it started working, it was like, there is no way this was this little work. This is not working. There's no way this is working. Android Pay was a little more work, but we eventually got to that point. And during the whole process, there was a lot of very productive back and forth with speedly and, you know, speedly with Google, and then Google Seed Geek. There was a lot of back and forth, but eventually we were able to support all of these payment methods that we were hoping to be able to store. Yeah, so it was working. We put in the work, and we saw the transactions coming in. Everything was going smooth. We thought we were good. Is the clicker gone? The clicker is good. OK. So we knew we were officially now in charge of customer service, refunds, chargebacks, anything risky that happened on the platform. As I mentioned, customers were already reaching out to us, and we had to redirect them. So we didn't want to have to do that. We had this nice web form where people could talk to us, send us their questions, and then we also had to worry about fraud. We were slightly less prepared for this one. So we knew it was a thing. We knew what chargebacks were and knew about fraud in a general sense, but weren't totally prepared for what we needed to do to mitigate it. So this was our chargeback slide. The red dotted line was the arbitrary goal that we had set for ourselves to say, this is what we think the limit should be. And for the first several months, everything was within the bounds that we were expecting. And then all of a sudden, out of the blue, we had that happen. That was our oh crap moment. So we sort of had to scramble. And this was around the time that I joined the team as well. So we brought it back down. Don't worry, we're safe now. But there was a lot of stuff that we had to do internally. We had developed some internal tools that we're still using today, one of which is an order review queue system where we have some rules around what transactions we can review, which ones we want to accept, which ones we want to reject outright. We have some external partners that we're working with on the fraud side that are really good in this space. We set up those integrations. We pulled together a new team. So this was when the payments and risk team sort of started. And we have people that are reviewing transactions every day now, looking for risks in the marketplace and keeping everyone safe. And there was a lot of shared learning happening during this time. This was definitely a crash course in risk for Piki. Very exciting. I like how I'm laughing now. So we did all of this. We had a platform that people could do native checkout on. We could charge credit cards. Everything was going well. But like any other company with BC money, we had to grow. We had to find other ways to get bigger, drive more volume, get more customers. And this is when we really started digging into our data and try to figure out, how do we do against our competitors when it comes to tickets? And this was like a study that we did. And we figured out that because we had this merchant record stuff, we were doing dynamic pricing. We had a bunch of tickets. Every time we did have tickets to a certain event or in a certain section, a certain row of a stadium, we had the best prices. But we didn't have all the tickets. So that was an issue. So our competition is like 20 times our size at times. So you know, companies that sell a lot of tickets. And just doing this analysis, we realized there were two things that we had to do. We had to build a marketplace, which not only caters to Seeky customers, but if you bought a ticket on Seeky, you should be able to sell it very easily, but also to professional sellers that have contracts with major teams that make wholesale deals with them and just get like 15,000 tickets to every Dallas Cowboys game or something like that. And we had to bring them on to our platform. And like I said before, as you get closer to the source of tickets in the industry, the level of technology drops. So this meant that we had to build a lot of tools for them. And one of the reasons we were able to spend a lot of time doing that and building cool UI interfaces like those, when our competition at the time would make you search for an event, then enter the name of your section, enter the name of your row, enter the ticket quantity, and then ask you to come up with a price. We just had someone drag a PDF that would be instantly parsed, and we would suggest a price based on our deal 14 saying, hey, you should sell this ticket for this price. So we were able to do a lot of that and build all the tools our professional sellers needed because the payments piece of this just worked out of the box. So in Braintree, we had a marketplace product. And Spreedley did a pretty good job of sort of exposing the custom variables that we needed to pass during an authorization request that will allow us to split payments between the marketplace and the merchant. So that's essentially all we needed. So again, we found ourselves in this place where we were like, wait, we thought this was going to be a lot of work for payments. Turns out it's not. So let's just build a better marketplace, which we were able to do. Because we are a customer facing company, it doesn't like a lot of logistics don't really matter. People just want the easiest way to list their tickets and being able to just have this luxury of just putting in a lot of work on the marketplace product itself and not worrying too much about payments was another sort of major win for us. Things are still going well. We are growing very quickly at this time. And this is me and myself climbing up Transaction Mountain, dodging boulders left and right. So another interesting thing that happened when we sort of built this marketplace was we started talking to these sellers. And we honestly, at this point, we were like, well, we're definitely at parity with our biggest competition. And everything's good. I don't think there's a lot of work left. And that's when we sort of stumbled into this whole idea of what are the issues that the sellers are facing. So we've always been a very customer focused company. But now we have this other side of the marketplace where people are just trying to sell their tickets. And they're essentially small businesses. The professional sellers, at least, are just basically small businesses. And they have their own challenges. So some of the things that were obvious to us is that you could own your tickets. But there was no real way to export them into a format that you could list tickets on any other websites for. There was no central place to be able to do that. This whole idea that a ticket is a piece of paper that you have, like a hard ticket, as we call it, that idea was going away. Everything was sort of mobile entry and people were doing those things. PDF was still a concept. But it was definitely going away. It's like, what do you actually buy when you pay someone money? Are you just buying a PDF? It's so easy to lose. It's so easy to be stolen. It's like, I don't really understand this whole idea of PDF, but it did make things very convenient when it came to reselling things. But now that idea of PDF was also going away. And then the sheer number of the long tail of event delivery methods that we just were not able to handle because we had no control over this was mind boggling. So we had to be able to sell will call tickets, VIP tickets, meet and greet tickets, Rihanna backstage passes. It was, there was just too much. The industry was extremely fragmented. And that's when we decided to sort of put some focus into saying, you know what, we are doing this well, but let's try to study the industry and see what is there a dent that we can make in the industry? Can we change how these things are looked at? So this sort of introduced us to a lot of the challenges. It just existed in the ticketing ecosystem in general. So we had solved a lot on the customer facing side. We were starting to solve a lot of things on the ticket seller side when we were servicing our platform, but there was still just a lot in general that we couldn't do anything about. So ticketing, if you're not aware, it's a really closed ecosystem. The ticketing companies that are out there in the space are controlling where people can sell tickets, where people can buy tickets, and the people that are organizing events, the teams, the venues, the promoters. They have a really hard time dealing with this because they have to work in such a narrow framework that is built by someone else and controlled by somebody else. There's also a big issue with data. If you can imagine, the ticketing companies do not want people to resell tickets. They want them to use them themselves. So what that means is that if you need to sell your tickets, or if you want to sell your tickets, whoever is showing up and sitting in your seat, that person's name is not on the ticket, that means that the team or the venue or the promoter has no idea who's actually attending their events, and it's a huge missed opportunity for them, for marketing, and for any other purposes that they have. And like Vee was talking about, as you get closer to the source, the technology levels just drop completely. These are all legacy systems, and the customers that are using them are huge, huge, $100 million teams, venues, organizations that have a lot of prestige in the industry and they're stuck using these crappy things. So we thought maybe there's something that we can do about this. So this brings us to our most recent model that we've been having to work in, and that is Enterprise. We are now a partially B2B company, which was a new thing for SeatGeek as well. And so how did we do that? We went out and we acquired a company. TopTix was a ticketing software company that was active in the United States, very active in Europe, Australia, kind of all over the globe, and now they are a part of SeatGeek. This has been really exciting for us, but sort of what was being referred to in the last presentation, when you acquire a company, you might be acquiring another legacy system. So not only did that happen, but we now had a lot of new things that we, we knew we were gonna have to support that we've never had to think about before. So how do people pay in a box office? With a device, with a device, it probably has to be EMV compliant, could be different requirements based on the country. We now have deposits. A lot of teams want to have their customers be able to pay for a part of the payment for whatever they're purchasing. We have season tickets, so someone's gonna pay a huge lump sum payment for like a bunch of inventory, for a bunch of different dates, and we need to support that. And last but not least, on sales, we're a huge challenge for us in terms of scalability. We need to be able to process thousands of transactions in minutes, which is just something that we never had to worry about previously, and obviously there's a lot riding on us getting that right. So the company that we had just acquired, TopTix, we thought maybe they had solved this. Maybe they were doing something that we can just learn from and carry that over into C-Geek Enterprise. And so when we reached out to the engineering leads in that team, we asked them, who did you integrate with for payments? Like, who were you working with? What worked well? What didn't work well? How did the clients tell us what was going on there? And the answer that we got was, well, we would just integrate whatever the client said they wanted. So we said, well, how did the client know what they wanted? So a lot of clients had the same requirements, but weren't talking to each other and the company wasn't really recommending anyone in particular. So what happened was there was like 50 plus payment integrations, a bunch of which we had never heard of, that would be activated and integrated for one client, and then an engineer would never look at it again. So there was bugs, there was issues, there was tickets getting opened all the time because some minor thing had to be fixed with an integration. So it was an all around not great experience and we thought that maybe we can consolidate some of this. Maybe there's some similarities in some of what clients are looking for. Maybe there are partners out there that can help us solve like 80% of the use cases and then if we need to add more, we can add more because we know that it would be easy to do. So we went out and did an RFP for a new partner and many of you probably know what an RFP is. I did put the technical definition here because it sounds very professional, but when we were doing it, it sort of just felt like, oh my God, how do we solve this really quickly? What are we gonna do? So this was a really good example of like in the past when we just went to the web form, hey, we need a merchant account for US e-commerce, US dollar transactions, that didn't work anymore. Now we have devices, we have countries, we have currencies, weird payment methods, and we need to be able to support all of it. So one of the themes that you might have noticed in the whole presentation, we were always running out of time, like always trying to catch up with a lot of this stuff. And I remember the RFP process where we were looking at a bunch of, I think there were three or four, I think it started with a bigger list, but then we were down to the final three or four. And one of the really cool things about that whole process was that we didn't actually have to look at their APIs. Like, I know that was a concern that some people in the company had, like do they have good APIs, but in my head, I was like, I hope Speedly's doing this, like I'm not actually gonna go and do stuff with their API. So I was very happy to see that the one that we chose, in fact, the last three that we were on, like all three of them were supported by Speedly. So I was pretty ambivalent from an engineering side, like whatever you pick, I'm cool with it. And, but then we did have to re-engineer our payment service. So this idea that we had one payment provider that was gonna do our marketplace, it was gonna do our box office stuff, it was gonna do everything for us, that idea basically completely broke down. And we were in this partnership, we had, we were the official ticketing partners of the MLS, which is the major league of soccer. And we had signed the Sporting Kansas City as our first team and signed two more teams that we are ticketing this season. And we needed these solutions quickly. So, we, Slack, we use Slack. So there was a, there was a, we had to really build this quickly. And then we sort of modeled our payment service based on the fact that, you know, Speedly allows you to have multiple gateways. So maybe we can modify service to invest heavily early on in the transaction when you decide which gateway to use. So look at a transaction, look at the users that's making the transaction, look at the IP address of the person that's making the transaction. How can we make this extremely genetic where payment processors, instead of like being integrations and code, just become data. There's a list of integrations that are all represented by this one string that, you know, it's a gateway token that Speedly gives us. And all we have to do, like my coding problem was simply given a bunch of attributes about this transaction and this person pick the best string. And that's it. So if we think about adding more payment processors after all the work that we did, it's basically no work. It's just adding another thing to a data structure and then figuring out what attributes that maps do best and then just picking it for the transaction that's happening. So on the right, there's a slight graph of, and you'll see a lot of these dates that we're going through a lot of this transition right now. And we are sort of very easy to, it's very easy for us to like drag a slider now in one of our admin tools and it just sends transactions one way or another when we have to. One of the things that Nicole talked about which is challenging for us was this idea of an on sale. So close your eyes and just imagine Justin Bieber at the biggest stadium that you can think of. Those tickets are going to sell in 10 minutes. There's going to be 100,000 tickets sold in 10 minutes. And I remember I think it was either Luke or Nathaniel, they were at the Seed Geek office and they were selling us that you should realize that at that level of transactions the payment processor is going to slow down. It's not going to be Speedly or Seed Geek. So you have to be prepared for those things. Because of this fact that Speedly takes out all of this coding integration stuff and converts that to data, we now have an effective payment service that can just choose and pick whichever payment service gateway that we want to go to. And we were like, yes, we can now rest. Everything's good, everything's working. I'll go take a vacation, Nicole can hang out with her kid and then this happened. So Cowboys, for those of you who don't know or don't follow football, are the biggest sports team in the world. I Googled this, I did Google this. They are the biggest sports team in the world, not in the US, not the biggest football. They are just the biggest sports team in the world. So this wasn't supposed to happen. There's no way this can happen, but it did happen. So this started another mad dash. It was like, oh, I thought we were done. And then, well, then let Nicole talk through the rest stuff. Yeah, so that happened. I think we had about six weeks to get it up and running, not only to make sure that all the payment stuff was ready to go, but that the software that we had, that they were gonna be using, essentially as their entire ticket manifest was up and running and integrated and installed. So this is us on the right. This is in, to the right of this is a wall. And then on the other side is the window where people walk up and buy tickets at the box office. So we're in the box office with the devices that we're installing so that they can accept payments in their box office. And this is just a nice picture of AT&T Stadium. It was before a soccer game that we got to attend while we were down there visiting. And it was just a completely surreal experience and kind of brought together all of the years of hard work that we had done on the like scaling payments. Like, oh my God, how do we do this side? And it is working, so. So again, from the engineering perspective when we were sort of given this news that, oh, you've signed the, besides the fact that I'm a Giants fan. I didn't like it. I'm a Giants fan too, so. It was also a little disappointing in the sense that, wait, so what do we have to do now? How does this affect our payment service or our NUDE sort of created this? Couple of things were easy. So if they wanted, if the Cowboys wanted to use a different payment provider, we could just add that as another gateway to that list that I talked about. So the other challenge here was that for all the good things that our back-end primary system does, the UI for everything, the customer interaction is still CPEAK4, right? So we had a bunch of payment methods that were in CPEAK that needed to make its way back to our back-end sort of primary technique system so that people could be charged for season tickets through subscriptions, et cetera, where someone's sitting in the box office. So the idea is there's a credit card that lives inside CPEAK.com that somebody bought an MLB ticket. Now I need to make that credit card go from there all the way into our box office software so that when they call to renew their season tickets possibly for the Dallas Cowboys, the rep sitting there can simply click a button and they just do this. And the interesting thing here is that there's a gateway store method that allows you to store tokens which did not exist for this payment provider that Dallas Cowboys. And I think it was done just in time. I think it was delivered the week before by Spreadly. So thank you, Spreadly, for doing that. Listen, you said this is the last payments API so I didn't want to do it myself. That's all I'm saying. So they were able to deliver that method just in time and then we were able to sort of launch the Cowboys. So the future, the future, that long arrow, I thought we were going to fix that. Anyway, so the future is very exciting. Based on what we've shown you as I was going through building this deck, it seemed like we had already done a lot but then there's so much more to do. We have maybe five or six primary teams in the US. Are any of you like English Premier League fans? Parker? We also take it 25% of the Premier League, by the way. We just signed Manchester City like two weeks ago. So the future is bright. From an engineering perspective, there's a couple of things that I'm very excited about. It is to take our core platform and make it international which means there's going to be more types of payment methods. There's going to be more types of countries that we have to support, maybe more payment processors. And then also this idea that we built, the Seeking Enterprise is also known as this, in the US we also call it Seeking Open because we wanted to syndicate our inventory to every possible place. So there are competitors that we have that call our APIs to sell our tickets. And we want to keep going with that. And some of these use cases are very interesting because it's one thing to sell your tickets on a channel that is traditionally e-commerce, like Amazon was selling our tickets, that's very easy, like they have everything set up. But we want to target places that are not traditionally e-commerce channels, like a website that just shows you the latest scores and maybe they want to sell tickets to the Dallas Cowboys. So we want to enable all of this commerce happening. So there's a lot of really cool payment cases. Some of them we have already solved, some of them we're sort of working out on how to do. But the future is very bright from that perspective, from an engineering point of them. I know Nicole has more. Yeah, so not only do we want to empower the ecosystem itself, we want to empower the fans and we want to empower the organizers of events. So you can imagine, you've purchased your ticket on Seeky, you show up at the event, you sit down, we know where you're sitting and we have your card on file. If you want to order hot dog at a baseball game or a t-shirt at a concert, we should be able to enable that and just hit your card on file. And then the team also knows what you bought. So when you come back, maybe they think like, oh, maybe they'll buy a hot dog again. Like these are all things that we think would be really cool to make every experience with payments just super seamless for customers while also providing a lot of value to people. And you're all peers, as we were saying before, but you're also fans, I'm hoping, and in a way, customers. So if you had never heard of Seeky, I just made this over there. So if you use the payments FN code on Seeky, you'll get $25 off. So have fun, have one on us. And if you know people that want to help us do this, we're also hiding, so talk to us after. But thank you. Yep, thank you. Thank you.