Ep. 93: Do You Need a Payment Orchestration Platform? Eyal Nevo of Orchestra Solutions Explains Why One PSP Is No Longer Enough

Welcome to The Payments Shed Podcast, the weekly podcast that dives into the big topics, trends and people shaping the worlds of payments, fintech and business leadership, with your two co-hosts, Grant Evans and Justin Hanna.

Host:

Welcome to another episode of The Payments Shed Podcast. Today, we're joined by Eyal Nevo, creator of Orchestra Solutions and CEO of PCI Booking.

Eyal, welcome to the show.

Eyal Nevo:

Hi guys. Thank you.

Host:

Can you tell us a little bit about yourself and your career in financial services and payments to date?

Eyal Nevo:

Sure. My origin is not in payments. We started off offering online faxing.

From there, we were introduced to the lovely world of PCI compliance and credit card security, and we realised there was a lot of pain in that industry.

Once we were in the PCI compliance business, we realised the natural progression of using cards was to process them through a payment gateway.

We realised that integrating with payment gateways is a lot of hassle and a lot of headache, so we created what we aptly named a universal payment gateway to provide all these connections.

That led us into the world of payments and into payment orchestration.

Host:

At what point did you realise you'd effectively already built most of the components for orchestration before the industry labelled it orchestration?

Eyal Nevo:

During COVID, we were trying to figure out how we could restructure the business to be more sustainable for the next worldwide catastrophe that happens.

We spoke to a few providers and were introduced to a few orchestration providers. Then we realised, wait, everything you're offering, we already have. We've just named it differently.

We realised we could repackage the offering, put a proper name on it, payment orchestration services, and we had a new product.

Host:

What was the biggest challenge in making that decision and saying, yes, we can do this ourselves?

Eyal Nevo:

It's always a risky move to start something when you're not really sure what you're doing.

Fortunately for us, at that time we already had a good customer base and customers using our payment gateway connections.

It was a very natural progression for us to switch it, and it was essentially a marketing exercise rather than a development exercise.

There was some development. Obviously we had to carve out some components and restructure them into a separate product, but it was primarily a marketing exercise. As such, there was less cost and risk involved.

Host:

You guys have stayed pretty lean as a business in terms of headcount, probably leaning more into the technology side of things.

Was that a really deliberate decision? It's interesting that we're seeing businesses scaling back staff in the payment stack at the moment and utilising more AI. It seems like you guys were ahead of the curve with that.

Eyal Nevo:

Throughout our DNA as companies, we were always a lean organisation, always having people doing multiple things and trying to make things as efficient as possible.

Here as well, we rely on cloud services. We outsource wherever possible, wherever it's efficient. Obviously, we keep it in-house when that's more efficient.

All of our team is highly dedicated and experienced in what they're doing, whether it's development, operations, accounting or sales.

That's how we can keep it very lean and efficient.

Now with the invention of AI, every person in the company becomes five people, so there's even less need to grow to 50 or 60 people.

Host:

Have you put much emphasis on your staff becoming experts with AI tech stacks? Is that something you've looked at, where you want people playing around with AI tools and having them as part of their day-to-day?

Eyal Nevo:

Absolutely.

We look at it on a couple of fronts.

First, in terms of the staff, it makes them more efficient. Any person who can use AI better and do more things at the same time is more efficient for the company. We can do more with less.

There are automation capabilities. We can now reach tasks that were put on the back burner and delayed because we never had the resources or enough priority to do them. Suddenly they can be achieved very easily.

Finally, we're looking at the growth of the staff.

Obviously AI is here to stay, and whatever our staff do next, they'll need AI in their next role.

The more they learn within the company, the more it will help them in their next business.

Host:

Someone was talking to me about AI last week and said the biggest problem we have with AI is that it tries to be helpful before being honest.

What we actually need is for it to be honest and then helpful.

There's a lot of time when you put things into AI and it tells you some kind of biased opinion based on what you've been feeding it in the past.

I thought that was a really good way of looking at it.

Eyal Nevo:

Well, I have a preliminary step.

It fluffs you up first. It says, "Oh, that's an excellent idea."

I don't need you to say it's an excellent idea. I need you to answer the question.

