Orchestration layer: Controlling complexity w/Payrails

Speaker A: Foreign.

Speaker B: Uh, we are here at MPE 2026 and we are uh, here, uh, in the podcast of voice of mpe. My name is Andre Moller. I'm leading the payment risk and fraud at Volkswagen Group charging and we are in charge of everything which is E mobility across the brands. And I'm here with um, Alex from payrails. Uh, May give us a couple of words to you person.

Speaker A: Yeah, thanks. Thanks Andre. Thanks to the voice of mp. Um, I'm Alex. I'm responsible for the new initiatives at Pay Rails. Um, basically we're an orchestrator, plus uh, more services and I am responsible for kind of how we expand the products beyond the traditional core orchestration and vaulting.

Speaker B: I remember you are staying for a very long time in payment industry like I do also. And you do a couple of things before. Now you're moving, changing the side of the table, going from the merchant side to the supplier side and uh, be part of Pay Rails payment orchestration. What's the difference between Pay Rails and other orchestrator like Prima or Ixupay or something like that?

Speaker A: Yeah, no, that's correct. I've been in the industry for like 13 years now. I've been both on the PSP side and on the merchant side and trying also to build a consumer payment product. Um, I think Pay Rails is different than the other orchestrators, um, through maybe two things. One, we don't actually see ourselves as an orchestrator. We see ourselves as more of an operating system for the merchant where orchestration is just one of the things that uh, we do for the merchant. It's orchestrating about integrating the different providers, routing retries, all that. But we do way more than that because when you think about what a payment transaction is, of course customer clicks the buy now button and he gets his stuff. So life is good. But in the back, everyone that works in payments know that there's like a lot of stuff happening and that's where Pay Rails is in my opinion, at least from what I understand from the market is that we're differentiated, that we're trying to tackle the entire chain of events that are happening through modular agnostic products. So we have like a fraud prevention orchestration module where you can kind of uh, use different fraud providers. Through us we have the orchestration which is the typical, you know, integrations, routing retries, etc. We have then post transaction, uh, data reconciliation. Um, so we get settlement files, we get order data from the merchant and try to kind of match them and uh, simplify the accounting process. We have uh, Performance and cost optimization products which are basically looking at getting data from all the sources of the merchant also outside of what payrolls uses, um, and give uh, the merchant a complete picture of both cost and performance together with insights on how to improve. We have a chargebacks product now that we're just uh, rolling out which is trying to solve the problem that when you work with multiple acquirers you get chargebacks from different places. And not just acquires in the card Sense, but also PayPal, Klarna, all the payment methods that have consumer protection have some sort of dispute system. And we're trying to optimize and streamline everything through that. And basically everything that happens after the buy now button. We try to create an agnostic product and we're not um, you know, trying to sell everything to everyone. Uh, and this is maybe the second differentiator. We're very open and we're building the parallels with this in mind that we're building these agnostic components and we just want to go uh, to our ICPs, to our enterprise customers and solve problems immediately. We're not trying to reinvent payments. Reinventing payments sounds nice. And many of our competitors actually pride themselves and this is a state of the art new innovative, blah, blah. But reality is when you're processing billions per year, you can't risk everything, uh, change your operations for an innovative product. Even though the innovative product might be innovative. You need to work with what you have. And we're trying to build these modules, these agnostic products to fit into the existing merchants uh, system and just plug in the hole right away, bring value. And then we work very closely with the merchant to try to, to expand the solution to cover more um, problem areas. So that's what I would say is different. We're not like a take it or leave it put everything, um, we're more like we're building it agnostically and we're focusing way more than just the payment itself. We're looking at fraud, 3Ds data, uh, reconciliation, chargebacks, the whole thing.

Speaker B: You mentioned, uh, the buy now pay later button, for example, I coming from, with our business, I coming from another uh, point of view, let's call it so, so Buy now, pay later, uh, gives me directly the iteration to E Com transactions like auto, like E Com shops and something like that. Our business is we talk to the customer, he make the onboarding, he give us his payment and in the worst case we don't see him for six months because he owns a house, he charged the car at home and then in the summertime he's going to Italy for example to make his holiday. How can I as a merchant be sure that the transaction in that environment is working well and how could I then set up for example a fallback uh, routing if the first transaction failed to not come into the mood that uh, customer account would be blocked and uh, m ruined holidays for our users.

