ALEX GINET: Hello. Welcome. Thank you for being here. We’re excited to have you. Welcome to Sessions. My name is Alex. I’m the head of product for core payment at Stripe. And today I’ll be talking about multiprocessor. So we’ll be talking about when to consider it and how to go about it. Before we start, just a show of hands, I’m curious who in the room already has multiple PSPs or is actively considering it. Okay. I see a good amount of hands. You’re in the right room. Perfect. And this actually matched what we see in industry research. About 62% of enterprises actually suggest they prefer to use multiple PSPs. And it’s pretty appealing, right? You can avoid vendor lock-in, you can reduce your payment costs, you can expand globally. The reality though, maybe many of you in the room know, every PSP you add adds a lot of complexity.

And so today we’ll really talk about three things to really help you weigh the trade-off of going multiprocessor. First, we’ll talk about why you might want to go multiprocessor. What are the common reasons that we hear in the market and from our users? And then my colleague John will come on stage and talk about the different implementation paths. What are the trade-offs between the different options you have? And then Josh from Canva will join me on stage and we’ll have a little fireside chat. We’ll talk about Canva’s experience of going multiprocessor and what they’ve learned to share with all of you. So let’s get started. Why go multiprocessor? So we’re going to try something here. This is the first time you’re doing this, this is the first time I’m doing this. If you can try to scan this QR code, pull your phone, this should take you into the sessions app.

And I want you to answer this question: why are you considering a multiprocessor strategy? Is it redundancy and reliability? Is it performance and cost optimization or is it geo expansion? In practice, it may be multiple things, but try to pick the one that resonates the most. I’m going to see if this is working. I’m seeing some votes coming in. So please keep trying. I’m going to give you a minute here.

All right. It’s pretty balanced. All right. Okay. Oh wow. Okay. I see now a lot of responses. Okay. So it’s pretty balanced. Looks like performance and cost optimization is the winner though. And no surprises. We hear this a lot from our users as well. So let’s dive in. And so what are the benefits of going multiprocessor? The first one is to avoid a single point of failure. Let’s take an example. Let’s say you have a single PSP and you’re having unfortunately an outage on your biggest day of the year. Maybe it’s Black Friday. Maybe it’s a big product launch day for you. Maybe you’ve had a marketing campaign all week. What happens? Your sales stop, your customers are leaving. Maybe they’re going to your competitor. They start complaining on social media. Your internal teams, your finance team is asking what’s happening. A nightmare scenario that you try to avoid at all cost.

And the damage can, of course, be really severe. A survey into large enterprises suggests that about an hour of IT downtime can be up to $5 million in lost revenue. And it’s not just revenue, right? It can be your reputation, your brand as a company, it could be your stock price if you’re a public company. And so in many cases, multiprocessor and redundancy is actually a boardroom mandate. And maybe for some of you, that’s the case. And so when you have multiple PSPs, if your transaction fail on your primary PSP, you can instantly retry in a second processor. You saved the sale and you’ve protected the customer experience.

Moving on to the second reason. A lot of you, and we just saw in the survey, are actually going multiprocessor for the idea of improving performance. And you can intelligently route your payments between the different PSPs that you have. Maybe you do it by type of cards or by regions or by amount or many more sophisticated strategies. And to improve your performance, that means potentially reduce your cost, your processor costs, your network cost, but also improve your payment success rate, improve your auth rate. And so we’ll take a very simple example here. Let’s say you’re a business running about a hundred million dollar a year and you have a first PSP, which has a 95% auth rate, but then you decide to run a champion challenger test. And you find that the other PSP actually has half a percent more authorization rate. Well, that means $500,000 in revenue for you directly for your business.

