Adding a second PSP without a re-integration: a step-by-step plan

The decision to add a second payment provider is usually easy. An outage, a reserve, a weak approval rate in one country or a pricing review makes the case. The project that follows is where teams get stuck, because “add a provider” turns out to mean rebuilding half of the payment stack a second time.

This article is the how-to. Our piece on single-PSP risk covers why to add a provider, and how many PSPs per market covers how many you need. Here we set out what a direct second integration really involves, what changes when an orchestration layer sits in front of the providers, how to handle saved cards, and a step-by-step plan for moving traffic safely.

What does a direct second integration actually involve?

More than the payment call. Every part of the stack that touches the first provider needs a twin for the second, and the two must agree with each other.

Area	What has to be built or changed
Checkout	A second card form or SDK, its 3-D Secure flow, and the provider’s local methods
Saved cards	A second vault, or a migration, and logic to decide which token to charge
Payment API calls	Authorise, capture, void, refund and payout calls in the second provider’s model
Webhooks	A second endpoint, signature scheme, retry pattern and status vocabulary
Decline codes	Mapping the second provider’s codes to the same retry and cascade decisions
Back office	Refunds, disputes and customer support tools that work on both
Reconciliation	A second settlement report format, fee model and payout calendar
Monitoring	Approval, error and latency dashboards that compare the two fairly

The webhook row alone shows why. Checkout.com retries a failed webhook up to eight times at intervals from 5 minutes to 12 hours. Adyen queues a webhook for retry if it gets no successful response within 10 seconds, and identifies duplicates by event code and reference. Each provider’s rules are reasonable; handling both correctly in one ledger is work.

What changes with an orchestration layer?

The twin disappears from your side. Your checkout, back office and ledger integrate once, with one API, one transaction model, one set of statuses and one webhook format. The orchestration layer holds the connection to each provider and translates.

Adding a provider then becomes configuration:

• Credentials for the new provider’s merchant account.
• Eligibility rules: which countries, methods, currencies, amounts and customer groups it may receive.
• Routing rules: which share or segment of eligible traffic it gets, and in which order providers are tried.
• Cascade policy: which failures move a payment from one provider to the next.

What does not disappear is everything outside the code: the new provider’s underwriting, its contract, its settlement and fees, and the migration of saved cards if they live in the first provider’s vault.

How do you handle saved cards?

This is the slowest part, so start it first. There are three situations:

1. Cards in a vault you control, independent of either provider. Both providers can charge them from day one, and no migration is needed. This is the position to aim for.
2. Cards in the first provider’s vault, and you keep that provider. Returning customers can stay on it while new customers are spread across both. Migration can wait.
3. Cards in the first provider’s vault, and you want them usable elsewhere. You need an export.

Exports have rules. Stripe’s documentation is a clear example: it transfers card data only to a PCI DSS Level 1 processor, which must provide its Attestation of Compliance or a listing on Visa’s Global Registry of Service Providers, and a PGP key of at least 4096 bits. The export includes card details, email addresses and metadata, but not payment history or subscriptions. On the receiving side, Stripe says a previous processor can take a few days or several weeks to send the data, and that it typically imports within 10 business days of receiving correct data.

Two migration details catch teams out. Cards updated by customers between the export and the import can be lost unless the flow handles them. And imported cards on file must keep their correct flags: Stripe warns that issuers which cannot confirm a cardholder’s consent to future payments may decline them. Our article on network tokens vs PSP tokens covers which token types travel between providers.

What is a safe step-by-step plan?

1. Start underwriting and contracting. Share your real traffic by country, method and amount. Confirm local acquiring, payouts and settlement currency.
2. Map statuses and decline codes. Decide how the new provider’s results map to your statuses and to your retry and cascade rules. Our guide to soft vs hard declines lists which codes are worth a second attempt.
3. Align the descriptor. Use a statement descriptor customers already recognise. Stripe notes that descriptor changes can trigger issuer risk models.
4. Test the full lifecycle in the provider’s test environment. Payment, 3-D Secure, capture, partial refund, full refund, payout, failed payout, duplicate webhook and late webhook.
5. Send a first live segment. One country, one method, a small share. Check every webhook and the first settlement file against your ledger.
6. Compare fairly. Measure approval on payments, not attempts, for the same segment at both providers over the same period. Our guide on how to calculate approval rate explains why the two differ.
7. Ramp in steps. Increase the share only after each step’s numbers settle. Watch decline code mix, not only the rate.
8. Turn on cascading once the provider is proven, so soft declines and technical failures at one provider can move to the other.
9. Keep both warm. Leave a share of traffic on each route permanently, so a failover never sends a cold provider a sudden surge.

Worked example: ramping a second provider in Turkey

Example figures, for illustration only.

A merchant takes 40,000 card payments a month from Turkey through provider A. It adds provider B, which acquires domestically.

Stage	B’s share	Payments at B per month	What is checked
1	Debit cards from one issuer, 5%	about 2,000	Webhooks, refunds, first settlement
2	All debit cards, 20%	about 8,000	Approval on payments against A for the same segment
3	All cards, 50%	about 20,000	Decline code mix, fraud and chargeback signals
4	Routed by measured performance	varies	Monthly review, cascading both ways

At stage 2, B approves 81% of debit card payments against A’s 74% for the same segment over four weeks, on several thousand payments each. That difference is large enough to act on. Had B handled only 150 payments, it would have been noise.

What should the contract with the second provider cover?

The commercial terms decide whether the second route stays usable. Before the first live payment, confirm in writing:

• Coverage for your real traffic: countries, currencies, methods, payouts, and whether acquiring is local in your largest markets.
• Settlement: currency, timing, fees netted or invoiced, and the report you will receive per batch.
• Reserves and limits: any rolling reserve, volume caps or notice periods before either changes.
• Card data: your right to export saved cards on exit, to a compliant receiver, within a stated time.
• Descriptor: the name customers will see on statements.

What are the common mistakes?

• Treating it as a code project. The calendar is usually set by underwriting and card migration, not development.
• Big-bang cutover. Moving all traffic at once hides problems until they are expensive, and can look like a risk event to the new provider.
• Comparing attempts with payments. With cascading, attempt counts mislead. Compare payments in the same segment and period.
• Forgetting the back office. Refunds, disputes and payouts must work on both providers before the ramp, not after the first complaint.
• A cold backup. A provider that gets no traffic for months is not a backup you can rely on.

How does Omno help add a second PSP?

With Omno, your systems integrate once, and each provider connected to Omno is added by configuration: credentials, PSP eligibility rules and routing rules. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. Webhooks arrive in one format whichever provider processed the payment, saved cards are tokenized so they can be used across the providers you route to, and the routing-decision log shows which provider was eligible and chosen for every payment. The payment orchestration page covers the integration, and smart routing and cascading covers the rules.