Theo Spyrides: James, thanks for staying to record a second episode. For this part, we're going to take a slightly different approach. You've obviously been at Worldpay, which is now being acquired by Global Payments, for over 10 years, and I'd love to explore a bit more of the product side of your role versus the payments ecosystem. So let's see where we go with this. My opening question, and I'll follow your lead: how do you build a PSP?

James Fry: Yeah. I mean, not that I've built a PSP. PSPs predate me and the investment there, but I think there’s a lot that goes into that because ultimately, when you say a PSP, that can mean many things to many people, right? A payment service provider in the past could just mean a gateway. In its rawest form, it was a gateway that connects a merchant to an acquirer. Because the messaging integrations into acquirers were complex, and hardware was involved, it was about simplifying the ability to integrate into the ecosystem. So that's what a PSP really was years ago. It was: "I need to take a payment. I have no idea how to do an API certification or understand ISO 8583 messaging. I need something nice and simple, from a simple HTML post to a hosted payment page if you're an SMB, through to an API integration." At its rawest form, it’s a case of saying: "I, as a merchant, have a consumer who needs to take a transaction from their card, and they need to get a message to their issuer. How do I get that message to the issuer?" Ultimately, that's what's formed the ecosystem. Payment service providers or gateways have probably grown mostly from incumbent acquirers who have tried to make it easier for merchants to integrate. And that's become the industry that we see today.

But there’s so much more that goes into a PSP now. Again, what payment methods do you want to accept? How do you reduce the number of times you, as a merchant, have to integrate to get access to cards, alternative payment methods, value-added services like authentication, fraud tools, routing logic? All of these things have started to come into it, where it's actually about how you create a sophisticated platform that allows a merchant to get the most value without having to build everything themselves. So when you’re building a PSP, it can be from the most basic level of: "I want to create that communication channel between a merchant who wants to sell their product and a downstream payment player." Ultimately, there is someone who has a funding instrument that is where the consumer wishes to pay from. But that has many, many facets to it. Typically, you'd expect a PSP to have connectivity either to its own proprietary technology, if it has its own fraud engine, or to multiple fraud engines. A merchant can come to me and say: "My fraud provider is X, my payment near my acquirer is Y. Can you connect me to those?" Really, what you're trying to do is reduce the technical burden and complexity on the merchant to navigate the ecosystem. And as we all know, the payments landscape is pretty large. There are lots of different assets to it, especially if you're a global organization. So it's really about helping build out that connectivity.

I would say underpinning all of that is having something scalable, reliable, and compliant. There are many changes every year that come from the schemes and other players. It could be: "Here's a new upgrade," or "Here's a new thing you need to do," and you then need to change your systems. Ideally, the PSP shields as much of that as possible from the merchant. It's: "I have to change this message, but I'll do it on your behalf. You don't need to worry about it." Ultimately, it minimizes the amount of time, money, and resources that a merchant has to spend navigating payments, rather than doing what they’re supposed to be doing, which is marketing their products, goods, or services to their customers.

TS: You raised a lot of great points there. I don't think people really appreciate the scheme relationships and the changes in mandates. Could you maybe give us a 101? How does that relationship work, and what is the effort you need to put in to maintain compliance?

JF: So a lot of the main network relationships or expectations sit with the acquirers because they're the ones that are part of the scheme networks. They're bought into it. An acquirer has done what a PSP has said earlier: a PSP simplifies the acquirer connection, but acquirers simplify communication with the schemes and networks. You have to be part of that network. You have to buy into it. And you can imagine, as I'm sure you know, merchants will feel this less, but they’ll still feel it on an annual basis. The number of changes that come down from networks can be significant. It could be pricing changes. It could be new fields and formats that need to happen. We're seeing a lot of movement towards using network payment tokens and saying that's the gold standard. Using full PANs anymore is not a good transaction. All of these things have to be taken into account. You can have hundreds of changes on an annual basis.