So it’s a very tangible reason why you might want to try to optimize between different PSPs. And then finally, we’ll go to the third reason, which is geo expansion. For all of you that are considering geo expansion or maybe actively doing it, you probably know that the hard part isn’t really to figure out where you want to go next. It’s really the investment required to build that infrastructure, operate in that country, potentially integrate with a regional PSP, integrate with the local payment methods. That can be a month-long projects or maybe a year-long project. It’s a massive amount of time and investment. But the payoff is pretty clear. One in three buyer will abandon their cart if they don’t find their preferred payment method at checkout. And even if you make the sale, the cross-border processing fee can be 10x more than domestic. That also directly eats into your margin.

And so with a multiprocessor strategy, you can maximize your reach, and in most cases, do so at the cheapest cost. So if any of these resonated with you and your company’s priority, the next step is going to be to evaluate the different implementation path. How should you go about implementing your multiprocessor strategy? And for this, I’m going to have my colleague Jon Krauss come on stage.

JON KRAUSS: Thanks, Alex. You sold us. We’re ready to implement. We want to go multiprocessor. How do we do it? So really there are just two paths: you do this in-house. You figure out what connections do you need, you stand those up, you maintain your data, or you work with a third-party orchestrator. So I’m going to dive into those and Stripe supports businesses across both spectrums. But first, we’re going to try this again. And now you guys are professionals. So please take out your phone. And I saw earlier, many of you raised your hands that you’ve started on this journey already, and share how long have you been working on or did it take you to integrate an additional payment provider? Was it six months, 12 months, two years? Still working on it. Please share. Okay. We have some swift engineering teams represented in this house.

So I think that the bottom line here is it’s not a de minimis investment. So while the benefits are compelling, as Alex outlined, it’s a significant commitment to go multiprocessor. So let’s talk about the build-in-house solution. Why would I do this? I would do this for maximum control. Payments is a top priority for my organization, and I can’t afford to outsource this. I need to be in control of the routing strategy. I need to be in control of the retry strategy. It needs to integrate perfectly with my own other systems. That’s why businesses go in-house. However, there’s significant trade-off, and it seems like many in the room understand that, and it’s cost. So you need to stand up this integration yourself. So you’ve got a new processor that you want to connect to. That’s a net-new connection for your business, and you have to maintain the payment data yourself.

The payment data is PCI sensitive and has the highest degree of scrutiny from a compliance perspective. And on top of that, you need to maintain that data. If you want maximum conversion, maximum authorization rate, you need to use things like network tokenization, card account updater, and those are independent integrations themselves with the schemes. And then on top of that, you need to maintain all of this. So you not only have to stand up this integration, but the requirements can change over time. There’s an ongoing operational burden. And one of the misconceptions that we see most often is businesses that feel compelled to do this themselves. They start down this journey and they realize they cannot sustain the investment. And they’re actually in a worse-off position where they’re sort of buried with a sort of half-built solution and they don’t have all of the features and requirements that they need.

So that’s where a third-party orchestrator comes into play. And the benefit is insulation from this technical burden. So rather than maintaining all the data, rather than maintaining all the connections, I integrate to this third-party orchestration layer, and it’s all of those connections are available to me. All of those optimization features are available to me. You get speed to market and this greatly reduced technical burden. But that also has considerations. So first and foremost, the data is no longer directly in your control. So if you need to synchronize data across multiple vaults, if you want to make use of those network token features, card account updater, you got to make sure that that orchestration provider has all of those capabilities. In addition to that, we’re adding an additional layer in the transaction journey. So this can create more latency. So because of that additional step, there are added milliseconds to the end-to-end transaction flow.

So this is something that you need to scrutinize when evaluating a third-party orchestrator. And then lastly, and most importantly is reliability. An orchestration provider gives us optionality downstream of the orchestrator, but it creates concentration risk with the orchestrator themselves. So if the orchestrator goes down, you have a single point of failure. Thus, the availability of the orchestration layer is probably the most important component to evaluate.

So in summary, we really have two viable paths. We can do this in-house, maximum control, full purview, full responsibility for the outcome, but at that full cost. And again, not just a point in time cost to stand up that connection to the new processor, but the ongoing cost of maintaining this more complex setup. And then the alternative of working with a third-party orchestration provider—speed to market, insulation from the technical burden, but a new sort of concentration risk to evaluate along with certain controls and features that you need to make sure you have.