Host:

When we talk about payments, there are a lot of businesses talking about payment infrastructure and trying to deal with fragmentation in payments.

A lot of people claim to be fixing it.

How does that typically happen from your perspective? Does it happen overnight or evolve over time?

Eyal Nevo:

It's definitely an evolving process.

Our approach to companies that come to us and want to consider payment orchestration services is to say, let's not break what's already working.

Whatever you've got, let's keep it as it is.

Start with your next integration with Orchestra.

You need to do another integration anyway to support whatever the next payment need is. You might as well do it with Orchestra because once you've done it with Orchestra, the next one after that is already done because you don't need to worry about it.

We say: keep what you have, use us for the next one, get confidence in our services, then switch back and address what you've already got.

Host:

Is there a continual underestimation of the process of integrating a PSP?

People assume adding multiple PSPs is going to be straightforward, and that's really not the case.

Eyal Nevo:

Yes, absolutely.

People get blinded by the simplicity of Stripe and Adyen. They don't realise that once you leave Stripe and Adyen, it becomes considerably more complicated.

Once you get into more niche markets and niche payment methods, it balloons from there.

I see this all the time. Companies have development teams strictly working on payments, where you have five, 10, 15 or 20 people just on payments, while the company itself does something completely different that's unrelated to that.

Host:

I see this at the moment where there are legacy PSP integrations businesses are maintaining because that PSP gave them something a bit quirky that hasn't since been changed.

Whether it's a good thing or not, it's something they're familiar with as a business, or it makes their life easier.

A new PSP might say, we're not going to build it that way because it doesn't make sense.

But these businesses are now stuck with those PSPs because they don't want to lose the freedom they had with a legacy product sitting in the stack.

Is that something you encounter a lot?

Eyal Nevo:

Yes, absolutely.

It comes up often where you have legacy systems using some communication technology that has disappeared from the world, and you can only support it through there because nobody else supports it.

We've actually helped a company do exactly that.

They were getting the material in some weird format, and we had to create a conversion from that format into a standard JSON API to make everything work.

It's very common.

That's exactly what I was saying earlier. We try to say to people: don't break what's already working.

It's working. You're happy with it. Leave it and address the next one.

Host:

It's very difficult in payments to compare apples with apples.

Eyal Nevo:

Yes.

Host:

We talk about it from a commercial perspective when we're talking about acceptance rates or what the statement looks like.

Is this fee similar to that fee? Is this acceptance rate measured in the same way one provider would measure acceptance compared with another?

You're trying to optimise that and decline reasons, but how you integrate is just the same.

A lot of businesses have this expectation of Stripe or Adyen where you integrate overnight and it's a quick development project.

Actually, unpicking some of that is really difficult, which is why businesses stay with a legacy provider. They get something they've not been able to mirror through new integrations.

Eyal Nevo:

Absolutely.

PSPs rely on the fact that integrating one of their competitors is so complicated that even if you get an offer that's five basis points cheaper, it's still not worth the hassle.

That's their entire lock-in mechanism.

You see this all the time.

Host:

There's an argument that legacy PSP maintenance is technical debt within organisations.

Have you had feedback around the time saved by stripping out engineering teams managing legacy payment integrations that can instead be outsourced to a platform like yours?

Instead of maintaining all these PSPs yourselves, you'll keep those connections up to date.

Have you got stats around how much easier you've made things for customers?

Eyal Nevo:

It's very difficult to measure because it varies by company.

What we usually do is understand what the company currently has in terms of development resources for payments.

We say, if you use us, basically all of that resource becomes available and you can now use it for other things.

What would you do if you suddenly had five extra developers sitting around who could handle your backlog?

What new features and capabilities could you add that would promote your service?

That's our approach.

Host:

As we talk about legacy PSPs and modern technology companies, why is a single PSP no longer a viable model for platforms and merchants?

Eyal Nevo:

We'll start with the simple one for merchants.

It very much depends on your business.

If you're happy to just work in the UK, all your customers are in the UK and you get a processor with good rates, stick with it. That's fine.

But a lot of companies these days have customers everywhere.

Online commerce is exploding everywhere.

