Single Global PSP vs Multiple Local Acquirers: How to Decide

Quick answer: one global PSP is simpler to run and usually right until international volume becomes material in a specific market. Multiple local acquirers can improve the economics and the customer experience in each market, but the cost lands on your team rather than your rate card: more contracts, more reconciliation, more routing logic to maintain, and more places for something to break. The decision is not really about acquiring. It is about who absorbs the operational complexity of running more than one provider. If you want the market coverage without your engineers owning a separate integration per provider, that is a third option, and this guide covers it last.

This guide covers what each model looks like day to day, the four tradeoffs the decision always comes down to, how to test an acquirer's performance claims before you sign, and how to sequence a move if you decide to make one.

If you want the underlying mechanism first, why a domestic transaction is treated differently to a cross-border one, read what local acquiring is and how it works. This guide assumes you already understand that and picks up at the decision.

The two models, in operational terms

The brochure version of this decision is about fees. The real version is about what your team does every week.

Single global PSP. You hold one contract, one integration, one dashboard, one settlement file and one support relationship. Your provider handles cross-border processing to whatever markets you sell into. Some global PSPs hold local acquiring licences in a set of countries and can route domestically inside their own network, which gives you part of the local benefit without you contracting separately. Your engineering surface stays at one API. Your finance team reconciles one source.

Multiple local acquirers. You hold a contract per market, or per region. Each one has its own onboarding, its own underwriting, its own API and its own settlement cycle. You decide which transaction goes where, which means you own routing logic. You reconcile several settlement files into one view of revenue. When a provider changes an API or a scheme changes a rule, you absorb that per provider rather than once.

Nobody chooses the second model because they enjoy it. They choose it because the first one stopped serving a market well enough, and the difference became big enough to justify the work.

The four tradeoffs

Almost every version of this question reduces to these four. Take them in order of how much they actually bite.

Two of these deserve more than a table row.

Reconciliation is the one that hurts. Adding a second provider does not just add finance work, it compounds it, because you inherit the job of making two different data models agree. Settlement timing differs. Refund and chargeback handling differ. Fee structures are itemised differently. Currency conversion may happen at different points in the flow. Until someone normalises all of that into one ledger, your month end gets slower and your revenue reporting gets softer.

Redundancy only exists if you built the failover. This is worth being blunt about because it is the most commonly claimed benefit of a multi-provider setup and the least commonly realised one. Holding contracts with two providers gives you a commercial fallback, not a technical one. Unless traffic can move between them without a deploy, a provider incident is still an outage. Ask yourself whether you could shift traffic in minutes today. If the honest answer is that it would take an engineering ticket and a release, you do not currently have redundancy.

How to evaluate an acquirer's authorisation performance without relying on sales claims

Providers usually quote a headline authorisation rate. It is rarely comparable, and the ways it becomes incomparable are consistent enough to test for.

Aggregate approval rate is close to meaningless on its own. Approval rate is a function of the traffic mix, not just the provider. A provider whose book skews towards domestic consumer debit will show a better headline number than one processing cross-border commercial credit, with no difference in capability. Comparing two headline rates compares two customer bases.

Ask for the denominator in writing. Before you compare anything, get the definition. Does an attempt include retries, or does a retried transaction count once? Are 3DS challenge abandonments counted as declines, excluded, or never counted as attempts? Are pre-auths and captures counted separately? Providers make defensible but different choices here, and the choice can move the headline number more than genuine performance does.

Insist on segmentation. A useful comparison is split by issuing country, card type (consumer or commercial, debit or credit), channel (ecommerce, telephone or recurring), and ideally BIN cohort. A provider that is genuinely stronger in a market will be stronger inside a segment. A provider that only looks stronger in aggregate is showing you a mix effect.

Separate soft declines from hard declines. Hard declines (closed account, reported stolen) are not recoverable and say nothing about the provider. Soft declines (issuer temporary failures, generic do-not-honour) are where routing and retry strategy earn their keep. Ask for the decline-code breakdown. If a provider will not share it, that is itself informative.

