How to run several payment providers at once

To run several payment providers at once, keep the billing platform as the single owner of invoices and customers, connect each payment service provider (PSP) as a gateway, and define rules that pick the provider for each payment: by country, currency, payment method or customer segment. Add a failover rule for when a provider is down or declines for technical reasons, and keep retries and dunning in billing so they work the same whatever provider took the payment.

Why companies use more than one PSP

A single provider is simpler, and many companies should stay with one. A second provider usually comes from one of these needs:

• Local payment methods. Direct debit in Europe, local cards or bank transfers in some markets are better covered by a regional provider.
• Currency and settlement. Settling in local currency into a local bank account avoids conversion fees and can raise acceptance.
• Acceptance rates. Some card issuers accept charges from local acquirers more often than from cross-border ones.
• Resilience. If a provider has an outage on renewal day, a second one can take the volume.
• Negotiation and concentration risk. Volume split across providers is easier to move.

How multi-PSP billing works

The billing platform keeps one customer record and one invoice. The payment is what gets routed. A working setup has five parts:

1. Gateway connections. Each PSP is connected with its own credentials and settlement account. The billing platform stores the provider’s payment method token on the customer, not the card itself.
2. Routing rules. An ordered list of conditions: customers in the euro area paying by direct debit go to provider B; cards in USD go to provider A; everything else goes to A. Rules run when the invoice is charged.
3. Failover. If a provider returns a technical error or times out, the platform retries the same charge on a second provider. This only works for payment methods that exist on both providers, which is the main limit of failover.
4. Retries. Soft declines (insufficient funds, issuer unavailable) are retried on a schedule. Hard declines (stolen card, closed account) are not retried and go straight to dunning.
5. Dunning. Emails, in-app notices and account actions (pause, downgrade, cancel) follow a sequence until the invoice is paid or written off.

Because invoices and dunning live in billing, finance sees one receivables ledger. The reconciliation work moves to the payouts: each provider pays out on its own schedule, net of its own fees. See how to connect your billing system to an ERP for how payouts are matched to invoices.

Worked example

This is an illustrative routing table, not a recommendation for any provider.

Rule	Condition	Primary provider	Fallback
1	Country in EU, method = direct debit	Provider B	None (mandate is provider-specific)
2	Currency = GBP or EUR, method = card	Provider B	Provider A
3	Currency = USD, method = card	Provider A	Provider B
4	Any other case	Provider A	None

A German customer on a €900 monthly card plan is charged on the 1st. Provider B times out. Under rule 2 the platform retries on provider A, which succeeds. The invoice shows as paid, with the provider recorded on the payment.

A US customer’s card returns “insufficient funds” on the 1st. This is a soft decline, so no failover is attempted. The retry schedule tries again on day 3 and day 7, while the dunning sequence emails the billing contact on day 1, 4 and 8. On day 14 without payment, the account moves to a restricted plan.

Note the difference: failover handles provider problems; retries and dunning handle customer problems. Mixing them, for example by sending a declined card to a second provider, rarely helps and can trigger fraud flags.

Common pitfalls

• Tokens that do not move. A card saved with one provider cannot be charged by another unless the token is portable or the card is stored by a network tokenization or vault service. Plan failover only for methods that exist on both sides.
• Direct debit mandates. A mandate belongs to the provider that collected it. Switching providers usually means collecting new mandates.
• Dunning per provider. If each PSP runs its own retries and emails, customers get duplicate messages and finance gets conflicting status. Turn off provider-side dunning and run it from billing.
• Reconciliation. Two providers means two payout files, two fee structures and two currencies of settlement. Budget for it.
• Refunds. A refund must go back through the provider that took the payment. Check that the platform tracks this per payment.

Checklist: what to ask a vendor

• Which payment gateways are natively connected, and can several be active at the same time?
• Can routing rules use country, currency, payment method and customer segment?
• Is failover automatic, and on which error types does it trigger?
• How are retries scheduled, and are soft and hard declines handled differently?
• Is dunning configurable per segment, with emails, in-app notices and account actions?
• How are refunds, disputes and payouts tracked per provider?
• How are payouts reconciled against invoices?

Which quote-to-cash platforms document it

The table ranks the platforms that document multiple payment providers, payment gateways and dunning. 23 of the 44 platforms we score document running multiple payment providers, while 42 document payment gateway connections and 40 document dunning.

The full lists are on our multiple payment providers and dunning pages. How levels are assigned is explained in the scoring criteria.

FAQ

Can a failed card payment be retried on another provider?

Only if the payment method is available on both providers and the failure is technical, such as a timeout or an outage. A card declined by the issuer for lack of funds will usually be declined again, whatever the provider.

Should dunning run in the billing platform or in the PSP?

In the billing platform. It owns the invoice and the customer, so it can run one sequence across all providers and update the subscription when payment finally succeeds or fails.

How many payment providers does a SaaS company need?

Most start with one. A second one is justified by local payment methods, local currency settlement, or the cost of an outage on a renewal date. Beyond two or three, reconciliation work tends to outweigh the gains.