TS: Hundreds? Wow. That surprises me.

JF: We spend a huge amount of time in product and engineering on what we call KTLO, or “keep the lights on.” What are the things you have to do to continue doing what you do today? That could be internal things. Is my architecture compliant, secure, stable, and performant? Can I handle high-volume events? But also, am I compliant with the networks and APM providers? Again, we often talk about the card networks, but APM players change their specifications too. They have updates on a less regular basis, but they still happen. Just recently, an APM provider went from version one to version two, and it was fundamentally different. It was a full reintegration. Someone has to manage that. Ultimately, that's what PSPs try to do. They try to shield merchants from some of the volume of change that happens in this industry.

TS: And you talked about acquirers. So how do you pick your mix of acquirers to be able to process globally?

JF: Well, no one acquirer can process in every single country. It really depends. Especially if we talk about large enterprise customers, you typically see merchants have at least two acquirers in their core markets for reliability, backup, A/B testing, performance testing, that sort of stuff. But then you may also have a market where you can't access it through a global player and you need a local player. There are many different reasons behind it. Ultimately, what you need to look at is: what is the surface area of your business? What you're always trying to do is not have too many contracts, integrations, or relationships. So how can you get the right mix and make sure you’re working with an acquirer or PSP that can support you in the right way and help you through that journey? Every market is different. It has its own nuances. You have to understand how you navigate that.

TS: Maybe a stupid question, right? But I've been in payments for a while and even I don't think it's super clear to me. Would you define Worldpay as an acquirer? Does it have acquiring licenses in certain regions?

JF: Very good question. If you asked most of the market what Worldpay is, they would say an acquirer. That's a fair assumption. We are, and our biggest product is acquiring. We offer domestic processing in 45 markets with our own licenses. We also offer them in over 70 countries through partners. So Worldpay is an acquirer in its own right. We operate in many markets across the globe, which means we have entities, licenses, and operations on the ground where required. But Worldpay is actually a full-stack payment provider. We offer gateway services, many of which are microservices that you can take on their own or in conjunction with other products and services. We orchestrate payments. We orchestrate to payment providers, other acquirers, and partners of ours that open up geographies or regions for us. So there’s a whole host of things that happen within that. If you really look at Worldpay, it's about taking acceptance of payments, then optimizing your payments, whether that's fraud, authentication, or value-added services like payouts and FX. It's about turning a cost center into a profit center. All of these things combined are what Worldpay is. But yes, I would say most people in the market would consider Worldpay first as an acquirer, which is fair. There is a lot more offered as part of that. The biggest value is what you can offer through the value-added services and the data. We processed over two and a half trillion dollars as part of Worldpay alone last year. That's a huge volume of data. It shows scalability and resilience, but it also means we have data to make informed decisions about transactions and how to route them effectively.

TS: So it's almost like Worldpay is both an acquirer and a PSP. And because you have all these value-added services, what you're saying is you can swap out the acquirer, maybe because a merchant has a preference, or maybe because in some markets you need to go to a different third party.

JF: Absolutely. At the end of the day, we work with the largest customers in the world. As I said earlier, most large merchants won't have a single acquirer in a market. If we as a gateway can say: "You can come to us as an acquirer," and of course we'd love that to be across the space, but you also want to connect to another acquirer, either we have that connection and you can utilize it, or we'll look at a business case to add another acquirer as a connection behind us. We have to be flexible. There has to be a level of agnosticism, even when you come to a large incumbent player like us as an acquirer. We're not truly agnostic in that space, but we understand that you may want to take certain products and services as standalone. That could be something as simple as our vaulting service. It's basically credential forwarding. It means you can have a token vault that allows you to send traffic to Worldpay or to someone else. It is a product in itself. Or you may want to use our fraud tool. You may want to use us for fraud, but payments might come to us, or they might need to go somewhere else. Again, tokenization. There are lots of things that are agnostic to acquiring or even traditional gateway routing. It could be a standalone service you want to consume. There is always value in full-stack service because it means you've got all of the data points.