Ask what retry logic is applied and whether it is counted. Aggressive automated retries can lift a headline approval rate while also increasing scheme fees and, past a point, triggering the card schemes' excessive-reattempt fees. Both Visa and Mastercard operate programmes that charge for reattempts beyond a threshold. You want to know what is being done on your behalf and how it appears in the reporting.

The only honest test is matched traffic. Run both providers concurrently over the same period on comparable traffic, split by a neutral rule such as BIN range or round robin, and compare inside segments. Sequential tests are unreliable because seasonality, fraud pressure and your own product changes move the numbers underneath you. Be aware that pilot traffic tends to be your easiest traffic, so a pilot flatters everyone.

Ask who decides the routing, and whether you can see it. This is the question people skip. If your provider also owns the acquiring, it has a commercial reason to keep transactions inside its own network, which may or may not be the best path for a given transaction. That is not necessarily wrong, but you should know it is happening, be able to see the decision, and be able to override it. Shuttle is not an acquirer and does not issue merchant accounts, so it has no processing of its own to steer volume into.

What running multiple providers actually costs you

The rate card comparison is the easy part. These are the line items that usually get left out of the business case:

• Integration per provider. Each acquirer or PSP is its own API, its own error taxonomy, its own tokenisation model and its own edge cases. This is not a one-off cost, because it recurs every time one of them changes.

• Routing logic you own and maintain. Deciding which transaction goes where, handling failover, and keeping the rules current as you add markets.

• Reconciliation and reporting normalisation. Covered above. This is usually the largest hidden cost and it falls on finance, not engineering, so it often escapes the original estimate.

• Compliance validation. Each acquirer sets its own compliance validation and reporting requirements, so the paperwork and the SCA and 3DS implementation work repeat per relationship. Your PCI scope itself is set by how you handle card data, not by how many providers you hold.

• Ongoing maintenance. Provider APIs change, scheme rules update, local regulation evolves. Every additional relationship adds a stream of small mandatory work.

None of these are reasons not to run multiple providers. They are reasons to be honest about where the saving goes. A material rate improvement that gets consumed by ongoing engineering and finance maintenance is not a saving, it is a transfer.

The third option: keep the relationships, drop the integration burden

The framing of "one PSP or several" assumes you have to choose between simplicity and coverage. You do not, because the two costs are separable. The commercial relationships and the integration work are different problems.

Shuttle is a payment execution layer that sits above PSPs and gateways. You connect to it once, and it connects to the providers you hold relationships with. You keep your own contracts and your own rates, because Shuttle is not an acquirer, not a PSP and not a merchant of record.

What changes is where the work sits. Adding a provider becomes configuration and onboarding rather than a new integration build. You choose which connected provider handles a given payment type from the portal rather than in code. Payment methods can be filtered separately by minimum amount, maximum amount and currency. Transaction activity across your connected providers is visible in one place.

Be precise about what that does and does not cover, because this is where vendors in this category tend to overpromise. Processor selection is per payment type, and the amount and currency rules filter payment methods. There is no routing by issuing country or BIN. Currency is also not the same thing as market: one currency can span several acquiring markets, so a currency rule will not separate a French acquirer from a German one. Changing which provider handles traffic is a configuration change you make, not automatic failover. And because Shuttle tokenises with the gateway rather than holding card data itself, stored credentials stay with the provider that tokenised them, so continuity for saved cards and subscriptions depends on network tokenisation and on what your providers support.

That matters most in three situations:

• You are entering a market where your current provider is weak and you want a local relationship without a second integration to build and maintain.

• A large customer or a market mandates a provider you do not currently use. If Shuttle already connects to that provider, it becomes a provider you add rather than a build.

• You want to be able to move new transaction traffic between providers by changing configuration rather than shipping a release.

Shuttle supports a wide range of gateways and providers across a large number of markets. The current supported list is on the payment providers directory. If you want the technical detail on how connections and payment configuration work, the documentation is public, and PCI documentation including the AoC is at docs.shuttleglobal.com/docs/org-security.