Do you really want to process charges in the US from a UK-based PSP?

Do you want to charge someone in Australia that way?

Most products these days are online anyway. You have customers online from anywhere.

Using one PSP is adding money and ridiculous amounts of cost.

That's before we even go into supporting the way your customers want to pay.

How customers want to pay in Australia is not the same as how they want to pay in the UK. It's not the same as the US, India, Brazil or anywhere else.

Even a PSP as big and comprehensive as Stripe can't handle everything.

You will run out of Stripe's capabilities at some point. It might take a while, but you will.

Having one PSP for a merchant can therefore be very limiting.

If we move into platforms, that limitation happens much quicker.

As a platform, you have businesses that are your customers. Those businesses are most likely already operating with a PSP of their choice.

If you're only working with one PSP as the platform provider, you could potentially be losing business opportunities because you can't support what they want, and they might not be able to move to the PSP that you have.

I know many merchants that were kicked off the Stripe system for whatever reason and can't come back.

If you're just using Stripe, you've lost a whole chunk of potential customers.

For platforms to only support one PSP is business suicide in my mind.

Host:

That's like the vendor lock-in trap you've spoken about previously.

You have platforms bundling payments, then it gets increasingly painful to leave.

Why is that becoming such a big problem at the moment?

Eyal Nevo:

Again, everybody is online.

It's not 20 years ago when e-commerce was so new that everybody was starting up.

Now everybody has business relationships.

Everybody says, "I have this great deal with this processor or that processor."

You come to a platform and want to keep using what you already have for whatever reason, or you might not be able to use the one that they have.

Or, as a platform, you've completed the market you're in and now you want to expand.

Again, you need to support the payment methods, payment services, currencies, geographic restrictions and regulatory requirements of a new geography.

One processor is just not enough.

Host:

One thing I've never seen is a merchant starting to use an orchestration platform and then reverting to one provider.

I've never heard a customer say, "We're working with an orchestration platform, but actually we don't want to anymore."

Eyal Nevo:

No, I've never heard that.

The only thing I've seen is someone switching from one orchestration provider to the next.

In my view, and this is how we've done it as a business as well, once you start expanding, you're not going to stop.

Once you've expanded into one market, chances are you're going to continue into another one, then another one and another one.

Payment orchestration just makes plain sense from that point.

Host:

How do you maintain and scale your own relationships with PSPs?

It's always an interesting topic. We've had a few orchestration platforms on the show and know a lot through our connections in the industry.

We don't probably talk enough about the fact that you actually have to have a relationship with the PSPs sitting on your panel.

There was certainly a fear factor when orchestration first arrived in the market that you were going to point their traffic somewhere else.

We've got to a point now where it feels like you've got to be on board with orchestration as a PSP, or you could get no traffic at all.

Eyal Nevo:

Absolutely.

First of all, most PSPs these days have realised where the wind is blowing.

They're actively reaching out to us and saying, "How can we be on your system? What can we do? Do you want revenue? What can we do to be on your system so you can promote us and provide us to customers?"

However, I have had experiences with PSPs who say, "No, we don't work with payment orchestrators."

Even after I've shown them that they're losing business and that I'm holding business waiting for them to be onboarded, so they don't have to do anything, I'll just do the integration and they get the customers, they still don't want it.

Some people just live in the past.

If you live in the past, you'll probably go out of business soon.

Host:

Especially some acquirers that have only allowed their own gateway to integrate into their acquiring platform.

We talk about Stripe, Adyen or Checkout.com.

Until more recently, they wouldn't allow anyone else to integrate into their platform anyway.

I think they've realised that some merchants still want relationships with more than one provider.

It's that old saying: you'd rather have 30% of something than 100% of nothing.

Eyal Nevo:

Exactly.

Host:

I think it's keeping agnostic PSPs relevant in the market.

Their whole narrative was, "We give you acquirer choice."

But if the big acquirers with the best technology stacks are now saying, "We give you PSP choice because everyone's connected to our acquiring rails," that's a big transition point in the market as well.

Eyal Nevo:

In my view, if you have a good service, customers will want to use you.

If you have a bad service, it doesn't matter what you block. People won't use you.