Speaker A: Yeah, I mean in terms of blocking on the merchant side that's relatively easy. Um, um, because as a merchant you work with different providers and you're trying to always optimize for performance. If you're a merchant that cares about consumer experience and that means that if the first acquirer declines the transaction because of some fraudules they have, you can always try with the second acquirer and it will eventually work. If the transaction is blocked on the issuer side because of some card related problem, then there's little you can do. Um, but of course what we can always do is uh, make sure that the error codes are transparent to the customer. Um, of course with the balance of you don't want fraudsters to also know everything. Um, but yeah, that's generally how you would do it. And with orchestration players, I think all the orchestration players can do this relatively easily now. Uh, you can easily set up uh, fallbacks, you can easily set up retries, you can easily set up all sorts of uh, routine rules.

Speaker B: So I'm now here to merge and I'm the bad guy in that game. So if I see a payment orchestrator I see an extra cost of payments.

Speaker A: Yeah.

Speaker B: How do you handle this in the conversation with a merchant like me? Because um, the margin is always very low. And um, if we spend of this little margin, for example something to an extra cost like an orchestration layer, what's the challenge with a guy like me or a company I uh, work for to not saying let's work with one or two PSPs in Europe it's fine. But if I need an orchestration layer, extra cost.

Speaker A: Yeah, that's a great point. Uh, orchestration does cost money because orchestration companies are for profit companies that also have to pay their employees and have uh, technology costs and running costs, infrastructure costs, et cetera. Uh, so of course there will be a cost for that. Um, and maybe orchestration is also not for all the companies and this is why we're very clear when we're talking about sales and go to market at payrolls that we have a very specific ICP like ideal customer profile, which is this enterprise customer where we know that they need orchestration and then the question is whether they build internally or not. But they always need orchestration. So that's the first thing. Does the business need orchestration? And if they do need orchestration, then the build versus buy discussion is a lot easier. Once, uh, you've known that orchestration is something that can bring value, building, um, has benefits. You retain control, you retain the ip like the thing that I built, maybe I resell to somebody. Um, but in most cases, my experience has been that this is wishful thinking. Uh, if you're a merchant selling socks, your core competency is the supply chain. Getting the socks, getting the materials, building, uh, the marketing, branding. It's not really building the payment infrastructure. And if you want to operate in an environment. Exactly. If you're operating in an environment that's very complex, M, then the payments will be even more complex. Right. If you have a subscription for socks, if you have in person socks payments, if you have socks, uh, in, uh, you know, split payments on stocks and managing disputes and managing like a lot of payment methods, uh, across a lot of countries, managing money movement from different countries. This is not something that you want to build internally. And maybe you do want, but then it's the cost of building it will be very high. So what I always tell merchants, and the problem is now I work at an orchestration, so it sounds biased, um, but I have been in the shoes of merchants. I work with three merchants. And we've always overestimated our capability to build because of course everybody is ambitious. Um, but the reality is that building an orchestrator is hard. So what I would tell merchants is that it's good to use specialized products, uh, especially if it's not your core market, your core product. Like if you're not, maybe if it's like a high risk gambling merchant, then maybe it makes sense because that payment is kind of the only thing you do. But if you have like an actual business with complexities in the business, you're better served outsourcing the payment. And then of course you can always say, oh, maybe I just work with Adyen and Stripe and that's good and maybe that's enough. Right. Maybe you don't need orchestration. But if you do need orchestration, building it internally is going to be very tough.

Speaker B: Oh, definitely, definitely cost money costs resources and it costs, uh, much, much more time.