A decision framework

Stay on one global PSP if: international volume is not yet material in any single market, your authorisation rates in your main markets are acceptable, no customer or regulator is mandating a provider you cannot support, and you can tolerate a provider incident. This covers a lot of businesses for a long time.

Add local acquiring in a specific market if: that one market is now material on its own, and you can point to a concrete problem there such as costs that have become a visible margin item, decline patterns concentrated on domestic issuers, settlement timing that is hurting working capital, or customers expecting local payment behaviour you cannot offer. Add it for that market, on evidence, rather than adopting a multi-acquirer posture everywhere at once.

Solve the integration layer first if: you can see more than one of these coming. If you are going to end up with several providers, the order matters. Adding the layer before the second provider means you integrate once. Adding it after means you integrate twice and then migrate.

Treat redundancy as its own reason. If concentration risk is the actual concern, say so explicitly, because it changes the design. Redundancy needs failover routing, not just a second contract.

If you decide to move

Do not migrate everything at once. The sequence that tends to work is: agree the metric definitions before you start so you can tell whether it worked, run the new provider in parallel on a slice of traffic, compare inside segments rather than in aggregate, then shift traffic progressively while keeping the ability to roll back.

Card data portability is the part that catches people out, particularly with saved cards and subscriptions. That is a solvable problem with a defined process, but it is not automatic and it needs planning before you sign anything. We cover it in detail in how to switch payment providers without losing customers.

Global PSP vs local acquirers FAQ

Is a single global PSP always more expensive for international payments?

No. It depends on where your volume actually is. A global PSP holding local acquiring licences can route domestically inside its own network in those countries, which captures much of the benefit without you contracting separately. The gap tends to open up in markets where your provider has no domestic presence and your volume there has grown. The honest answer is that it is worth checking per market rather than assuming.

Do I need separate contracts with each acquirer?

In a direct model, yes. Each relationship has its own commercial agreement, underwriting and onboarding. If you use a payment layer above your providers, you still hold the contracts, because the layer is not the acquirer. What changes is the integration and routing work, not the commercial relationship.

What is the difference between using multiple PSPs and payment orchestration?

Using multiple PSPs describes the commercial arrangement. Orchestration describes software that routes between them. The distinction that matters commercially is whether the software also sells you processing, because that creates an incentive in the routing.

Worth being clear about where we sit, since this guide describes configuring providers. Shuttle is a payment layer rather than an orchestrator: you configure which connected provider handles a payment type, and Shuttle does not make routing decisions about individual transactions on your behalf. It also has no processing of its own to route to. See payment orchestration vs payment layer for the fuller comparison.

How do I know if a provider's authorisation claims are real?

Get the definition of the metric in writing, insist on segmentation by issuing country and card type, ask for the decline-code breakdown split into soft and hard declines, and ask what retry logic is applied. Then test with matched concurrent traffic rather than sequentially. A provider that is genuinely stronger will be stronger inside a segment, not only in aggregate.

Does holding two providers give me redundancy?

Not on its own. Two contracts with no way to move traffic gives you the cost of a multi-provider setup and the resilience of a single one. Ask how quickly you could actually shift traffic today, and whether that needs a code change. Note also that stored credentials are tokenised with the provider that captured them, so saved cards and subscriptions do not move as freely as new transactions do.

Should I add local acquiring before or after fixing my integration layer?

If you expect to end up with more than one provider, do the layer first. Adding a second provider directly means building an integration you will later migrate. The sequencing is the difference between integrating once and integrating twice.

Where to go next

If you run payments across more than one market and this decision is live for you, the useful next step is a conversation about your specific markets and providers rather than a generic recommendation.

• Platforms embedding payments for their customers: platform payment infrastructure

• Businesses taking payments in several markets: payment services for merchants

• Either way, book a call and we will go through your markets, your current providers and what moving would actually involve.