Even Visa and Mastercard have realised in the past few years that it's not enough for them just to talk to acquirers and PSPs.

They need to go down another level and talk to payment orchestrators as well.

Host:

How does Orchestra standardise the payment experience across multiple providers?

Eyal Nevo:

We've basically designed a bridge on top of all the payment connections.

We have a library of payment connections to all the different PSPs, and it all funnels into one standardised API that we've created in our system.

From the customer's perspective, or the integrator's perspective, there's one integration process, one UI and one backend API.

That's it.

We take care of everything else in the background.

You tell us what card you want to charge and where you want it to be charged, and that's it.

Host:

You've built a unified experience for things like 3DS, tokenisation, DCC, APMs and local payment methods regardless of the underlying PSP.

Why is consistency so important across those different stacks?

I also wanted to ask about tokenisation across PSPs, because that's the next blocker we've got.

If network tokenisation exists, that's great from an acquirer point of view, but I want that across all my different PSPs in a region as well.

That seems to be the hurdle we need to overcome next.

Eyal Nevo:

Exactly.

All of these services aren't universal, and that's where we really shine.

You have a PSP that supports 3D Secure and one that doesn't. You have one that supports Apple Pay and one that doesn't, and so on.

It's the same with network tokenisation.

We've designed our system to be completely agnostic and sit at a level above the PSP.

All of these services happen in our system and then we send a card to the PSP.

Whether that PSP actually supports 3D Secure or anything else, we simplify things and pass them whatever they can actually process.

Host:

Should merchants or platforms even need to know which PSP is processing their transaction anymore?

Eyal Nevo:

The way we operate is slightly different because this goes into smart routing.

We've designed our system specifically so that we don't do smart routing on behalf of the customer.

We want to give the merchant or platform the capability to decide on their own.

Our logic is very simple: we're not you. We're not the customer.

You know what your business is. These are your relationships. These are your agreements. These are your costs. This is your risk.

You tell us what you want to do. We're not deciding for you.

So, to answer your question, yes, our merchants do need to know what's covered.

However, we try to make it as agnostic as possible.

For example, Apple Pay is very common but isn't supported across the board.

Host:

Just that statement gets me. How is it not supported across the board in 2026?

Eyal Nevo:

It's ridiculous, but it's not.

We've designed a process where we can extract the underlying card that Apple Pay is sending and pass the card to the processor.

It doesn't matter if the processor supports Apple Pay or not because we're just sending a card.

In that sense, it doesn't really matter to the merchant what the capabilities of the processor are.

It's the same with 3D Secure.

We process 3D Secure irrespective of whether the processor is an American processor that doesn't even know what 3D Secure means.

Host:

A subject we always tend to get onto is AI in payments.

You said AI and payments falls into four separate conversations, not one.

Can you elaborate on that?

Eyal Nevo:

We need to look at a few things.

First, the most common one is decision-making.

Again, we stay out of that.

We provide all the details and inputs for your system to make an informed decision about how to process it.

Should you use AI? Absolutely.

It's a tonne of data. You're passing a lot of transactions. You should use AI.

But we provide the inputs. You have the mechanism.

Then there's AI that we use for development.

As I mentioned earlier, we use AI to improve our team, make them more efficient and produce more.

Recently, all of our integrations are first handled by AI.

It creates the integrations against a very standardised interface we've created in our APIs, then the developer reviews it and checks that everything is working properly.

There's obviously AI in all the other operations as well.

But we've deliberately stayed out of the decision-making process, whether it's manual or AI-based.

Host:

I was told last week that you should be using AI in engineering as effectively a junior to mid-level engineer that can do the first or second draft of some coding, then it goes on to manual review.

Eyal Nevo:

Absolutely.

That's also a big problem because soon we won't have any junior developers to grow up to be senior developers.

Host:

That's a problem for five years from now, right?

Eyal Nevo:

Exactly.

Host:

At the same time, you're using AI internally.

You mentioned preparing for AI-assisted integrations and agentic commerce.

How quickly do you see the shift happening from where we were 18 months ago to where we are now, compared with where we'll be in another 18 months?

Eyal Nevo:

AI is moving so fast.

