Routing A/B Tests
A/B tests let you compare the performance of different PSP connections under real traffic. Instead of guessing which provider is best for a region or payment method, you can run a controlled experiment and let the data decide.A/B Tests are an advanced feature for optimizing your payment stack. Use them when you have multiple connections for the same region and want to find the highest-performing option.
π― When to Use A/B Tests
| Use Case | Why A/B Tests Help |
|---|---|
| Selecting a new provider | Test a new PSP alongside your current one to compare success rates before fully switching. |
| Optimizing by region | Compare Paystack vs. Hubtel for Ghana mobile money payments. |
| Fee comparison | Determine if a slightly more expensive provider has better success rates that offset its cost. |
βοΈ How It Works
- Create an Experiment: Define at least two
variants, each pointing to a differentconnection_idwith aweight(traffic allocation). - Set Targeting: Optionally limit the experiment to specific currencies, countries, or payment methods.
- Start the Test: Activate the experiment. Reevitβs router will split traffic according to your weights.
- Analyze Results: View real-time success rates, latency, and costs per variant.
- Declare a Winner: Complete the test and apply the winning connection to a permanent routing rule.
π οΈ Creating an A/B Test
Via SDK
π Field Reference
| Field | Type | Required | Description |
|---|---|---|---|
name | string | β | A descriptive name for the experiment. |
description | string | Explain the purpose of the test. | |
variants | array | β | At least two objects, each with connection_id (string) and weight (integer percentage). |
traffic_percentage | integer | Percentage of eligible traffic (1-100) to route through the test. Default: 100. | |
target_currencies | string[] | Limit test to specific currencies (e.g., ["GHS"]). | |
target_countries | string[] | Limit test to specific country codes (e.g., ["GH", "NG"]). | |
target_methods | string[] | Limit test to specific methods (e.g., ["card", "mobile_money"]). | |
start_at | string | ISO 8601 timestamp to automatically start the test. | |
end_at | string | ISO 8601 timestamp to automatically complete the test. |
π Test Lifecycle
| Status | Description |
|---|---|
draft | Test is created but not yet active. Traffic is not being routed. |
running | Test is live. Traffic is being split among variants. |
paused | Test is temporarily stopped. Traffic reverts to default routing. |
completed | Test is finished. Results are frozen for analysis. |
Managing the Lifecycle
π Analyzing Results
Fetch the comparison report:β Best Practices
- Sufficient Volume: Run tests long enough to gather statistically significant data (usually 1,000+ transactions per variant).
- One Variable at a Time: Only compare connections; donβt change targeting rules mid-experiment.
- Start with Low Traffic: Use
traffic_percentageto initially test with 10-20% of traffic, then scale up. - Apply Learnings: After completing a test, create a Routing Rule to make the winning connection your primary.
π Related Resources
Smart Routing
Apply your test results as permanent routing rules.
Connections
Manage the PSP accounts youβre comparing.
Payments
See how individual payments are attributed to test variants.

