When to Switch Payment Providers
Switching payment providers is one of the few infrastructure decisions where dissatisfaction creates pressure to move quickly at exactly the moment when diagnosis matters most. Low authorization rates create pressure to find a “better processor.” A disappointing international lau
When to Switch Payment Providers: How to Know Whether Your PSP Is Still the Right Fit
Switching payment providers is one of the few infrastructure decisions where dissatisfaction creates pressure to move quickly at exactly the moment when diagnosis matters most.
Low authorization rates create pressure to find a “better processor.”
An outage creates pressure to find a “more reliable PSP.”
A painful reconciliation process creates pressure to find a provider with “better reporting.”
A disappointing international launch creates pressure to find a “more global” payments partner.
Sometimes that conclusion is correct.
Sometimes the merchant changes providers, spends months migrating checkout, tokens, subscriptions, reporting and Finance workflows, and discovers that the original problem is still there.
The reason is straightforward:
Changing PSPs can fix a provider problem. It cannot automatically fix a payment architecture, data, fraud, integration, reconciliation, or organizational problem.
Before deciding to switch payment providers, determine where the constraint actually sits:
provider capability
→ provider execution
→ merchant configuration
→ merchant architecture
→ internal payment operations
Only then should the merchant choose among:
Optimize the existing PSP
Renegotiate the relationship
Add another PSP
Rearchitect part of the payment stack
Migrate specific traffic
Replace the provider
The right question is therefore not:
Are we unhappy with our PSP?
It is:
Is the PSP the constraint we need to remove?
When should you switch payment providers?
A business should seriously consider changing payment providers when material payment problems are attributable to structural or persistent limitations of the existing provider and cannot be resolved at an acceptable cost, risk, or timeframe through configuration, optimization, commercial negotiation, or supplemental providers.
Strong reasons can include:
Required countries or payment methods the provider cannot support
Acquiring limitations that materially constrain the merchant
Persistent reliability problems that are not being corrected
Architecture that prevents the merchant's required operating model
Reporting or reconciliation limitations creating disproportionate manual work
Economics that remain commercially unacceptable after proper comparison and negotiation
Support and escalation failures that repeatedly prevent important payment problems from being diagnosed or resolved
Strategic incompatibility with the merchant's future markets, products, subscriptions, marketplace model, or multi-PSP architecture
But dissatisfaction alone is not diagnosis.
Start by establishing what is actually broken.
First determine what is actually broken
A useful PSP replacement analysis can classify the problem across seven dimensions:
Performance
Reliability
Coverage
Economics
Operations
Technology
Support
The same symptom can have several causes.
That is why each dimension should be investigated before the merchant starts comparing replacement vendors.
Performance: is the PSP actually causing poor payment outcomes?
Low authorization is one of the most common reasons merchants consider switching processors.
But a low authorization rate can originate from:
Issuer behavior
Cross-border acquiring
Authentication
Fraud rules
Stored credentials
Transaction data quality
Routing
Merchant category or transaction characteristics
Retry behavior
Customer mix
Provider/acquirer performance
A global decline from:
88% authorization
to:
84%
does not establish that the PSP deteriorated.
Segment the change by:
Country
Issuer
Card network
BIN/IIN
Card type
Currency
Acquirer
PSP route
Authentication state
Credential type
Recurring versus one-time
Transaction-value band
New versus returning customer
Then ask whether the underperformance follows the provider.
If the same problematic population performs materially better through another valid route under comparable conditions, provider/acquirer performance becomes a stronger hypothesis.
If every provider sees the same deterioration after a merchant fraud change, switching PSPs will not repair the fraud configuration.
Internal link:
Proactive Payment Optimization
and:
Authorization Rate vs Payment Conversion Rate
Reliability: does the provider create unacceptable operational risk?
Repeated PSP incidents can justify replacement or diversification.
Evaluate:
API availability
Technical-error rate
Timeout behavior
Webhook/event reliability
Latency
Incident frequency
Incident recurrence
Time to diagnosis
Quality of corrective action
Availability of status retrieval
Settlement/report delivery reliability
One outage rarely establishes strategic incompatibility.
A recurring failure pattern with weak corrective action is different.
The important distinction is:
Provider failure
The provider's infrastructure is the recurring constraint.
versus:
Merchant integration failure
The provider is healthy, but the merchant's:
Timeout handling
Idempotency
State management
Retry logic
Webhook processing
Deployment architecture
creates the observed instability.
Migrating the same integration assumptions to PSP B can reproduce the problem.
Coverage: has the business outgrown the provider?
Coverage limitations are often among the clearest reasons to change or supplement a PSP.
A merchant may require:
New countries
Local acquiring
Additional currencies
Local payment methods
New card schemes
Recurring-payment support
Marketplace functionality
Payout capabilities
Merchant entities
Alternative settlement currencies
A provider cannot optimize its way around a capability it simply does not offer.
The important question is whether the limitation requires replacement.
Suppose the incumbent handles 90% of the merchant's existing markets well but cannot support one strategic country.
Replacing the entire PSP may be unnecessary.
Adding another provider for that market can be more rational.
Coverage problems often produce the strongest case for supplementation rather than wholesale migration.
Economics: is the provider genuinely too expensive?
Payment pricing can become a legitimate reason to switch.
But compare complete economics.
Potential costs include:
PSP markup
Acquiring charges
Interchange treatment
Network/scheme costs
Fixed transaction charges
Payment-method fees
Cross-border costs
FX
Refund charges
Chargeback costs
Minimum commitments
Settlement-related costs
Operational/manual work
Do not compare:
PSP A = 1.7%
against:
PSP B = 1.5%
and conclude that B is cheaper without confirming what each price includes.
Also incorporate payment outcomes.
A nominally cheaper route can produce worse economics if it causes sufficiently poorer payment success.
Internal link:
Auditing PSP Fees
Before switching solely for price, determine whether:
Pricing can be renegotiated
Volume tier has changed
Traffic can be routed differently
Certain markets are disproportionately expensive
Another provider should receive only cost-sensitive segments
Operations: how expensive is the PSP to operate?
A provider can be technically functional and operationally expensive.
Warning signs include:
Transactions and settlements are difficult to reconcile
Finance regularly downloads and manipulates manual files
Fee reporting is too aggregated
Refunds or disputes require manual investigation
Support cannot trace transactions easily
Payment state is unclear
Historical data is difficult to retrieve
Provider IDs have become embedded throughout merchant systems
Several internal teams maintain different interpretations of the same payment
The question becomes:
How much human infrastructure is required to compensate for provider limitations?
This cost can become material even when the processing fee is competitive.
But again, diagnose ownership.
If reconciliation is painful because the merchant has no canonical payment model and three disconnected internal databases, a new PSP may simply create a fourth dataset.
Internal links:
Multi-PSP Reconciliation
and:
Payment Reporting for Operations Teams
Technology: is the provider constraining the target architecture?
A PSP can become a strategic constraint when its technology prevents the merchant from building the architecture it needs.
Potential issues include:
Provider-specific checkout dependencies
Proprietary token dependence
Limited API functionality
Weak event/webhook semantics
Inadequate idempotency or status retrieval
Difficulty adding multiple acquirers
Limited routing
No practical multi-PSP support
Provider-bound payment state
Difficult credential migration
Poor historical data portability
This is where PSP lock-in becomes operational rather than theoretical.
AusPayNet's 2025 guidelines on payment-related-data porting explicitly address friction merchants can face when changing PSPs that hold customer card data. The guidelines distinguish network/scheme tokens from proprietary PSP tokens and note that proprietary tokens are generally limited to the merchant/PSP ecosystem. They also describe merchant-data portability as important enough that inability to move required credential information can force customers to re-enter card details or increase payment declines.
Internal link:
Avoiding PSP Lock-In
Support: is weak service hiding a deeper operating limitation?
Poor PSP support is a legitimate concern when it repeatedly prevents the merchant from operating payments effectively.
Evaluate more than:
First-response time
Phone availability
Account-manager title
Ask:
Can the PSP identify which acquirer handled the payment?
Can it analyze issuer patterns?
Can technical and acquiring teams be coordinated?
Are severe incidents escalated appropriately?
Do recurring issues reach root cause?
Does the provider preserve knowledge between incidents?
Can it explain material performance changes?
Are agreed actions followed through?
Does it proactively surface material deterioration?
A provider that repeatedly gives generic answers to material payment problems can become a genuine operating constraint.
But a dedicated account manager cannot compensate for missing product capabilities or merchant-side payment data.
Internal links:
What Good PSP Support Looks Like
and:
Payment Performance Reviews
Problems that may be fixable without switching PSPs
Switching should not be the default first response to every provider complaint.
Several classes of problems may be fixable more efficiently.
Configuration problems
Examples:
Incorrect currencies
Poor payment-method configuration
Authentication settings
Incomplete transaction data
Misconfigured recurring flags
Fix the configuration before changing infrastructure.
Routing problems
If the merchant already has multiple acquiring routes or PSP capabilities, performance may improve through better traffic allocation rather than replacement.
Internal link:
Payment Orchestration vs PSP
Fraud false positives
A PSP migration does not automatically improve payment performance if merchant fraud controls are blocking legitimate customers before processing.
Review Risk and Payments together.
Missing optimization
The provider may support:
Local acquiring
Better routing
Authentication optimization
Network tokenization
Account updater
Additional payment methods
that the merchant has never enabled.
The provider is not necessarily incapable merely because the merchant's current configuration is underperforming.
Commercial pricing
If the only significant problem is price, run a commercial review before rebuilding the payments stack.
Use competitor proposals as leverage where appropriate, but compare effective economics rather than headline rates.
Reporting configuration
Some reporting problems result from:
Fields not being consumed
APIs not integrated
Merchant IDs not mapped
Relevant reports never configured
Determine whether the information is actually absent or merely unused.
Escalation failure
A serious support issue may be resolvable by establishing:
Named technical escalation
Incident severity
Dedicated payment contact
Performance-review cadence
before replacing the platform.
Signs the PSP may genuinely be the constraint
The case for replacement becomes materially stronger when several of the following are true.
Structural market limitations
The provider cannot support the countries, entities, acquiring relationships, payment methods or currencies required by the merchant's strategy.
Persistent performance gap
Comparable transaction populations consistently perform worse through the provider and credible optimization work has not closed the gap.
Recurring unresolved incidents
The same reliability problems continue despite escalations and corrective-action commitments.
Architecture conflicts with strategy
The merchant needs an operating model the provider cannot support, such as:
More provider independence
Multiple acquirers
Certain routing controls
Particular credential architecture
Required payment methods
Reporting creates structural manual work
The provider cannot supply the transaction, settlement, fee or payout detail necessary for scalable Finance and Operations.
Commercial relationship remains unacceptable
Renegotiation cannot produce viable economics.
Support cannot operate at the merchant's complexity
Material problems routinely remain unresolved because the provider lacks appropriate:
Data
Expertise
Acquiring visibility
Technical access
Escalation
Roadmap is persistently misaligned
Critical capabilities remain unavailable on a timetable that conflicts with the merchant's business plan.
One limitation may justify supplementation.
Several structural limitations often justify replacement.
Optimize, add, or replace? A PSP decision matrix
Problem
Optimize Existing PSP
Add PSP
Replace PSP
Pricing
Strong option if commercial terms can change
Useful for selected lower-cost routes
Consider if economics remain structurally poor
Authorization
First diagnose configuration, fraud, auth and acquiring
Useful for testing/routing comparable traffic
Consider if persistent provider-specific gap is proven
Country coverage
Use if incumbent has needed capability
Strong option for incremental markets
Replace if strategic footprint fundamentally mismatches
Payment methods
Enable available methods first
Useful for specialist/local methods
Replace if missing methods are central to the business
Support
Improve escalation/account structure
Adds resilience but does not fix incumbent support
Consider if recurring material issues cannot be resolved
Outages
Improve incident/failover handling
Often valuable for redundancy
Replace if reliability remains unacceptable
Reporting
Integrate existing APIs/reports first
Can add even more reporting complexity
Consider if provider data fundamentally cannot support operations
Reconciliation
Fix merchant data model/configuration first
Requires multi-PSP reconciliation capability
Replace if incumbent creates structural unreconcilable burden
Lock-in
Abstract merchant-owned IDs/state where possible
Can reduce concentration
Consider migration if incumbent architecture blocks strategic flexibility
Subscriptions
Optimize stored-credential/recovery setup
Possible only with compatible credential architecture
Replace only with clear migration plan
Architecture
Refactor merchant layer where sufficient
Strong option for diversification
Replace if provider fundamentally prevents target design
The matrix is not an automatic scoring system.
It forces the merchant to identify the intervention most proportionate to the problem.
Should you replace the PSP or add another one?
This is one of the most important strategic distinctions.
A second provider can be valuable when the merchant wants to:
Enter markets the incumbent cannot serve
Add local acquiring
Introduce a specialist payment method
Compare performance
Create outage redundancy
Route according to defined objectives
Reduce dependency on one provider
Modern orchestration products explicitly support routing transactions across multiple PSPs or acquirers, illustrating that adding another provider can be an architectural alternative to full replacement. Braintree's current orchestration documentation, for example, describes connecting multiple PSP/acquiring paths through a shared control layer and routing transactions among supported connectors.
But adding a PSP creates new complexity:
Another commercial relationship
More payment states
More provider IDs
More reporting
More reconciliation
More credential considerations
Routing governance
More incident paths
A second PSP is not free redundancy.
It is another production system.
Add one when the value of diversification or specialization exceeds that operational burden.
What switching payment providers actually involves
The checkout integration is only one workstream.
A serious migration inventory should examine at least the following.
Integration
API calls
SDKs
Checkout components
Authentication
Webhooks
Status retrieval
Idempotency
Capture
Refund
Reversal
Payment methods
Each method may require:
New contracts
Configuration
Merchant IDs
Testing
Customer-flow changes
Do not assume equivalent method coverage means equivalent implementation.
Stored credentials and tokens
This can be one of the largest hidden dependencies.
A PSP vault token may not be usable by the destination provider.
AusPayNet's portability guidelines explicitly distinguish proprietary PSP tokens from scheme/network tokens and state that the relevant standard does not make one provider's proprietary token directly interoperable with another provider. Instead, migration can require the underlying merchant payment-related data or relevant scheme-token information to be ported through appropriate processes.
Mastercard Gateway documentation likewise provides a formal merchant-data import process for merchants migrating from another gateway or PSP, including importing payment data for subsequent transactions and recurring payments.
A current NAB gateway migration guide demonstrates the practical complexity: it documents both secure file-based and API-based token-migration approaches and requires specific prerequisites and controlled transfer processes.
Internal link:
Payment Token Migration
Subscriptions
Recurring billing introduces additional questions:
Which reusable credential moves?
What recurring state moves?
Which reference identifies the original stored-credential relationship?
What customer action may be required?
How are next renewals tested?
What happens to subscribers that cannot migrate?
Credential migration and subscription migration are related.
They are not identical.
Fraud
A new provider can produce different:
Data
Risk signals
Authentication behavior
Decline patterns
Do not assume fraud performance will remain constant after migration.
Reporting
Map destination-provider data into:
Merchant reporting
BI
Finance
Support
Payment Operations
Do this before large production ramp.
Reconciliation
Validate:
Transaction IDs
Captures
Refunds
Fees
Settlements
Bank movements
A migration that works for Checkout but breaks month-end reconciliation is not complete.
Settlement and Treasury
Verify:
Settlement currencies
Timing
Merchant entities
Bank accounts
Funding requirements
Reserves where applicable
Customer experience
Test:
Devices
Browsers
Locales
Authentication
Redirects
Wallets
Stored cards
Error handling
The merchant is changing infrastructure.
The customer should not become the migration test environment.
Payment-data portability deserves investigation before the contract is signed
Token and data portability should ideally be evaluated when selecting a PSP, not only when leaving one.
AusPayNet's current Australian portability framework was explicitly created because merchant switching can be impeded when PSPs hold sensitive customer-payment data. The guidelines state that payment-related data may need to move securely between sending and receiving parties so customers can continue future transactions without re-entering sensitive card information.
The jurisdiction-specific standard does not apply universally.
The broader procurement lesson does:
Before placing a large stored-credential population inside a PSP-controlled environment, understand the exit path.
Ask prospective providers:
What can be exported?
In which format?
Who can receive it?
What security process applies?
How are proprietary tokens handled?
How are network tokens handled?
What costs apply?
What happens after contract termination?
PCI SSC also notes that tokenization systems and any systems capable of retrieving PAN data require appropriate PCI DSS controls, which is one reason token migration should be handled through approved secure processes rather than merchants casually extracting raw card data themselves.
Plan the migration before terminating the incumbent PSP
Do not structure migration as:
sign new provider
→ shut off old provider
→ move payments
A more controlled model is:
define objective
↓
inventory dependencies
↓
build destination
↓
migrate/configure credentials where applicable
↓
test
↓
limited production traffic
↓
compare outcomes
↓
ramp
↓
new-traffic cutover
↓
legacy operations
↓
final decommission
Parallel operation can be useful because the old PSP may still be required for:
Historical refunds
Disputes
Existing recurring credentials
Pending payments
Settlement
Reconciliation
Historical reporting
The detailed process belongs in:
Migrating Payment Providers
The critical point here is:
“100% of new traffic uses PSP B” and “PSP A can be terminated” are not necessarily the same milestone.
PSP migration risk checklist
Before committing to replacement, confirm ownership of the following.
Business
Original problem defined
Success metrics defined
Migration budget
Commercial exit terms
Destination-provider agreement
Technical
New API integration
State mapping
Webhooks/events
Idempotency
Timeout handling
Refunds
Testing
Rollback
Credentials
Stored-card inventory
Token type
Token-export process
Import process
Network-token considerations
Customer remediation plan
Subscriptions
Active subscription count
Recurring credential path
Billing state
Next-renewal validation
Payments
Country coverage
Currency coverage
Payment-method parity
Authentication
Fraud
Finance
Reporting
Fees
Settlement
Reconciliation
Bank accounts
Operations
Monitoring
Incident escalation
Support training
Runbooks
Legacy-provider ownership
Measurement
Baseline performance
Migration cohorts
Comparison methodology
Post-migration review date
If several of these remain unanswered, the merchant has selected a new vendor but has not yet designed a migration.
How to evaluate replacement payment providers
Use a consistent framework:
Performance
Can the provider demonstrate and support the acquiring/payment architecture required for the merchant's traffic?
Evaluate:
Authorization capabilities
Payment conversion
Acquiring
Routing
Authentication
Fraud integrations
Do not rely on universal approval-rate claims.
Reliability
Evaluate:
API architecture
Status retrieval
Event delivery
Incident handling
Redundancy
Operational history available to you during diligence
Economics
Model:
Processing
Acquiring
Fixed fees
Cross-border
FX
Refunds
Chargebacks
Operational cost
Minimum commitments
Compare effective merchant economics.
Operations
Evaluate:
Reporting
Reconciliation
Settlement
Transaction search
Historical records
Finance workflows
Coverage
Evaluate:
Countries
Currencies
Local methods
Card schemes
Merchant entities
Recurring support
Marketplace/payout needs
Use the merchant's actual expansion roadmap.
Technology
Evaluate:
APIs
SDKs
Webhooks
State model
Credential architecture
Token portability
Orchestration compatibility
Data export
Include the exit architecture.
Support
Evaluate:
Technical expertise
Escalation
Incident coordination
Account management
Acquiring/payment expertise
Performance analysis
Optimization
Internal link:
What Good PSP Support Looks Like
Measure whether the migration actually solved the original problem
One of the most important stages occurs after the migration.
Suppose the original problem was:
Authorization is poor in Country A.
After switching providers, compare the destination PSP with the old baseline using appropriately comparable traffic.
Do not declare success because:
Migration completed.
Measure the objective that justified it.
If the reason was authorization
Track:
First-attempt authorization
Payment conversion
Decline mix
Comparable transaction cohorts
If the reason was reliability
Track:
Technical-error rate
Timeout rate
Incidents
Unknown payment states
Service availability according to the merchant's own evidence
If the reason was economics
Track:
Effective cost
Cost per successful payment where appropriate
FX
Operational cost
Actual invoice/settlement economics
If the reason was support
Track:
Material issue resolution
Recurrence
Escalation
Root-cause completion
Time from finding to corrective action
If the reason was reporting/reconciliation
Track:
Manual intervention
Reconciliation exceptions
Data completeness
Close burden
Finance support requirements
If the reason was coverage
Track:
New markets successfully launched
Local-method utilization
Payment performance in those markets
Operational burden
A migration without post-migration measurement is a costly hypothesis that was never tested.
The “Should You Switch PSPs?” decision framework
Use this sequence:
PAYMENT PROBLEM DETECTED
|
v
IS THE ROOT CAUSE KNOWN?
/ \
NO YES
| |
v v
DIAGNOSE IS THE CURRENT PSP
FIRST THE CONSTRAINT?
/ \
NO YES
| |
v v
FIX MERCHANT CAN PSP
ARCHITECTURE / RESOLVE IT
CONFIGURATION? ACCEPTABLY?
/ \
YES NO
| |
v v
OPTIMIZE IS THE GAP
SEGMENT-SPECIFIC?
/ \
YES NO
| |
v v
ADD PSP EVALUATE
REPLACEMENT
|
v
MIGRATION COST
JUSTIFIED?
/ \
NO YES
| |
v v
REARCHITECT / MIGRATE
RENEGOTIATE IN STAGES
This prevents the most expensive mistake:
Changing providers before proving that the provider is the problem.
Final recommendation
A PSP switch is justified when the merchant can show that:
a material payment problem exists,
the root cause is understood well enough to isolate the provider as a significant constraint,
reasonable optimization or remediation cannot solve it,
and:
the expected value of changing the provider exceeds the cost and risk of migration.
That standard naturally produces several possible outcomes.
Sometimes the answer is:
Stay and optimize.
Sometimes:
Renegotiate.
Sometimes:
Fix the merchant's own architecture.
Sometimes:
Add a second provider for one market or capability.
And sometimes:
The incumbent PSP no longer fits the business. Replace it.
The important part is reaching that conclusion through evidence rather than frustration.
As payment operations grow, provider relationships accumulate dependencies:
APIs
Tokens
Subscriptions
Fraud
Reporting
Settlement
Finance processes
Support procedures
Institutional knowledge
That makes switching more consequential precisely when it can also become more strategically necessary.
The mature merchant therefore treats provider replacement as both a diagnostic decision and an infrastructure migration.
Diagnose first.
Identify the actual constraint.
Choose the proportionate intervention.
Design the exit before turning off the incumbent.
Then measure whether the original problem actually disappeared.
Because a successful PSP migration is not one where all traffic reaches the new provider.
It is one where the merchant's payment operation is demonstrably better against the objective that justified the switch in the first place.
This article provides general information and does not constitute legal, regulatory, financial, tax, accounting, security, network-rule, contractual, or compliance advice. Payment-provider capabilities, contracts, stored-credential requirements, migration processes, token portability, payment-method rules, settlement arrangements, and applicable requirements vary by merchant, provider, acquirer, network, market, and jurisdiction. Merchants should verify current requirements with their payment providers, acquirers, card networks, qualified security and payments specialists, legal advisers, Finance teams, and other relevant advisers.
🙂 🙂 🙂 🙂 🙂 🙂 🙂
A safe positioning is:
As a merchant's payment operation expands across countries, currencies, local payment methods and business models, the relevant question is not whether a provider can process a transaction in isolation. It is whether the provider's payment coverage, operating model, data, technical architecture and support remain aligned with the merchant's current and future requirements.
Current country coverage
Payment-method coverage
Currency support
Local acquiring
Recurring capabilities
Marketplace/payout capabilities
Reporting
Reconciliation
Token migration
Multi-PSP compatibility
Merchant support
Performance reviews
Optimization services
Migration assistance
Improve authorization
Reduce fees
Migrate all stored cards
Replace every incumbent capability
Eliminate reconciliation work
Deliver zero-downtime migration
The article should earn commercial credibility through the diagnostic framework rather than forcing a sales conclusion.
Recommended title
When to Switch Payment Providers: How to Know Whether Your PSP Is Still the Right Fit
When to Switch Payment Providers: A Merchant Decision Framework
Meta description
Learn when to switch payment providers, when to optimize or add a second PSP instead, what to compare before migrating, and how to manage stored cards, subscriptions, reporting, reconciliation, costs, and migration risk.
URL slug
/when-to-switch-payment-providers/
switch payment provider
Secondary keywords
switch payment processor
change payment provider
change payment processor
migrate payment provider
replace payment gateway
when to change payment processor
PSP migration
payment processor migration
payment provider problems
alternative payment provider
payment provider evaluation
Search intent
High-intent commercial investigation / provider replacement.
The article should satisfy a merchant who is already questioning the incumbent PSP but has not yet determined whether replacement is the correct intervention. The brief's most important contribution is the distinction between provider problems and problems that will simply follow the merchant to its next provider.
ARTICLE
SEO, EDITORIAL & PRODUCTION ADVICE
FAQ
When should I switch payment processors?
Consider switching when a material problem is attributable to a persistent or structural limitation of the current provider and cannot be resolved acceptably through configuration, optimization, commercial negotiation, or supplementation. Examples include strategic coverage gaps, recurring unresolved reliability issues, architectural limitations, or operational burdens the incumbent cannot remediate.
Should I switch PSPs because my authorization rate is low?
Not automatically. Low authorization can result from issuer behavior, acquiring, authentication, fraud controls, credentials, routing, transaction data, customer mix or the PSP itself. Segment comparable traffic and identify the source of the underperformance before concluding that provider replacement will improve the result.
Can I use two payment processors?
Yes, where the merchant's architecture and the providers support it. A multi-PSP strategy can provide geographic specialization, additional acquiring routes or redundancy. It also introduces more routing, credentials, reporting, reconciliation and operational complexity, so a second provider should solve a defined business problem.
What happens to stored cards when changing PSPs?
It depends on how the credentials are stored. Proprietary PSP tokens generally cannot simply be sent to another PSP. Migration can require a controlled transfer of payment-related data, re-tokenization, scheme/network token processes or, for some credentials, customer re-entry. AusPayNet's current portability framework explicitly distinguishes proprietary and network tokens and provides an example of formal PSP-to-PSP data porting.
Can recurring subscriptions be migrated to another PSP?
Often, but subscription migration depends on credential portability, provider capabilities, merchant and network requirements, recurring-payment metadata, billing-system architecture and the population being migrated. Mastercard Gateway, for example, currently documents merchant-data import specifically to support subsequent and recurring transactions after migration.
How difficult is it to change payment providers?
Difficulty varies enormously. A simple one-time card integration with no stored credentials can be materially easier than a global merchant with subscriptions, local payment methods, multiple entities, fraud tooling, settlement feeds and millions of saved credentials. The correct planning unit is the dependency inventory, not a universal number of weeks.
Should I replace my PSP or add another provider?
Add another PSP when the problem is segment-specific or when diversification itself creates value, such as new-market coverage or redundancy. Replacement becomes more compelling when the incumbent's limitations affect a substantial portion of the business or fundamentally conflict with the target payment architecture.
What should I compare when choosing a new payment provider?
Compare performance, reliability, economics, operations, coverage, technology and support. Include effective costs, acquiring, payment methods, currencies, APIs, token/data portability, reporting, reconciliation, settlement, support escalation and the provider's fit with your future operating model—not just headline transaction pricing.
Suggested internal links
What Good PSP Support Looks Like
Use when evaluating whether the current relationship's support model is structurally weak.
Proactive Payment Optimization
Use before concluding that poor authorization or conversion requires replacement.
Payment Performance Reviews
Use for establishing the evidence base that should precede a provider decision.
Migrating Payment Providers
Use when the decision to move has already been made and the reader needs the migration program.
Avoiding PSP Lock-In
Use in the technology and data-portability discussion.
Payment Token Migration
Use when discussing saved credentials and subscriptions.
Multi-PSP Reconciliation
Use when discussing the operational cost of adding rather than replacing a PSP.
Payment Orchestration vs PSP
Use when introducing multi-provider control layers.
Payment Failover
Use from the reliability/redundancy discussion.
Suggested anchor text
what good PSP support should look like at scale
proactively diagnosing payment-performance problems
running a structured PSP performance review
planning a staged payment-provider migration
reducing payment architecture dependence on one PSP
migrating stored payment tokens safely
reconciling payment data across multiple PSPs
using orchestration to manage multiple payment providers
designing payment failover without creating duplicate-payment risk
Recommended authoritative external sources and citations
AusPayNet — PSP data portability
The strongest source for the article's portability discussion is the Australian Payments Network's 2025 Guidelines for Payment Service Provider Porting of Merchant Payment-Related Data. It explicitly identifies switching friction caused by PSP-held card data, distinguishes proprietary PSP tokens from scheme/network tokens, and describes secure movement of merchant payment-related data between providers.
Use it carefully as an Australian industry standard/guideline example, not a universal global requirement.
Mastercard Gateway — merchant data migration
Mastercard Gateway currently documents importing payment data from an existing payment provider, including token migration and continued use for subsequent or recurring transactions. This is useful primary technical evidence that saved-credential migration is a distinct migration workstream.
NAB — token migration
NAB's April 2026 Gateway Token Migration User Guide documents both secure file-based and API-based approaches, prerequisites, testing and optional updater treatment during migration. It is useful evidence of the operational/security work hidden behind the phrase “move the tokens.”
PCI Security Standards Council — tokenization
PCI SSC's tokenization guidance establishes that tokenization replaces PAN with surrogate values and that environments capable of accessing PAN or token-to-PAN mappings remain subject to appropriate cardholder-data security controls. Use it to reinforce that token migration should follow controlled provider/security processes rather than ad hoc merchant extraction of card data.
Braintree/PayPal — multi-provider orchestration
Braintree currently documents a payment-orchestration model connecting merchants to multiple PSP/acquirer routes through one integration. Use it as a primary technical example that adding another processor can be a distinct architectural strategy from replacing the existing provider.
Optional visual and diagram opportunities
Should You Switch PSPs? Decision Tree
PAYMENT PROBLEM
|
v
ROOT CAUSE KNOWN?
/ \
NO YES
| |
v v
DIAGNOSE PSP THE CONSTRAINT?
FIRST / \
NO YES
| |
v v
FIX CONFIG / CAN PSP
ARCHITECTURE FIX IT?
/ \
YES NO
| |
v v
OPTIMIZE SEGMENT-SPECIFIC?
/ \
YES NO
| |
v v
ADD PSP REPLACE?
Caption: Diagnose the constraint before choosing the intervention.
Alt text: Decision tree for determining whether a merchant should optimize its existing payment provider, add a second PSP, fix internal architecture, or replace the PSP.
PSP Evaluation Scorecard
A seven-column or radial scorecard:
Performance | Reliability | Economics | Operations | Coverage | Technology | Support
Each dimension can receive:
Current state
Required state
Gap
Fixable?
Replacement advantage?
Evidence
This would work particularly well as a downloadable evaluation worksheet.
Provider Problem vs Merchant Problem
Two-sided diagnostic graphic:
Provider-side constraints
Coverage
Acquiring
Reliability
Product capabilities
Data availability
Support expertise
Merchant-side constraints
Integration
Fraud configuration
Checkout
Data model
Reconciliation architecture
Ownership
Center:
Observed symptom
Examples: low authorization, outages, reporting burden, slow investigations.
This reinforces the article's differentiated thesis visually.
Replace vs Add PSP architecture
REPLACE
Merchant
|
v
PSP A → PSP B
ADD
Merchant payment layer
|
┌─────┴─────┐
v v
PSP A PSP B
Add below:
Replace: lower steady-state provider count, higher migration dependency.
Add: diversification and specialization, but greater routing/reconciliation complexity.
Migration Dependency Iceberg
Above water:
Checkout API
Payment page
Below water:
Tokens
Subscriptions
Authentication
Fraud
Webhooks
Refunds
Disputes
Reporting
Settlement
Reconciliation
Support
Finance
Historical transactions
This is a particularly strong header/LinkedIn derivative because it visually explains why changing payment processors is rarely “just another integration.”
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