What was yesterday is now today, and what's today is tomorrow.

I see it from my own use and from my team's use.

We're constantly finding new capabilities where we can use AI internally.

What will it be 18 months from now? I have no idea.

AI is becoming very strong in development, and we've designed our system to facilitate that development.

Our code samples and documentation are all geared towards AI-based development.

We've had people on our team with no development skills whatsoever build an app that handles payments using the documentation, just to see whether they could do it with AI.

They were successful multiple times.

That's happening very quickly.

It's not even 18 months from now. It's happening today and will continue happening.

After that is agentic commerce.

I think that's still a big problem.

I don't think it's fully thought through yet.

Everybody's talking about it. Everybody's making noise about it, and we're definitely geared for it.

But there are a lot of issues people haven't considered.

To me, the main one is consumer adoption.

As a consumer who uses AI many times throughout the day, I'm still not ready to give it my credit card.

Host:

I think there's a massive hype-train problem with agentic commerce at the moment.

It's definitely that shiny marketing tool everybody's talking about.

Eyal Nevo:

Yes.

It's the hype at every conference.

Everywhere you go, there's at least one session about agentic AI, and it's all theoretical right now.

Host:

I think AI-assisted integrations are more interesting.

Maybe web developers need to be some of the most concerned people right now.

I can go and vibe-code a new website for myself.

If there are modular payment integrations, I can say to my AI, "Here's the country I want to go into, here's this integration tool, drop it in and build the checkout for me."

Do you need a merchant account? Fine, pre-populate the application form with the acquirer. You get your merchant ID the same day with a lot of acquirers now.

Eyal Nevo:

Web developers are probably a dying breed in general.

You have services out there like Replit, Vercel and many others that use AI in their web development.

You go in and say, "I need a web application that does this and this," and it builds it, hosts it, manages it and runs a database for you.

It's all right there, and you don't need anyone.

You can easily say, "Add payment orchestration capability. Here's the documentation," and let it run with it.

Host:

One of the big agentic commerce frameworks seems to agree that AI agents shouldn't touch raw card data.

We've talked about tokenisation today, but why do you think tokenisation becomes even more important if, even in five years' time, more people are using agentic agents to do their shopping?

To your point about giving it your card details, if you've got tokenised card details, perhaps there's a happy halfway house.

Eyal Nevo:

That's one of the problems with agentic commerce: the security of the credit cards.

Tokenisation is absolutely a must, and all the protocols around agentic commerce talk about tokenisation in one shape or another.

Most of them lean towards network tokenisation, which, as we mentioned, has its own problems.

We've created mechanisms that can facilitate either our own tokens or network tokens.

Whichever the AI agent prefers to use is fine with us.

That's one problem, how to secure and store the card.

The other problem from a consumer side is that I need to be able to trust the AI.

Not only that you're securing my card, but that you're not going to waste my money.

You're not going to run off and buy something completely different from what I asked for, or have a bidding war with yourself and raise the price because I gave you a limit.

It could go all the way up to the limit even though the item was only half the price.

Tokenisation has nothing to do with that.

That's the AI itself being silly.

Host:

There's stuff definitely going on in the background.

I did a post on LinkedIn a few weeks ago.

I used Apple Pay to buy something for one of those sparkling water machines. It was a company in Europe.

I didn't have an account with them. I think you buy two canisters for £60, then they ask whether you want to be green and return your canisters.

They send you the Yodel link.

I went away over a bank holiday weekend, came back and got a £50 charge taken from my card.

I thought it must have gone into a recurring subscription by mistake.

It wasn't that.

They had a five-day or seven-day window on their Yodel agreement for returning the canisters.

But I didn't tokenise my card. I didn't register at all.

They had saved and tokenised my card off the back of my initial Apple Pay transaction and charged me £50.

Long story short, I sent quite a strongly worded email.

They refunded the money, but the initial email back was, "These are our terms and conditions."

There's no way they paid Yodel £50 for that return.

They're monetising an opportunity, but they're also capturing people's card details from an initial digital wallet payment, which I think is very questionable.

Eyal Nevo:

Again, then it falls into the terms and conditions.

It might be hidden in paragraph nine of section 25 that nobody reads: "We store your card."