TS: I was actually going to ask you about that.

JF: You can then get to a point where you can probably inform and help even more than if you only see part of that transaction or part of the end-to-end journey. Of course, there are pros and cons to both. We're under no illusions that we expect a large merchant to come to us and say, "We're going to work with you and only you," and that's fine. We are open to being flexible around that because ultimately that's what our customers need, and we think it's the right thing to do.

TS: So modularity by design makes a lot of sense. How important is the developer experience to a PSP?

JF: Super, super important. We've done a lot in this space over the last couple of years, and I think there is more to do. There are certainly players who have always gone in as developer-first or developer-experience-first. Now, in the buying decision, CTOs and developers are part of the influential group that decides whether to work with someone or not. Being easy to understand, having documentation that's easy to consume, making it easy to get into a sandbox environment and test, and allowing people to do discovery is really key. It proves the products you have and the experience you would have actually utilizing the payment provision, whether that's gateway services or other services. It really is key. There’s lots more to do in that space. It’s not only the ability to understand and access documentation, but also how you demo your products and tools. Have you got things that can show the customer experience and developer experience? This is what it looks like in checkout. This is what happens in the background. These are the messages you would send. These are the SDKs you would use to create this experience.

TS: I’m so glad you raised sandbox. It really upsets me how little some people invest in that part of the developer experience. At Primer, we’ve built over 140 integrations in production. We’re pretty good at building integrations. The amount of times we build something in sandbox, start rolling it out in production, and then find out, “Oh yeah, of course the behaviour is different. It’s sandbox.” As a developer, I don’t know that. I have to build against a sandbox. I think it’s a great callout. It’s one of the underrated parts of building a great payments API: really thinking about how developers build into it.

JF: Absolutely. I think it comes from this idea that you want to build things, get them out there, and get them used. But ultimately, merchants want to go in, test it out, and understand what it really means. What does this mean operationally? What does this mean financially? What does this mean for my backend systems? What needs to update across the different parts of my systems? I’ve taken a transaction. I know the outcome. What are the next actions I can take? All of that is really key. Being able to create the ability to test and play with different configurations gives you the confidence to then go live.

Going in blindly isn’t the desired approach. The sandbox should be an exact mirror of production wherever possible. There are different ways of doing this. Sometimes you have a stubbed integration sandbox. Other times, if you want to see the full end-to-end financial process, it’s more about creating a pre-production environment and testing there. There are different levels, but it’s super important. No one would do something without wanting to test it out first.

TS: Okay. So as a seasoned product leader, I’m very interested. How do you think about slicing the org and building a scalable, effective product function at Worldpay?

JF: I think there are so many different ways you could do this. It depends on the size of the organization as well. Ultimately, you would want squads tied around propositions. When I say proposition, I mean solving a customer need. An example could be creating an end-to-end marketplace proposition that serves all the different things a marketplace might need: seller onboarding, KYC, split payments, payouts, and so on. When you take that as a proposition, it becomes an end-to-end customer experience. That’s the “what” and the “why.” What are we building? Why are we building it? What’s the business case? What are we trying to solve? This is really the explore stage of the product development lifecycle. What could we do here? What does good look like? At that stage, you shouldn’t be thinking about the reality of what you can or can’t do. It’s about defining what the ideal outcome would be.

Then you move into the “how.” How am I going to build this? What does my stack look like? How do I need to structure my teams to build effectively? I do think if you have people who live and breathe the “what” and the “why” through to the “how,” you get a much better delivery of something you know you actually wanted. You need people looking across the organization and asking: “I’m building something on the gateway. It’s going to connect to the acquiring platform or another downstream system. Does it actually work end-to-end?” If something I build here breaks something over there, then we haven’t created a complete experience. You need visibility and alignment across the whole journey.