Speaker A: Exactly. Like a bias that people always have is, um, I don't trust the people. I don't know. Right. Imagine you go pick an orchestrator and you see payrolls or whoever else and you Say, I don't trust these guys. I would rather build it internally because I know my guys. But just because you know your guys doesn't mean that your guys are more competent. Actually, when you think about payments, it's this very complex environment. The guys that, you know that have been building a web shop to sell socks or whatever, uh, charging stations, they might not actually have the technical competency to build the payment system that you need. And even if the manager knows, and this is something that I've dealt with many times, um, and sounds arrogant, but I have worked in payments for a long time. I have a relatively good understanding how it works. If the engineers also don't know how it works, you need to always babysit them to make sure that are you building the right flag? Are you building that? So you need a lot of people to have really good knowledge, um, to be able to build a good product. Because if just the boss knows how it works three levels down, it will not be built correctly, right? Because it will just be filled. And the Orchestrator folks, that's the benefit, uh, of working with them. Or, you know, Adyen Stripe, like the PSP folks, they've built payments for a long time, so they have this understanding. But if you have general engineers, of course everybody can code well, but it's not just coding. It's designing the product. It's understanding the customer need and building for that. And this is the really hard part that always gets, um, let's say neglected in discussions because the CTO will always say, of course it's rational. It will always say, yeah, ah, give me a budget for 50 more people. Um, and I can build it. Because everybody wants 50 more people on their resume. Because, you know, everybody that's getting to that place in their career is kind of an empire builder, right? It's the mindset, right? Everybody wants more. So it's a very attractive idea to say, I'm building a team of 50 people to build my own orchestration in house. But getting the right people, that's hard.

Speaker B: That's a hard challenge. Um, if I understand it right, payrolls is a very young company.

Speaker A: Right.

Speaker B: Uh, when we sit together in 12 months again on Voice of MPE, around the MPE, uh, where do you see pay rates in 12 months?

Speaker A: Oh, I think.

Speaker B: Or what do you plan with pay rates in 12 months?

Speaker A: I think a lot of things are changing very fast these days, especially with,

Speaker B: uh, the AI Commerce AI.

Speaker A: So I think pay rails will be different in a few ways. One, we will have a lot more mature products so now these data products that I talked about in chargeback product, um, they're relatively young, uh, so in a year they will most likely be mature products at the same level of the others. Likely we will have a new product, um, at least um, in the portfolio because of course as Pay Rails, as I said, our mission is to solve all the challenges. Once you click the buy now button, um, there are more challenges to be solved than these five. Right. These fives are the first one that we're tackling. But there's a bigger opportunity here. So I think this is what will change. And I think also another thing that will change is more merchants, especially uh, with the push for profitability and uh, the world is getting more competitive, will likely get to outsource more.

Speaker B: Oh really?

Speaker A: I think so in terms of building, um, also

Speaker B: the developing.

Speaker A: Exactly. I think build versus buy will continue to go more towards buy because now with AI there's more opportunities to do stuff that's helping their core and payments and all the fintech services like Fintech, the tech part of fintech becomes more commodity and the fin part becomes hard. Um, I think merchants will realize that they don't want to play in the fin part. Where we have regulation everywhere you have pci, um, you just want to be able to innovate and keep up with all the startups that will start. Uh, because AI will basically mean that anybody, ah, with a cloud opus can build a competitor to you and you need to be able to build features and compete on all these kind of new kind of guerrilla work, especially the open cloth thing.

Speaker B: You read the articles of LinkedIn, of Mike Klotz, what he was building up with, uh, WhatsApp and.

Speaker A: Exactly, exactly. Because now you can more or less tell it, build me this feature and it builds it. And as an incumbent, because our ICPs are the big enterprises, they will need to kind of be agile enough to compete with all those. So they will definitely not say, okay, we're going to build internally more orchestration. So that's how I see this playing out.

Speaker B: Sounds very interesting. Um, I think within the time. Uh, thank you for joining Voice of Mpe with me. It uh, was a pleasure. Thank you for having me to sit together and have the conversation and I'm really looking forward what Pay Rails is going to.

Speaker A: Absolutely. Thanks for having me.

Speaker B: Thanks.