Traffic splitting between payment providers: setting shares and reading results

Once a merchant has two providers, the first routing question is usually simple: how much should each one get? A traffic split answers it with a number. Send 90% here and 10% there, then see what happens. The setup takes minutes. Reading the result honestly takes more care, because a split can show a gap between providers that comes from the traffic rather than the provider.

This article explains what a split does and why merchants use one, how to set the shares, how to compare providers fairly and which mistakes to avoid. It assumes you already have a second provider. If you do not, start with adding a second PSP.

What is traffic splitting, and how is it different from cascading?

Traffic splitting divides eligible payments across providers in set proportions before any attempt is made. APEXX’s documentation draws the distinction clearly: cascading reroutes transactions that fail, while a split divides traffic before processing begins. Hyperswitch’s documentation adds that a split applies to whole payments and never divides the amount of a single payment.

A split is one layer in a routing decision. It helps to keep the layers apart:

Layer	Question it answers	Example
Eligibility	Which providers may take this payment?	Provider supports the country, currency and amount
Routing rule	Which group of payments is this?	Cards issued in Spain, in euros
Traffic split	Which eligible provider gets the first attempt?	90% to provider A, 10% to provider B
Cascading	What happens if that provider cannot take it?	Move to the next provider in the rule

DEUNA’s documentation follows the same order: rule conditions decide eligibility, and the split sits after them.

Why split volume across providers?

Vendor documentation describes five common reasons, and each one calls for a different setup.

• Testing a new provider. Zuora’s documentation suggests sending 10% to a new gateway while 90% stays on the existing provider, and also describes comparing two gateways at 50% each.
• Balancing cost and performance. A cheaper route may be good enough for part of your traffic. A split lets you measure that on live payments before you commit. Our guide to interchange++ and blended pricing explains what to compare.
• Keeping a second provider active. Hyperswitch lists this as a use case. A provider that takes real traffic every day is a working route on the day you need it, as our article on single PSP risk explains.
• Meeting volume commitments. APEXX gives the example of a merchant that must send 10,000 transactions a month across four acquirers and uses a 25% split for each. Primer describes the same use.
• Moving volume gradually. Primer describes shifting traffic off a provider you are leaving, or onto a new one, in steps, and spreading volume across processors during peaks so that no single service is overloaded.

Write down which reason applies. A commercial split and a test have different success measures, and a split that tries to be both usually answers neither.

How do you set the shares?

Use this checklist before you switch a split on.

1. State the question. “Does provider B approve Spanish debit cards at least as well as provider A?” is a test. “Keep provider B above its monthly minimum” is a commercial target.
2. Narrow the segment. Primer’s examples are approval rates in Spain and performance on euro payments. Hyperswitch suggests placing the split inside a rule condition when you want to split only a subset of traffic.
3. Confirm eligibility on both routes. Hyperswitch warns that an ineligible preferred processor can change the final allocation, so a 50/50 split can drift without anyone changing it.
4. Choose a starting share. Zuora uses 10% and APEXX uses 5% as examples. A small share limits exposure, while a larger one answers the question sooner. Primer calls the cost of exposing customers to the weaker route during a test “regret”.
5. Check the unit. APEXX’s split works on transaction counts, not values. If your commitment is in euros, a count split may miss it.
6. Keep a fallback. Hyperswitch advises keeping default fallback routing configured, so payments still have a path when no eligible processor is returned.
7. Set the stopping rule now. Decide the sample, the end date and the gap that would change your decision before any data arrives.
8. Plan the next step. Our guide to adding a second PSP covers ramping a provider in stages.

Splits also behave differently from one platform to another, so ask how yours assigns payments.

Behaviour	Example in vendor documentation	Why it matters
Random by weight	Hyperswitch: at 70/30, each payment has a 70% chance of preferring the first processor. Rebilly offers a similar weighted-random mode	Shares drift over small samples and settle over many payments
Fixed counter	APEXX: at 5/15/80, the first 5 transactions in a cycle go to one acquirer, the next 15 to a second and the last 80 to a third	At low volume, a block of payments can fall in one part of the day
Same route on retry	DEUNA stores the path on the order, and Hyperswitch’s test mode keeps a payment in its arm on retries	One customer’s attempts are not spread across both routes

How do you read the result fairly?

Three things distort most comparisons: different customers, different timing and different counting.