In large organizations, including Worldpay, you also have platforms that require deep subject matter expertise. You have people who really understand how everything works. What you almost have is a virtual squad that sits across domains. Those domains might include things like money movement, settlement, and everything related to that. These people are experts in their space, working with banks and other partners. A handful of those people will then align to delivering a specific proposition, like a marketplace proposition. That’s one way of doing it. In a smaller organization, or one with a single stack, you might simply have squads aligned to specific value propositions. You might say: “You own this proposition. You live it, breathe it, and build everything needed to deliver it.” But that proposition mindset has to sit underneath everything we do. At Worldpay, I’m a segment lead. I’m responsible for the enterprise segment end-to-end. That means I have to engage across the product organization to make sure we’re building things that work for our customers and merchants, but that are also being built in the right way. That means working closely with those domain experts as well.

TS: So I’m fascinated by this. You lead the enterprise segment? What’s your surface area of collaboration with other teams? I imagine every team is a surface.

JF: Everyone. Before I joined product, I was informally running our geo-expansion program. It didn’t sit within product, but I had to work with every single product lead because we were building things across the organization. That included the front-end integration and gateway, the acquiring platform where we were adding new entities and BINs, setting up settlement processes, and ensuring data was fed into our portals correctly. You’re engaging across everyone. My team’s role is to understand the end-to-end proposition for our customers. That then feeds into our product peers who own specific areas of capability. We say: “Here’s the proposition we need to deliver. These are the requirements. How do we get there?” A lot of it is navigating the organization and, ultimately, persuading people. With any organization, you have 100 things you want to do and maybe 20 you can actually do. There’s ruthless prioritization. We have three lines of business: SMB, platform, and enterprise. We have to make sure we’re making the right choices for the business. There’s always going to be some friction. There are trade-offs and discussions around: “How do I get what I need done for my segment and my line of business?” But ultimately, the biggest thing is saying: “Here’s our priority list. These are the things we know we need to do. How do we get them resourced, delivered, and taken into the go-to-market model?” Because once something is built, we need to make sure the commercial teams know how to talk to customers about it.

TS: How frequent are you having these negotiations and planning cycles?

JF: Constantly. We run SAFe Agile within Worldpay, so we work in 10-week planning increments. Teams come together and say: “Here are our priorities. Here are the things we think we’re going to take into PI planning.” There are always trade-off conversations. We might say: “We have three things we need to do, but we only have capacity for two. Which one do we choose?” Then we have to manage those expectations internally and externally. Sometimes we’re building things merchants have specifically asked for, so those conversations happen all the time. We also have quarterly product reviews. I’m actually going to be in Orlando next week for the next one. It’s all of product and engineering together. We talk about product and engineering as a two-in-a-box model because we own outcomes together. It’s not just about the product side. It’s about how something is built and delivered. In those quarterly product reviews, we go across the segments and what we call domains, which are essentially our capabilities. We discuss what’s important, how we’re performing against business priorities, and how we’re tracking against our OKRs, our objectives and key results. Those might include revenue-focused goals, performance goals, team goals, and more. We surface the difficult conversations: where do we need to scale? Where do we need to add resources? Which areas need more support to get something delivered? It’s all about open communication. There will always be more demand than supply in any size organization because there’s so much going on in the payments industry

TS: And how much of that is bottom-up versus top-down?

JF: It’s definitely a mix. You have priorities that are, I would say, top-down in the sense that we know the strategic direction we want to move towards. But nothing happens without collaboration from the teams. At the end of the day, discretionary spend in an organization is only part of your overall capital allocation. You have the things you’d like to do, but you also have the things you have to do. That’s the KTLO work we talked about earlier: keeping platforms performant, reliable, and compliant. Then you have mandatory change. If network changes come in or an APM provider changes their specifications, you have to factor that work in because there might be a timeframe you need to deliver against. You also have regulatory and country-specific requirements. There could be new rules around data localization or other requirements that you have to build into your platforms. Then you have your discretionary pool, which is the additional work you want to do. Any squad or development team working on something has to balance their time across all of those areas. Some things are non-negotiable. Some things are negotiable, even if they’re things you really want to build. It’s always a balancing act to get the best possible outcome for the business and, ultimately, for our customers.