So I’m pleased to share, Stripe has Orchestration. It’s a significant investment that we’re continuing to build on. And I think the main component that we’re most excited about is it’s built on Stripe’s core infrastructure. So you heard Will, or maybe it was Patrick sharing that we had 99.999%—five nines, sorry—percent uptime, and that applies to Orchestration. So that risk that we need to mitigate around single point of failure, Stripe is investing heavily to mitigate that. And in terms of portability, Stripe supports what we call the forwarding API. So you are able to extract your payment data to any endpoint that you require. And if it’s PCI sensitive, that endpoint just needs to be PCI compliant, and new endpoints can be stood up in a very short period of time. And again, this all ladders up to this idea of, you’re in control. Stripe Orchestration is an investment in a broader strategy of an open architecture.

You’re not going to have to be locked into Stripe. You don’t have to use every component that we have. It’s just what you need with maximum flexibility. And an example here, so this is a real-world business, 123cards. So they operate in a hundred-plus countries. They’re an online greeting card company and they’ve adopted Stripe Orchestration. So they were able to do this in a very short period of time with minimal technical, infrastructural overhaul. And in about four months, they were able to double their dunning recovery rate, so their retry strategy on subscription payments, and it led to over $140,000 in recovered revenue. So this was incremental to them, and it was very material. So again, a proof point in what Alex was talking about earlier on having multiprocessor can boost revenue and conversion.

Beyond Stripe Orchestration, we’re committed to this open architecture. So I think you heard about it at the keynote. If you were able to join for the keynote, Radar is now multiprocessor. So you can use Radar API regardless of whether or not you’re using Stripe Payments. So you can use our signals about transaction risk and apply them to transactions processed with other providers. Similarly, Billing and Checkout, the subscription management and online UX conversion optimization toolkit is now multiprocessor compatible. So it is processor agnostic. So you can use our subscription management tools without having to use Stripe Payments. Same goes for 3D Secure. And it’s important to call out that all of these have dedicated talks here at Sessions. So if you are interested in learning more about any one of these, feel free to check out your app and look for the dedicated talk.

So before we move on to Josh, just in summary, I encourage you all to think about this, take it back to your teams, evaluate what would the hour of downtime cost us, what could the optimization of multiprocessor look like? And then if you think this is really something that you need to pursue, think carefully about the trade-offs. Can we do this ourselves, not just for this initial investment, but on an ongoing basis? And if not, who’s the right provider to work with? And in fact, Slalom, one of our partners has a booth here and they specialize in multiprocessor implementation. So if you’re interested in carrying on the conversation further, stop by Slalom’s booths and bring up this topic and see what they have to say. Okay. So with that, we will hear more about a real-world journey. So I’m going to welcome Josh Barton from Canva up to the stage. Josh is global product lead and Alex is going to come back up as well to talk to him about Canva’s journey.

ALEX GINET: Thank you, Josh, for being here with us.

JOSHUA BARTON: Thanks for having me.

ALEX GINET: Yeah, of course. I was going to complain about my six-hour flight to get here, but Josh is coming all the way from Australia to be with us.

JOSHUA BARTON: A little bit longer, working hours.

ALEX GINET: Longer, yeah. Well, we want to hear about your experience. We want to hear about your journey into the multiprocessor world. And so maybe to get started, curious about your decision. Why did Canva and why did you decide to go multiprosser?

JOSHUA BARTON: Yeah, so we did this quite some time ago, and I think the real reason why we did this was redundancy. We accept payments in over 190 countries and having downtime, and not just full downtime, but degraded performance would mean that we’d lose a lot of revenue as we saw. We also knew we’d get some performance benefits, like when you fall over and get the second PSP to get some uplift there, and we’d avoid the lock-in, but primarily redundancy.

ALEX GINET: That makes sense. And then yeah, that seems to resonate with our audience today when we saw the poll. Did you actually get the benefits that you thought you were going to get?