Host:

It's an interesting one because I would in no way trust AI to order anything for me right now.

Even if I order the same thing from Amazon every single month, I wouldn't do it on a recurring basis.

I think it also depends on how people manage their funds.

Maybe I'm not in a position where I can let anyone run around with my card yet.

There's definitely an opportunity there somewhere, but I think a lot more needs to happen from a compliance perspective to allow consumers to be comfortable with it.

Something completely nonsensical I keep seeing at conferences talking about agentic commerce is the example: "I want to order a blue T-shirt with a red ball on the front."

It's the same example every time.

Who's buying this T-shirt with a ball on the front?

Eyal Nevo:

We use an example of buying trainers.

All our sample pages are shoe stores.

Host:

That's a better one.

Let's look ahead over the next few years.

How do you see payment orchestration evolving over the next one to five years?

Orchestration isn't new now. It's been around for a few years.

Eyal Nevo:

Orchestration is sufficiently generic that I don't think it will require a revolution.

I think orchestrators that don't do a good enough job as orchestrators will die out, as they should.

Orchestrators will provide proper orchestration and put all these payment capabilities together for the benefit of the consumer.

As payment capabilities expand, orchestrators will have to expand their coverage to support all these services.

But that doesn't fundamentally change the services they offer.

Host:

How do you best distinguish yourselves against the competition then?

If you're saying orchestration should do what it says on the tin, there are still a lot of players in the market.

Eyal Nevo:

That's one of the differentiators.

I can't tell you how many times a potential customer has told me, "I have an orchestrator and it took them six months to complete an integration."

Why?

No matter how bad the integration is, it shouldn't take an orchestrator six months to complete it.

It might take you six months to complete it, but not an orchestrator with experience.

Host:

At what point do you think we'll see acquisitions of orchestration platforms by larger PSPs?

Eyal Nevo:

That's a little tricky because, as we alluded to earlier, orchestrators almost compete with PSPs.

Host:

Absolutely.

Eyal Nevo:

It's not very usual that a PSP would want to buy an orchestrator because why would they transfer any traffic to someone else?

There's no logic.

Host:

It would lose trust in the product as well if an acquirer owns an orchestrator.

But people are in businesses for different reasons.

Some businesses have been created because the founders ultimately want to sell.

Eyal Nevo:

There is that.

But I think it will be more within the industry.

One payment orchestrator might envelop another if the founders want an exit, rather than a PSP buying it.

What is happening now is PSPs themselves saying, "Oh yes, we're an orchestrator."

And I'm like, "Oh, are you really?"

Host:

What about a big bank buying one?

A lot of banks have stepped away from having direct acquiring solutions, but their customers all need payment services.

I like the idea of one of the large banks buying an orchestration platform to be the segue for its customer base.

You could say, "These are my payment needs," and then an orchestrator says, "You have all these countries, you need to plug into these layers and we'll help you this way."

That would be an interesting acquisition.

Eyal Nevo:

It's funny you mention banks because we've just partnered with a neobank.

One of their stances is: "We don't care about payments. The margins are too small. It's not worth the hassle."

According to what they've told us, what banks are interested in is loans and credit lines.

That's where the money is.

We've partnered with them to facilitate on-the-fly tokenisation into their token vault so they can then offer credit lines based on future payments.

But the underlying service they're offering is the line of credit.

All of this is just a means to secure the line of credit.

Host:

Rewind 25 years and that's exactly what it was.

Eyal Nevo:

Yes.

Host:

It was mostly banks offering payments as a by-product of their issuing and lending book, and you got the acquiring for next to nothing.

Then the big crash happened and these larger acquiring banks said, "Let's get rid of our payment processing."

Twenty years later they're going to try and buy gateways themselves and suddenly think, "We're missing out on merchants that went to fintechs, which are now starting to offer lending solutions."

Eyal Nevo:

Absolutely.

Host:

Embedded payments is becoming a much bigger part of the merchant infrastructure layer as well.

You look at SaaS platforms taking embedded payments and making that one of their core products within their vertical SaaS stack.

Do you feel those companies need to be looking at orchestration because they're probably going to end up having more than one acquiring relationship as they scale?