Same traffic mix. Primer calls sequential testing, running one provider for months and then the other, a common mistake, because seasonality and other shifts can distort the result. Its recommended method is to split live traffic at random, at the same time. Even then, check the mix. Pagos names customer mix among the reasons two processors diverge, so compare the country, card type, amount and new or returning share on each route. If sticky routing keeps returning customers on the old provider, the new provider receives mostly first-time customers and looks worse for reasons unrelated to its performance.

Same timing. Compare the same days on both routes. A month against the previous month tells you little.

Same counting. Report two rates for each route. First-attempt approval shows how each provider handles payments it receives first. Payment approval shows whether the customer eventually paid. Hyperswitch’s test reporting keeps the two apart as a first-attempt rate and a net rate. Our guide on how to calculate approval rate gives the formulas. Assign each payment to the route that received its first attempt, and keep it there even if it cascades.

Raw provider dashboards hide this, because each provider also receives the other’s declines.

Example figures, for illustration only.

A merchant splits 20,000 card payments evenly. Each provider approves 20% of the payments cascaded to it.

Measure	Provider A first	Provider B first
Payments	10,000	10,000
Approved on first attempt	7,800 (78.0%)	8,000 (80.0%)
Declined, cascaded to the other provider	2,200	2,000
Recovered by the other provider	440	400
Payment approval	8,240 (82.4%)	8,400 (84.0%)

Now look at what each provider’s own dashboard shows. Provider A handled 12,000 attempts and approved 8,200, which is 68.3%. Provider B handled 12,200 and approved 8,440, which is 69.2%. Both figures sit far below what customers experienced, and the gap between them is smaller than the real difference on first attempts. The attempt view is mostly measuring leftovers.

How many payments do you need before you trust the result?

More than most teams expect, and the number grows quickly as the gap shrinks. Primer’s guide says that from a 70% baseline, detecting a rise to 80% takes about 330 payments per variant, while detecting a rise to 71% takes 33,000. A gap ten times smaller needs about 100 times the sample.

Hyperswitch’s test builder has sample presets from 1,000 to 50,000 transactions per arm, with a default of 5,000, and declares significance at p below 0.05. Treat those as one vendor’s settings. Your own requirement depends on your baseline and on the smallest gap that would change your decision.

Example figures, for illustration only. A segment with 60,000 card payments a month, split 50/50, reaches 33,000 per arm in a little over a month. With a 10% share, the smaller arm fills far more slowly and the same question takes much longer, so use a two-proportion calculator with your actual split.

Three rules protect the result. Primer advises analysing a fixed-horizon test only when the planned sample is reached, because checking early raises the risk of a false positive. It also says not to extend a test to wait for a significant result. And it warns that chargebacks can take weeks or months to appear, so keep watching dispute and fraud rates after you have an approval answer.

Approval is not the only measure. Compare cost per approved payment, chargebacks, refunds, latency and settlement timing on each route too. The provider with the highest approval rate may not be the best choice.

What are the common mistakes?

• Comparing before and after. One month on provider A against the next on provider B measures the calendar as much as the provider.
• Reading a small share too early. APEXX warns that with few transactions, a minority acquirer can appear to receive more than its configured share. DEUNA says exact distribution is not guaranteed over a small number of transactions.
• Stopping at the first dip. Primer describes a merchant that ended a test early after a temporary drop in conversion.
• Judging on raw attempts. Cascades add declined traffic to both providers, as the example above shows.
• Giving the routes different fallbacks. If one route cascades and the other does not, payment approval reflects the fallback, not the provider.
• Changing a live rule mid-test. Hyperswitch advises duplicating a split, editing the copy and activating it when ready. Any change restarts your comparison.
• Forgetting provider caps. A larger share can push a provider towards its monthly limit. Our article on provider limits and volume caps covers how to plan for that.
• Using a split to hide disputes. Spreading volume to keep a merchant account under a monitoring threshold hides the problem and puts the acquiring relationship at risk.
• Leaving a test running. Once you have an answer, apply it, then record the date so later reports make sense.

How does Omno handle traffic splitting?

In Omno, a traffic split is a rule your team sets in the dashboard, sharing volume across providers by proportion alongside rules by card BIN, country, currency, amount, browser information or customer segment. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. The transaction trail records every attempt, cascade step and provider response, so first attempts and recovered payments can be reported separately. The smart routing and cascading page shows how the rules fit together.