JOSHUA BARTON: Yeah, we did get the good redundancy benefits. And the easy scenario and the boring scenario is the PSP goes completely down and you route around it and you go to your other PSP and you’re still up. That’s very uncommon in this day and age. The more interesting scenario where we really got our money’s worth is the degraded performance. Stripe says they have five nines uptimes. Everyone say they do in the PSP world.

ALEX GINET: I don’t think that’s true but…

JOSHUA BARTON: But what they don’t tell you is that doesn’t include degraded performance. If a network goes down in Mexico or if a payment method goes down in Indonesia, that’s not included in your five-nines uptime. So your orchestration system allows you to compensate for those ones and have full performance all of the time, which is what we see. That makes sense.

ALEX GINET: And so those were the benefits you went to Orchestration for. Is there any other benefits you didn’t really expect that ended up materializing?

JOSHUA BARTON: Yeah. So other than redundancy, we went in thinking, yes, we get some performance benefits as well, and we thought, it’s going to be fallback. We try on one, it doesn’t work, we try on another, and we get a few percentage points uplift or fractions of percentage uplift. What we didn’t realize at the time was actually the real power is where you send the traffic the first time. So we went down this track of, okay, great, let’s route by country. And then that gave us good uplift. But just when we thought we knew what we were doing, we realized actually, country is not the real signal. It’s going to be BIN and issuer. And then we started routing by BIN and issuer. And then we realized, wait a minute, this actually is not the real performance indicator either. We had to go and create separate mids in multiple PSPs. So you had a mid for good traffic, a mid for bad traffic, and then you started getting performance through there. So the honest—

ALEX GINET: And all the combinations and you get into the combinatorial of—

JOSHUA BARTON: Yeah, exactly. So we started off with a redundancy system and all of a sudden we’ve got a full payments optimization solution. It’s a lot of fun, but it’s a lot more difficult than what you think it’s going to be.

ALEX GINET: Let’s talk about how you went about in doing it. So I think you built a system completely in-house, right? Any challenges that you faced when you did that or?

JOSHUA BARTON: Yeah, that’s correct. So like most startups in this room, we started off with Stripe, and we’ve been with Stripe for I think close to 10 years now, and they’ve been a great partner, but we got to a point where we were like, we’re doing, 95% of our payments were card payments. So our first, we thought we need a second PSP that’s specializing in card payments because we want that redundancy. So we’d put that in. And again, we didn’t think we had an orchestration system yet because it was just two. It’s really when we put the third PSP in that we started to think, hold on, we need some more sophisticated logic here because it’s not only just fallback anymore, it’s how do I route it around? And that’s when our orchestration system was kind of born. In terms of challenges, there’s quite a lot of them that you don’t think of at the time. As John mentioned, it takes maybe six months or more to integrate a new PSP and that’s engineering time.

ALEX GINET: We have fast teams here. Yeah.

JOSHUA BARTON: Very fast, yes. And that’s the engineering time that you’re thinking about. But what you don’t think about and what you don’t put on your timelines is all the commercials that you’re going to have to do with the new PSP, like you’re going to have to negotiate contracts, do your KYC, this that and the other to get to even get you to the started. Then you do the engineering. Then what they also don’t tell you is you need warm-up time when you have finally started with the—

ALEX GINET: The new mid.

JOSHUA BARTON: A new mid, yes, exactly. So you’re spending three-plus months warming up and then after the warm-up time, you need to start tuning the settings in the PSP and in your own system before you get that optimized performance. So when you were saying six months there, it’s six months engineering time, but you end up a lot more than that.

And finally, the other thing that no one thinks about is all of a sudden when you’re doing chargebacks or you’re doing refunds, your operations team now has to go into a second portal. So you’ve got context switching there. Yeah, it’s all the things that no one tells you about before you get started.