TS: I always describe it as an art versus a science. If prioritization was a formula, everyone would have the best possible products. But there is an art to it: how you bucket work, create the right mental models for discussion and debate, figure out your bets, and decide how to resource them. Everything you said matches my experience when we approach planning.

JF: Sometimes there’s complexity in larger organizations because you’re navigating a much bigger surface area of teams and people.

TS: How many PMs do you have?

JF: In my team, there are about 100 people at the moment. That’s across proposition leads and product managers. Obviously, the wider organization includes many more people outside of my immediate team. We have a size that’s appropriate for the scale of the organization, but it’s no small organization. Managing all of that is obviously a big challenge. But even in a smaller organization, you’re still going to have that long list, that laundry list, of things people want you to do. That’s the job of a product lead. You take all of that input, whether it’s merchant-led change, things a leader believes we need to do because they’ve looked ahead and identified an opportunity, or things that are mandatory. Then you work with your counterparts to get the best possible outcome. And that’s the art, as you said. It’s how you fit the things in as best you can to deliver the best outcomes.

TS: So if that wasn’t complicated enough, I know Worldpay has recently been acquired by Global Payments. I’d love to hear more around the why. What are the benefits? What do you see as the opportunities? But also the how. How do you bring two companies together, think about combining technologies, and think about combining cultures? I don’t think that story is told often. So I’d love to explore both sides: where you see the opportunities, and how you actually make it happen.

JF: I think there are some clear opportunities. Global Payments is extremely strong in SMB and particularly in card-present payments. My world, and the world of enterprise, is much more focused on enterprise customers, with a lot of that being card-not-present and e-commerce. There’s a lot of synergy and a lot of opportunity to bring the best of both companies together. The ability to leverage those capabilities to support merchants of any size is a clear reason why these two companies are coming together. What we’re focused on right now is continuing to deliver our business as usual. We have our strategy, and we need to deliver the things we’ve committed to. But we also need to address bringing the organizations together and making sure the teams are aligned. That means meeting counterparts and peers, getting the organizational structure in place, and understanding how we work together. Then there are opportunities where we can create immediate benefits for customers. That could be entering a new market, or bringing technology from Global Payments into Worldpay’s enterprise customer base. We’re looking at those opportunities. Ultimately, both companies have very similar cultures and values, so it’s actually been a very positive combination of the two businesses. The big focus is: how do we deliver more value for customers? That’s what we’re driving towards. Both companies already had a shared goal of making it easier to do business with us, whether that’s making integrations easier or improving the operational and financial experience. There are a lot of synergies there. It’s really about the power of the combination: bringing together the best parts of both organizations to support our customers.

TS: And are you going to bridge the tech stacks? How does that work in a big merger like this? Or do you keep them completely separate?

JF: I think the reality is there will be conversations around the technologies we can use across all the lines of business. We think about our lines of business as SMB, platform, which is more around embedded payments, and enterprise. Of course, you have two companies coming together. Over time, there will be opportunities to leverage technology from both sides. The key thing is making sure we keep things simple for our merchants. So those discussions will happen as we move forward. It’s still early days, but certainly it’s something we’ll look at in the future.

TS: And as a product leader owning that segment, do you now have a responsibility to go and figure out: “Wow, Global Payments can do all these things. I can take these capabilities and bring them to my merchants?” Is that something every leader is responsible for, or is there someone specifically owning how to get the best of both worlds?