Eyal Nevo:

Absolutely.

As soon as you start dealing in payments, especially if you're a platform, you shouldn't be doing it yourself.

There's no point.

You don't have the resources. You don't have the experience.

You'll be spending all your effort on something completely outside your wheelhouse, and you should just outsource it.

Host:

What do you think businesses are still misunderstanding around cross-border payments and global expansion?

Eyal Nevo:

The main problem is people don't understand what payment orchestration can offer them.

They look at things as, "This is what we've been doing for the last 30 years. We need payments, so we'll integrate Stripe. We'll integrate Adyen. We'll integrate Apple Pay."

It comes in phases.

It doesn't come as one massive project where you say, "This is too much for our team. We need to outsource."

You get little chunks over time.

"Fine, I'll deal with this. Fine, I'll deal with this. Fine, I'll deal with this."

Sooner or later, you find yourself with half a dozen different payment components and a team managing all these payment components.

Suddenly you're drowning in payment integrations, and payments aren't your product.

Host:

I think we can get better as an industry at explaining not just the local payment methods needed when moving into new markets, but also the infrastructure.

There are businesses giving you the ability to create a legal entity or use their legal entity for distribution.

Merchant of record businesses now say you can move into Australia where they have the legal entity and get better domestic acquiring rates, but they have to take control of the stock or product as a halfway house.

We could be better as an industry at explaining accessibility into those new markets, not just from a payment method point of view, but from an infrastructure point of view as well.

Eyal Nevo:

Yes.

Those types of services matter because that's a big barrier for, say, a small company in the UK with an online presence trying to expand into Australia.

It's a big barrier.

You need a legal presence. You need to set up a merchant account.

All of this stuff isn't possible for a small company.

There are services out there providing these external capabilities, but they're so hidden that you wouldn't even know to look for them, let alone find them.

Host:

Before we wrap up, our final part of the show is the Shelf of Shame.

What do you bring that really frustrates you from a PSP and payments perspective?

Eyal Nevo:

When a PSP makes it difficult for a customer to leave.

It's 2026.

You should be offering a good product and trusting your product enough that people stay because they want to stay, not because you're forcing them to stay.

If you have a good product, people will want to stay.

If you have a bad product, people should leave.

Host:

It's a really good point.

We've all seen it where a merchant is going to move and their existing provider says, "If you want these tokens, it's going to cost you X amount."

Or they say it's just not possible.

Then it's, "Okay, but all my business is on those recurring tokens."

I had a "not possible" one with Barclaycard a few years ago.

The customer was basically trapped.

They wanted to leave, but they couldn't risk the challenge of those subscriptions failing.

Even if 10% failed, it would be a problem.

Eyal Nevo:

Yes.

You can't just reach out to all your customers and say, "We need you to give us your card again."

That's very bad.

Host:

They were a very lean, traditional business.

It was stressing them out because they'd had enough of the current provider and really wanted to leave.

Commercially it made sense for them, but more importantly they wanted Apple Pay and wanted to modernise their payment stack.

They had to make a really emotive decision in the end about what would be more painful.

Do we stay, or do we try to get 10,000 subscriptions set back up because we can't bring those tokens with us?

They were completely trapped.

They're probably still there to this day.

That was the first time I'd seen a merchant genuinely pained by being stuck and completely attached to their incumbent provider.

It shouldn't be happening.

Eyal Nevo:

I agree with that.

Host:

Definitely going on the Shelf of Shame.

Where can people get in touch with you and find out a little more about Orchestra?

Eyal Nevo:

The best place is our website, orchestrasolutions.com.

In fact, the entire system is self-service.

You can register, start the service, see all the documentation and, as I said, develop yourself or with AI and get started.

We even have a free tier, so you can go live without paying a cent.

Once you're ready and your volume is up, then you need to contact us to start paying for it.

That's it.

Host:

That's very unique. We don't see that very often.

That's SaaS solutions at their best, isn't it?

Eyal Nevo:

Absolutely.

Host:

Amazing. Thank you so much for your time today. We really enjoyed the chat.

Eyal Nevo:

Thank you, guys.

Host:

Speak soon.