ALEX GINET: Yeah, no, that makes a lot of sense. And I think we see it on our site too with the customers we work with, they always take much longer than they think they will. They’re like, “Oh yeah, I want to integrate on Stripe Orchestration, but wait, I need to work my contract with my, and my compliance team hasn’t agreed to it.” And so we see that a lot as well. Maybe can you give us a sense of the sort of resources you’d had to allocate to this kind of project sort of reality of the teams that engineering effort—

JOSHUA BARTON: Yeah, we have a lot of people in our payments team at Canva, close to, I mean, once you start including operational people, it’s close to 30 people just working on this. So it’s not a cheap, easy fix to do. It’s something you have to commit yourself to.

ALEX GINET: And you have to think about the ROI of those resources, what else could they be deployed to? And that’s not always easy to-

JOSHUA BARTON: Exactly. Exactly. So there’s cost to all of this. So got to stack it up with your revenues.

ALEX GINET: Or you think about integrating an orchestrator, right? And I think you are starting to think about that potentially on your side and what are the consideration as you’re thinking about working with an orchestrator?

JOSHUA BARTON: Yeah. So to put in context of what we are doing and what we’re thinking about doing is, so we’ve got our home-built orchestration platform that we’re very happy with. We’re not looking to go away from that, but we want to put a parallel stack beside it where we have a parallel orchestrator where, that six months engineering time, we get rid of it. We know we’re going to still keep the tuning time, this and the other, but we wanted that parallel stack there where we can test a PSP or test a PSP on a smaller niche market where maybe the revenue doesn’t stack up when we look at that ROI. So when we’re looking for that orchestration platform, that external one, there’s a few things that come to mind. One, reliability. You don’t want to add another point of failure in there. So if they don’t have the five nines uptime that Stripe does, all of a sudden you’re bringing Stripe’s uptime down because the orchestrator’s how you get there. So you’ve got to think of that. Also, a lot of orchestrators out there will tell you they connect to 400 PSPs, but no one’s going to use 400 PSPs.

It’s all about the quality of the integration to the PSPs and depth of that integration rather than the breadth of integrations that they have. I know we’ve integrated, we have five PSPs that we’ve integrated to, and different integration levels get you different performance. So make sure you have the best possible integration to the PSP that you want to use. And then of course, predictability. When you’re choosing a partner, especially in payments, you want to know that what you see is what you get. Are their documents correct? When are they going to settle? There’s all of these things that they’re going to promise you. You’ve got to make sure I trust them, it’s going to be predictable because payments is working with customers’ money. It’s very sensitive, and we’ve got to get that right.

ALEX GINET: And it sounds like you’re thinking about an orchestration solution also as a way to sort of quickly test versus the investment of building the entire gradation yourself and maybe eventually getting there depending on the results you’re seeing from that test. And yeah, that makes sense. Great. Well, Josh, you have a lot of people here in the room who are on this journey. They’re thinking about it. Maybe some of them have started. If you were sitting in that audience today, what would you want to hear from you?

JOSHUA BARTON: I think firstly, it’s worth it, so do it. You’re going to think at times, this is horrible. I should just go back to one PSP because the engineering resources is a nightmare, or the operational resources are a nightmare as well. But at the end of the day, you look back and you have a look at the uplift, and that uplift is, wow, really? So it is worth doing. Don’t give up. But also really take the time to develop good partnerships with your PSPs and don’t be flippant about adding ones in and out. We’ve found the best performance have come with working with our PSPs like Stripe over a long time, over many years to get that really, really good performance from them. As I mentioned earlier, it’s not just turn a PSP on and you expect best performance from them. It’s not going to happen.

You will get good performance after the three months warm-up of your mid and then maybe another three months on tuning it, but it really comes in the years to come when you’re working with your PSP closely, that’s when you get the best performance out of them.

ALEX GINET: Great. Well, Josh, thank you so much for joining us. Safe travel back to Australia.

Thanks to all of you for joining us today. Have a wonderful time at Stripe Sessions. If you’re curious about any of the things we talked about today, you can also go to the payment optimization booth for Stripe in the expo hall. So thank you so much.