JF: It’s a mixture. A number of people are involved. But yes, that’s the exciting thing. We’re discovering really great capabilities and thinking: “Wow, it would be amazing if we could take this capability and combine it with what we already have to better serve enterprise customers.” A big part of what we’re doing right now is meeting our new colleagues, understanding what they’re responsible for, and identifying where there are opportunities. You start seeing things where you think: “This would be amazing to bring into this customer base or this segment.” That’s the value of bringing two companies together. It’s about the power of the combined capabilities. We have a lot of opportunities to deliver more value to customers, whether that’s a Worldpay product or capability that we bring into the Global Payments stack, or the other way around. That’s the fun part.

TS: Awesome. And I guess you now need to upskill and learn a whole new product suite.

JF: The payments industry is, as we all know, very complicated. I always say to everyone: I learn something new every day, and I’ll continue to learn at least one new thing every day. So yes, there’s a lot to learn. But ultimately, they’re solving customer problems and customer needs. When we talk about propositions and my role being focused on end-to-end propositions, it’s not like learning a completely new language or something I’ve never understood before. It’s a capability where we can say: “That would be great. We don’t have something quite like that today. How do we bring it in?” It’s a learning experience, but it’s all focused on the same thing both companies care about: serving customers of all sizes, regardless of channel.

TS: And if someone’s listening and they’re building payment technology, what would be the one piece of advice you’d give from a product perspective? Where should they be really deliberate and make sure they make the right decisions?

JF: I think if you’re trying to build something to solve a problem, that’s generally why you’re building a product: to solve a merchant problem or need. That’s only going to be successful if you have customers helping you through that process. You need to engage with your customer base, understand what they find difficult or challenging, and bring that into your product design. When we talk about the exploration stage of product delivery, it comes back to the “what” and the “why.” What are we building? Why are we building it? There needs to be a clear problem statement that you’re trying to solve. Then you need those friendly merchants throughout the process. Ask for feedback. Keep that feedback loop going through the build and design phases. Show them what you’re thinking: “This is what we’re considering. Does this resonate with you? Is this right? Are we missing anything?” There’s no monopoly on good ideas. Ultimately, you need to engage with the end users of the product you’re building and ask: “Is this actually what you want?” If you get that part right, the rest starts to fall into place.

TS: So make sure you work super closely with your persona. Build with them, ship with them, iterate fast, then go to general availability. That’s kind of your playbook?

JF: Exactly. And also, don’t try to solve everything at once. As you said, have a persona. Sometimes you’ll have a product that could apply across multiple industries or merchant sizes, but generally there is a first use case or first need you’re solving for. Trying to solve everything at once can turn into a never-ending project that’s difficult to get off the ground. You need to make sure you’re solving the right thing first. Then, once you get a product into pilot and general availability, that’s not the end of the story. I always used to break it down into explore and define, then build the product, then move into go-to-market. It’s in Salesforce, the commercial teams understand what’s happening, and the product is out there working. But then you have this forever iterative process. You need to improve the product. You need to enhance the product. Something new happens, and you need to react. You need to have ownership of what you build in perpetuity.

TS: And maybe last question on this: how often do you want your team talking to merchants?

JF: As much as possible. I always think it’s not as much as we would like, but whenever possible. That could be through business reviews with the commercial team, or through events we run regularly where we have customers there. Having product people in front of customers, talking to them directly, understanding their pain points, and learning what they need and want is incredibly valuable. Whenever we can get the product organization in front of clients, it’s great because you’re hearing directly from the consumers of our products what their experience is. And invariably, they’ve used the product day in, day out. They have a really insightful understanding of it that you can learn from. So the more, the better.

TS: Nice. There’s nothing better than actually sitting next to someone and seeing them use the product. It’s one of my favourite sessions that we get to have.

JF: Seeing something work and then being happy with something is the best part of the job, I guess.

TS: Yeah, exactly. Well, that’s a good place to end. James, thanks so much for your time. It’s been great speaking.

JF: No worries. Thank you very much.