 My name is Peter Mullins. I'm the guy that emails you. So welcome. It's great to see you all. So I'll be the master of ceremonies for the Ask Me Anything. So I appreciate everyone asking questions. We've already got up to 14, so that's great stuff. So what I'll do is I'll just go ahead and start. First off, first question was, can you talk a little bit about your roadmap for the next year or so, potential payment method distribution, integrations, et cetera? So there's two interesting things going on here. First of all, I can talk a little bit about the near-term roadmap, because we have some things about to start, some things in flight. And then I can talk a little bit about some exciting developments for us in the product arena. So in-flight things that we're working on, this actually got, Brian mentioned this in her lightning talk, we're about to launch into doing card-level account updaters. So you'll be able to take your vault and actually flag, it'll be a negative flag. So you'll be able to go in and say, I don't want this part to run through AU. So especially for a lot of those folks who are on running marketplaces and platforms, this becomes an issue, because maybe some merchants you want to run through an updater, maybe some merchants you built around whether you're able to pass those costs on, et cetera. So that would be rolling out, or the work on that would be starting here shortly. Who has checked out the new Spreatley dashboard? I think people know about that. So we just launched this new dashboard. And one of the other things that we're about to start doing is just some iterative work. We actually, I don't know how many of you all have heard of Conway's Law, but Conway's Law is the idea that computer systems and architectures end up reflecting the organizations that build them. And early on in Spreatley's life, we had a bunch of senior engineers who were all working on individual projects. And so we ended up with a whole bunch of individual experiences. So we had a debug app, and we had a support app, and we had a dashboard app, and we had another dashboard app. So we've just recently done some work to consolidate those down, and now we're able to iterate faster inside of that. We have a team that's working on that, and it's going to be working on improvements inside of our dashboard. So those are some of the short term things. And then the really exciting thing that we've done just recently is we've hired full time BPA products. We would have put him up here and made him answer this question, but he literally started like two weeks ago or three weeks ago, so we thought that wasn't quite fair. But he is going to be digging into some of those longer bets and longer term things and starting to help us map out 2019. We've always driven a lot of our innovation and the things we've done directly off of customer requests. And we'll continue to do that. We'll continue to use that feedback, but we want to look at some bigger picture stuff, try to understand not just what our existing customers want, but what future customers will want, or things that you would want if you knew that we could offer them to you. So that's kind of the next level of things that Daniel's going to be digging into over the coming quarter or so. He's over here, if you want to pass for him, again, he's only three weeks in, so he's nice. We don't want him to run away screaming yet. But he is here, and he would love, especially, to talk to anyone that's back. He's a wishes, and he's a thought. Okay, terrific. So next question. Spreely handles traditional payment options very well. Do you plan to support alternate payment methods in the future, specifically, Florida? Yeah. So it's a great question. And it's a constant recurring question is the idea around support for alternative payments. It's definitely in the bucket of sort of three or four things that we're looking at, and that we're looking at in terms of roadmap and broaderizing. I think the really interesting thing around alternative payments is we want to integrate them in a way that is similar to the experience we have with credit cards, which is you can change out the provider on the back end, still process credit cards. Could you change out the provider on the back end and still keep support for your alternative payments? So making sure it's not mapped to a, seeing if we can do it that way. And I think in just, you know, as it relates to product and the roadmap, for us as you all know, and most of you really appreciate that we're this low level set of APIs that you can build on top of, this sort of philosophical discussion that we're having internally and that Daniel is helping us drive is, how do we do more without suddenly going too far at the stack and building finished products? So we look at things like data. We have all this data that you can access via the API. And if you want to invest the time and energy, and we've done a few little things there, you can see, hey, how am I doing in terms of successful transactions, declines maybe by region, maybe by payment type. We're thinking about how do we build things that actually are, you can come in and see a dashboard in real time. So we're still providing the same, we're all set of APIs, but we're giving you actionable data where you come and see a dashboard and see how you're doing by card type, by region. We're thinking about the same thing. That sort of general concept of power we extend without moving too far away from the reason that we're all here, which is this really flexible set of APIs. So that's sort of philosophical discussion we want to have, we want to provide all value like that for you without suddenly having this little stack reaping. And we've got a rate-baked forward solution we want you to use or a concrete set of BI tools. Okay, how about any plans to support SAML single sign-on or onto the admin pages? I mean, I think one of the things we're working on with, again, consolidating into a single dashboard and really on the side of how you interact with the back end of screening, web UI, et cetera, we're working on consolidating that into a single code base. And one of the ideas there is adding on those enterprise features. I don't know about SAML specifically. We'd like to add two factor authentication. We'd like to add better account management so that you can go in and have multiple levels and more control over your APIs, et cetera. So improvements are coming in that area. Again, feedback to Daniel, feedback to us around what your highest priority is there, but we don't yet have specific SAML plans. Great. So you've already met Nathaniel and Justin. Ryan Daigle is our director of engineering. This question was directed to you, but of course I'll throw it out to anyone. Can you talk a little bit about how you deal with scaling payments, especially for big spikes like on, for instance, C-keeks on sale spikes? Yeah, we do a lot of things. You heard a lot of our engineers talk about React, which does a great job with availability. The initial wrinkle with what we do is that very little of the total payment processing time, like when you make an API call to Spreedly and say it takes 300 milliseconds to several seconds to return to you, Spreedly is adding 20 to 50 milliseconds across what is then happening downstream. So a lot of our performance is, you may be seeing it and witnessing it via Spreedly, but a lot of it is downstream performance issues and processing time. So a lot of what we are doing now in the move to AWS and how we've architectured our systems is in making sure and minimizing the effect that downstream degradations have on the Spreedly systems. Anything that's happening downstream, we try to isolate it as quickly as possible and return failures if we already know the gateway is down so we can return failures quicker. A lot of times that determinism and being that explicit upfront helps you do your jobs better. It gives you known error states that you could actually work with and deal with on your side. So we're kind of in this interesting spot as we've talked about many times or placed in the payment processing stack. So we kind of have to deal with performance issues at maybe a slightly different level or in a different way. It's more about isolating issues than maybe for somebody that has full control over the whole stack, the whole technical stack. Yeah, and I want to say we have not just CP, but we have other customers that do the rich heads here. We have other customers that do large on sales. And so we always kind of pay attention to those because those are interesting sort of stress test for the system and a lot of those customers give us prior warning that those things are happening so we keep an extra eye on the systems and we're paying attention to whether we have enough capacity basically to absorb those and trying to actually be able to absorb some multiple of those. There is no scaling magic bullet so it's really just about making sure that we're doing our best to be ahead of that curve. Great. Next question. With chips now being widely utilized, e-commerce is now being targeted as they'll low hanging fruit for fraud. Can you talk about any efforts to help out with additional fraud prevention and tooling? Well, so I think philosophically, we've talked a lot about fraud internally and really this for us would sort of fall in the PMD functionality. So fraud, I don't think that street people do anything sort of natively build anything on the fraud side anytime soon. It's probably a trap we can fall into where we see good volumes and so we stop saying maybe we can add some value there. Fraud for one thing is very verticalized so what someone selling 10,000 dollar pieces of jewelry sees and what someone selling digital goods sees in terms of fraud and what someone selling low hanging consumer goods is it's very, very different. So the first trap is still falling into a fraud as a single aid office blow. For us, I think we would be very interested in working with fraud providers. So phase one, PMD, we have customers using PMD today to pass card data out to third party fraud services and to apply those rules and then come back and decide if it was transactional or not. There are also many customers that use SIFS signs with us that actually sits on the front end and doesn't even need the card data the way they function. I could see a world where we might get more excited about helping I think an interested use case for us or if we went and did a first class that it received via PMD they'll call pointing out the three or five fraud providers and enable our customers to kind of aid be tested or even route based on different rules they have based on their skills as opposed to providers. I think those are things we would do and we really can trust them for us to do but again I think that's just extending the sort of PMD functionality we have versus us getting into the fraud and providing a spirit being made for our solution. Yeah and I think it's one of the really interesting questions we're always asking ourselves. What should we be building indiscreetly and what should we be enabling our customers to build on top of the street and finding the right place to sell and that might be really important because we can dedicate more resources to allowing you to build things on top of streetly and we're not spending much time trying to build things indiscreetly but we also there might be some unique set of services that only we can do at our point in the stack and we want to make sure that we're building these things. So we're always making that and trying to balance those things. So Ryan this one's for you. As you grow the speedly engineering team what are some of the things you try to keep in mind to have a productive engineering environment? There are many things. I don't know if you all are familiar with some of the stuff we've done with the hiring process but we try to talk about it a lot on the engineering blog and in other places too but I think one of the great things about speedly and really it's about the people within speedly is I think we're pretty much across the organization like we're very deliberate about what we do. So when we hire somebody we don't just put the post up see what we get and kind of just talk to people and see who feels like the right fit. We've sat down ahead of time. We've created kind of a job description almost like an internal job description of this is what this role entails for positions like on the engineering team these are roles that have been well flushed out many years now and they of course continue to be refined but we have this internal description everybody has the same target whether it's for promotions or hiring in this is the single source of truth or what this job entails. It's the thing by which everybody's measured to that's in that role and people coming in. So we've identified and if you look at these job descriptions they tend to have four ish categories. There tends to be technical competence that's kind of the basic one that's usually pretty easy to measure. But then we ask a lot of our engineers we really try to push responsibility down to the people that are doing the day to day work. So we are looking for not just strong technical people or not just people that are strong in the core definition of their role. We're looking for things like maturity, good organizational skills, communication skills. I think maybe things that might traditionally be thought of as soft skills those are really important and when I look at kind of our hiring across roles those tend to be the areas where strong candidates really distinguish themselves from others. So there are lots of specifics within that that there's some posts we have online but those are kind of the axes by which we are looking at when we try to bring people on and make sure that they're a good fit. I think something also that is really important is that even though we, I feel like we're kind of a tweener as a company. We've been around for seven, eight years now in the current form, revenue projections and whatnot are enjoyable at this stage. So we're probably not considered a startup by some measures but I think our mentality internally and the people that are really successful with us and how we kind of view ourselves is still as a startup. So people that really flourish in that type of environment tend to do really well here and that bringing those type of people on board just makes my job so much easier. You don't have to ask these types of people to do work. They're looking for work for ways to contribute and so those are some of the things that really helps as we grow up. Makes my job a lot easier. Okay, Justin, you mentioned earlier about the importance of data. This question asks, do you internally track a gateway uptimes and outages? Oh, I think the question's probably more around proactive. So we certainly know that the gateway's down. We look at, but it's always, it's not something we've talked a little bit about until you could almost do a marketing type service where we could track gateways, publish something that showed you our time. Like what's the MI outboard? Yeah, down for everyone or just? Down for everyone, yeah. So we thought about building some services around it. But when you support, the interesting thing, when we support 100 gateways, as you know, there's always 80, 20 people. And so many of those gateways might only do 10, 20, 15, 20, we might only do 10 or 20 or 50 or 100 transactions a day. So we're on the off of one or two clients. So they may go to sometimes, the department of gateways is going to have to pull out and come back on. We've never tried to talk to it. We've never even necessarily noticed. So we are not doing anything proactively where we're peening the gateway or running it in its transaction every five-second period in the same era. Most of it for the bigger volumes, we know immediately it's real time. So we're not having gateways for which it can be a customer that comes to us and says, hey, this gateway is, you know, we're getting your message and we're going to get it. So it's a mixed bag that has the behind of the gateway. I'd also add there's a long tail of what exactly an error state or error condition is. What does it mean to be up? A lot of times there's, it's just maybe the return times are slowly increasing. Maybe it's failing for this type of transaction. Maybe it's failing with or this IP address or like there's so many variables that go into that that it's really hard, especially at an automated level to say conclusively, this is down for everybody or down for even just you. So there's a lot that goes into that pot. I think we want to do more of that going forward. I mean, there's definitely an opportunity to do that. I just said how hard it is. I didn't get it. Yeah, it's true. That's normal. That's true. So, but it's going to require a lot of analysis. Normally detection is really difficult. The whole industry struggles how to do this in our stats and system stats and system metrics and it's even harder when it's a part of it. It's going to move from you and I on systems. But we have data, we're getting more data. I think there will be a lot more we can do with that. Okay, as one of the largest concerns for providers right now is data privacy. How are you handling buyer data with respect to the new GDPR requirements? So it's a GDPR applied to questions and answers. Yeah, so, where's LA with the lowest drag? I can't get it right there, this is easy. So we do plan. I think there's a couple that we do plan on. We are GDPR compliant. We have a GDPR, DPA, if you'd like for us to sign. I do like for something from our side, we have a GDPR, a DPA. I think where we're a little bit fortunate that there's two ways PCI is obviously fairly strict set of regulations. So as a small company, we train in the ground up to have a lot of regulations in place and controls in place. And then the amount of actual data we see is pretty limited, we're not, you know, I'm not going to accompany you or not. Even an expandable payments company that might be trying to take an address, shipping address, things like that will vary for hand and judge critical data. So, which is important, but it's also a fairly limited subset of data. So that's what we're doing. We have a fairly international company there, so we've been announced about GDPR, it was out in the middle. And a conflict process consulted with lawyers and consulted with bigger companies in the space that look like, oh, I'm up to there. Likely to them, they have so these dedicated GDPR teams. And so come up with our processes. And all of that, yeah. I think if you need more information, I know if you email support, we have a lot of stuff we can send you with more details. Also, I believe we're gonna have a public facing page go out very shortly, that will be accessible to everybody that kind of goes into some details around what our GDPR stance is and what your responsibilities are and where we see that division of responsibility. And overall we see our goal is enabling our customers to be compliant with our grant because we're storing your data. And so will we initially manually handling requests as they come in? Because we just don't know how many there were. We were, whatever the previous one was. Privacy shield? Privacy shield. And we were doing some research and we were getting schooled upon GDPR and we looked into the arbitration service and they had had like two requests under like, no, zero requests. No, they had one that got withdrawn or something, right? Yeah, so they had like one or two and they got withdrawn over the course of like two years of that program and this is the whole arbitration and never the free one so we figured lots of people were probably on board with them. So we don't know what the vibe would be around GDPR. So initially we're going to get a longer term. Okay, what are your thoughts on the idea of tokenization of things that are not payment methods? And do you see freely only supporting payment related tokens? Or do you see the future including more token types? Yeah, we're a payments company. I mean, we have a class around social security numbers and data and that sort of stuff and that is outside of our purview interests. We really want to focus in on payments, on payments APIs, on payments product and that's what we build and we'll work side of the building. So we don't plan to tackle other things. Yeah, so it's a relatively common question because we haven't followed, because we tokenize and we see people come in, you're primarily looking for a vault for all the things first and payments might be a self section of that but we're very decisionarily and often just continue to focus on payments and help you secure a vault for all the things. I think one thing that you've talked about a lot is vaulting a thing and tokenizing it is great but then what do you do with it? And so that's where all the domain specificity comes into play or the vertical industries that piece of information relates to. And so that's where all the hard work is really. I mean, a lot of our engineering effort is not on the vault itself that was done once and done well. It's now, what do you do with that information? So it's less about tokenization and more about what you're doing with the data after that that really comes into play and kind of guides what we think about things. Social security! We just love payments API so much we really want to deal with healthcare API. Walking off that stage. Okay, can you describe what happens when a single payment gateway goes down? How is it communicated and resolved? Okay, yeah. Oh, this is for you, Ryan, sorry. Yeah, so there's... I mean, we would view that as an incident, right? So we have an incident response process hopefully you've only had very few instances to have to interact or care about that but if a gateway is down, we've talked about anomaly detection before. We don't have systems that will automatically create issues and whatnot when one gateway is down. Let's not say we don't have visibility in alerting that's not what I meant to say. So there's the detection phase, like is this an issue, right? So we see their customers written in or it's a high-volume gateway that is down hard and we've noticed it, our various alerting and whatnot. So we will, at that point, determine is this an incident? So there's a basic triage phase. Is this an incident or is this, you know, something on the gateway side or is the customer doing something wrong, right? So you kind of have to dig in to understand where the issue is. But at that point that if it's a gateway down, it is an incident. We open a public status incident and we communicate as we kind of dig in and understand what's happening. Is there any remediation that you can do? Is there anything we can be doing or is it just purely on the gateway side? So it's really about, at that point, transparency and trying to put workarounds in place or at least educate you about what you can do. I think one of the most fun things we get to do when somebody says to me, now I'm just trying to figure out what's actually going on because it could be the gateway, it could be us. It could also be the customer just as the other day somebody wrote in and said, this gateway's down. We looked and said, well, there's transactions and it was a low volume gateway anyhow and they said, oh yeah, we're going to my server and everything's fine now. So sometimes we really have to dig in and figure out is this actually an issue that's freely that we break something into the adapter? Did an SSL cert go out of date? Do we need to update? Or is this happening at the gateway? And we need to make sure that customers have the information that they need and a lot of times we have more visibility but at the end of the day we need to follow up with the gateway and find out what's going on. There's definitely a lot of opacity in this industry and I think we always try to lead with transparency. Hopefully we are giving you information about why a transaction failed and the error response and whatnot and the transaction transcript itself which is kind of like just a text stream of the state of a connection to the gateway. Like we're trying to give you the tools so that you're empowered to be able to make those determinations yourself but that only goes so far. There's still a lot of work that we do on our side to determine what's actually happening. Okay, here's a follow-up question on Spreedy's roadmap. How does the evolution of real-time payments methods and systems impact Spreedy's roadmap? Real-time. Yeah, I don't know if we can clarify that. Yeah, if anyone could ask that question and wants to add some clarification or feel free to submit again. What tech in your stack do you most regret adopting? We are getting tough. Well, I often say that a lot of the stuff is my fault because I apologize to the employees because they have to deal with stuff that I didn't pass so I guess I could go. I think one of my biggest regrets is not a technology in general but it's a particular use of the technology. We adopted Redis for a particular layer of our indexing and for a period of time and kind of didn't pay close enough attention to it to the point where it was swapping massive amounts of data out of this and so even extricating ourselves from that use kind of involved doing rocket surgery and flight. So that was the biggest regret. Yeah, I think if you read any of our post-mortems we try not to name specific technologies or vendors despite what Nathaniel just did up here which is a close group. You said this for other things though. Yeah, we're very happy with that. So I would say that and culturally too a lot of what we try to do is make sure that as engineers we are making well-reasoned decisions but are also acknowledging that one week from now six months, two years, the same factors that were relevant and good factors or a good approach to making a decision that led to a certain choice may no longer be relevant. That's not, it doesn't make it a bad choice. It's just that now we have more information than we did before and so maybe we would have made a different decision. So I think there are a lot of things in our stack that have pretty heavy tradeoffs like, you know, REOC. We had a lot of lightning talks about REOC and what that choice has meant for our architecture and so we get a lot of great benefit from it but a lot of hardship too and I think we are still of the mindset that those tradeoffs are worthwhile and valuable but that applies to any decision too. So I, you know, maybe using Redis in that way maybe it was the right decision at the time with what we knew but we tend not to be pretty hard on our technical choices and I can't point to any one point in time where we made a decision and like immediately had to back it out. I'm still pretty glad that back when we started core we did not use Mongo. Well done. Good choice, yeah. Even though REOC has had its problems still really happy that we did not use Mongo. I think one thing from a pure engineering perspective if I could snap my fingers and change, again not to say it was a mistake is using Ruby. So we use Ruby for our core processing systems every time there's an API call out to another gateway it's a Ruby process sitting there holding open that connection. It's very resource intensive. Ruby does not, doesn't have a great concurrency story and it's why we've really started investing in Elixir and basically every new thing that's happening in the platform you can say pretty much without exception is Elixir based just has much better performance characteristics for our use case. So I think Ruby was a good choice at the time the ecosystem was so different eight years ago now though I would love to snap a finger and have another language in there. Okay, what are Spreedley's plans for countries where credit cards are not the dominant payment method that echoes an earlier question? Yeah. Yeah, so I think that question is a good question I think that would fall on their alternative. Right. I understand building payment service building a payment service is not easy but it's not obvious to people outside of this domain could you elaborate why building a payment solution is hard? I'll lead off kind of maybe the most obvious way that it's hard is the maybe this is specific to our place within the payment stack but a lot of companies out there are good at financial and transaction processing not good at building technology that exposes those functions and our job is to integrate via APIs and via technology with these companies so we are having to take on a lot of pain that's our business though we're taking on that pain so you don't have to but man it makes what we do hard and there's a lot of overhead we've learned a lot we've done hundreds of integrations at this point so we've got a really good system and really good engineers that know how to deal with these types of things but it doesn't make it easy a lot of times it doesn't make it fun so that's certainly one pain point I think an interesting experience for me is when we began we really just focused in on startups and so everybody who was coming along and signing up and using us was like oh this is great like this would have been two developers for me five developers for me and got a bit like I have to do PCI compliance but it just scares the heck out of me and so the logical question was what happens when you start when they become bigger for our customers or we go in and talk to logic prospects and I remember going into a logic company and asking them why wouldn't you just build what we have and they said oh my god the pressure we would have to build it to get it certified and then if we wanted to make it change we'd have to go through six or nine and go through a whole month in terms of IT approvals to get that change rest of the time if you're in a service and make changes real-time so that was pretty eye-opening so I think it depends on the stage you're at and some people if they're smaller the blessing of us is is the fact that they don't have those resources to build something like Spreatly and then larger companies that have the resources that could replicate it for them it's like oh it would still be problematic to change and go outside of PSP I want to go and deploy those things deploy those resources on what we do as a value-added and doing reviews of the value-added for us that have what we do it is way more cost-effective or sensitive I think there's kind of like two questions actually sitting in there and one is what makes Spreatly hard or what makes a company that's fully just focused on financial technology challenging then there's what makes a business that needs to do financial technology things challenging I don't think Spreatly is particularly more difficult than any other business every business has a problem that's going out and solving and one of the awesome things is that we get to focus in on this financial payments technology problem and do it full-time and a lot of our customers it's just 5% or 10% of what they need to do and they would much rather focus on the rest of their business so we get to take that piece and make it much easier for them to go tackle and we've had plenty of startups and smaller companies we couldn't have done if you didn't take this off of our place it would have been difficult for us to tackle that because it would have been a full-time job if we didn't get this much of our time to it so it got and then what makes our business hard specifically compliance security uptime in particular like it's not a consumer service it's not like Facebook where I can just grow some percentage of consumers at a particular page and then find out oh it's airing out let's take them off of that again we have to be really a lot more careful and deliberate we still have multiple times a day and many times a week but that's been a lot of work to be able to do that would you consider offering a private link API for AWS customers that's probably an enterprise feature so we have some enterprise sales people here that would love to talk to you about that we're currently in the process of giving AWS and people have a lot more options once we're done we're iterating through basically standing that up so it will be active active and once the majority of the service is active in AWS we can start looking at some more specific features around co-locating customers in the interview what do you look for from a cultural fit perspective when you're looking to hire also from a cultural fit perspective we've been talking about this like all companies we've learned from trial and error I think the most challenging thing is when you hire a really smart it's easy to hire somebody who struggles in their role maybe who's great at you clearly doesn't have the skills to do it it doesn't work there, they're stressed I think the interesting thing is when you have someone who's completely quite gifted, quite bright knows how to do their role but they don't fit in your company it's not working for them it's not working for you and we have realized and talked about that a lot internally where and Ryan talked about us as a startup but many startups have a different culture than we do so many startups a VC funded have a board to have very hands on C level leadership and that board VC C level is really really driving the culture of driving the engine driving the direction and people are given orders to go on executing those orders and that can be very exciting a lot of people are working in an environment there's a mission, you're going out and changing things but the decisions are usually made in a small hub and then the orders are given and it sounds a little over the top but direction is given and people go on and execute that direction and specifically what we do is we have much more dispersed control out to the group so we all understand we're trying to build this payment infrastructure that has a lot of uptime how you decide whether you're in engineering or whether you're in sales whether you're in success or you're pushed out to people to make those decisions and to run, make mistakes and get things right so where we struggle is with people that are bright and good but they're looking for more guidance and more hands on direction sometimes that's as simple as because we've hired them in and they're too inexperienced and shame on us because we're not giving them the guidance that they need so we learn that but sometimes it's senior people in the culture where they're like wait, I'm waiting to be told what to go do and then I go and execute that and we're saying okay well that's not how we were working so you know this is like latency I guess right they're waiting for us and we're waiting for them so I think that's the sort of thing we've learned and I think the final sort of piece is just another interesting thing early on big families the founders had a lot of a lot of kids a lot of families so we were not the places like doing the kids it's p.m. like we're like you know we're going to get out there we've got lots of kids to do so take care of all the things to do so I think sometimes for people that are excited about that some moves to this area and they're in their 20s and they want to take a job and they want to meet people and they want to socialize like that's a good component to taking their role we might not be the best place for them we're like 5 minutes to 5 say I'm going I'm going wait who's here who's going for drinks like we just don't do that well and I've worked with startups that did that well so when we first started I had like these like oh I can't be sweeten that thing for those people too but you realize we're counting that thing for those people so sometimes it's like that cultural social work life piece a lot of stuff sort of an extension of your personal life and that's really fun and exciting I'll say that we're in the middle of hiring for an engineering manager and we think about hiring a lot I think it's not an exhaustive or exclusive list but you know self-direction is very important positivity and maturity and I think inquisitiveness like those tend to be properties of people that do really well at Spreeley so go that out there and I will say too like just straight up we have to be back, I'm just because we're handling a lot of credit card data it's really sensitive stuff and so character managers a lot too and we've learned to be pretty strict around that so if you got that ticket while you're driving the dominoes in your early teens we can so this question is in the context of payment method distributions of PMD how do you scale new merchants quickly for PMD PMD is great because we have to do very little work we being Spreeley it's a pretty low level type of integration we provide some basic framework and a templating language and you kind of have to do all the work so a lot of our overhead is more around the compliance of that particular endpoint, they're not a gateway so a lot of times they're not listed in the normal list and it's not easily verifiable to their PCI compliance so a lot of our overhead is more at the administrative side of confirming their compliance and then it's an ongoing thing you don't just confirm a compliance once and you can go for years on them so there's that bit of overhead but at the end of the day you're having to do a lot of the integration work and understand their API we're kind of hands off it's hard because we if we get a support request and somebody's struggling with a PMD integration we want to help out and I think we do we try to do our best to point you in the right direction but that line of responsibility is further on your side than it is for a gateway integration where there's a known common vocabulary and common way to integrate that we can then expose to you much more open-ended I think it's an open area of exploration for us too potentially adding more structure on our side not just from a tactical perspective but also potentially from a business perspective maybe start to have some partnerships and that problem we can help our customers reach out to the endpoint so we'll see more developments there's that balance between functionality and flexibility we can try to give more structure a lot of times that might cut you off from some things that you want to do great what's the latest status on Google Pay integration? Google Pay is in private beta I think I talked about maybe someone can explain the first presentation so Google Pay is available in private beta contact success contact your account manager if you're interested I think as Didi said you see her around talk to her as well she's doing the implementation so she'll have a lot of the gory details if you're interested in that type of thing I mean I think literally we got our first payload going back and forth yesterday she's been cranking on it so we're in the process of getting production activation so we're just building a list of beta customers that are set to try that out as we get it and I think if you're familiar with how we've done Apple Pay and even Android Pay it should feel very similar to you so if you have that as a reference good starting point great the next question is probably a little more in depth for 527 so we'll park that one skip it all together I know exactly what the last question is let's see we weren't told that Happy Owls started at 530 that's a 10 minute wall that's true that's true you just said we weren't into partying after hours King exit 530 so it lasts 2 then we'll end on 2 can you describe your relationship with gateways so there's 100 at least 120 that we support so there's no single answer we have some gateways that we work very closely with I think the first step is what's the gateways culture like and you know and so I think early on many gateways started as a competitive server payments API, sort of organization server transfer and re-director free down the good news is I don't think we run into that anymore and then I think gateways so full in two categories that CIS is a necessary you cool or it's like okay I just did using them I don't really get it all they're not taking the processing from me and then the other group would be people who probably get the value share a lot of merchants with them a lot of transaction a lot of processing so those two categories I think the good news for you is the more the larger the gateway the better chance of development and they work well with us we have account manager relationships we have technical contacts we have support contacts but again there's a hundred and twenty so there are many that we support a typical level where we don't have accounting relationships there with those gateways right so there was one other question that was a great one but I'm going to conclude on this last one which is why the name Spreedly haha so first of all it was L.Y. Everything when we started Spreedly and we were fanboys but basically the original founders started out as subscription management service and so the original founders we just needed a code name so the very first name of Spreedly was Subnut so you can all be glad it's not so called Subnut and so the four original code there's all three names and two and a half and we used a condorsant method a frank voting method and we voted and let's just say there's lots of names in that list I went back and looked at it there's a bunch of them we're really glad we didn't take those and you're not coming to the conference for SubCal haha and Spreedly came out on top Shopping Spree was the kind of high in there but yeah so put together the time period and the L.Y. Everything and Shopping Spree something will come up with some great fictional backstory like you may have yeah yeah yeah Justin now wants to go right a completely fictional backstory haha haha okay