The router that argues back.
Every transaction is weighed against a named, versioned rule set — card brand, BIN, EMI, amount, currency, even custom merchant fields — before it ever reaches a gateway. Ties aren't broken by a coin flip; they're broken by live, Bayesian success-rate data.
One rule set decides where every rupee goes
A capability pre-filter runs behind every rule: a matched rule whose gateways can't actually process the transaction's method or currency cascades to the next rule instead of dead-ending.
currency != INR
→
RANK Stripe (SR-based) → CCAvenue → Razorpay
is_emi = true
→
RANK PayU (SR-based) → Razorpay → HDFC PG
method_type = UPI and amount ≤ ₹10,000
→
RANK Razorpay (SR-based) → PayU
card_brand = RUPAY
→
RANK Razorpay (SR-based) → BillDesk → Atom PG
amount > ₹50,000
→
RANK HDFC PG (SR-based) → Razorpay → ICICI PG
Rank, split, or hybrid — per rule
Every rule, and the default fallback, independently picks how its eligible gateways are chosen.
- 1StripeSR-based97%
- 2CCAvenue91%
- 3Razorpay96%
Declared priority order, with a working circuit breaker: if Stripe's live success rate drops below 70%, it's skipped in favor of the next healthy option — no rule edit required.
Every slice here is SR-based — Xirag doesn't just honor the configured percentage, it multiplies each slice by that gateway's posterior-mean success rate relative to the pool average, so a degrading gateway sheds volume automatically.
A fixed slice can cover a contractual minimum-volume commitment; whatever traffic remains is resolved by one Thompson-sampling draw from each SR-based gateway's Beta posterior each transaction.
Success rate is a posterior, not a snapshot
Every gateway's routing weight is a Beta distribution — narrowing and shifting as real outcomes arrive, never a single static percentage.
- Prior. Each gateway's static success rate from the capability registry seeds a 20-observation-strength Beta prior — a brand-new gateway starts at its declared SR, not zero.
- Live window. A 15-minute rolling window of real outcomes updates the posterior; fewer than 10 observations in that window and Xirag falls back to the prior rather than trusting noise.
- Per-method learning. Success rate is tracked per gateway × payment method — a PG can be excellent at UPI and mediocre at cards — falling back to the gateway's global window, then the prior, in that order.
- Circuit breaker. A gateway is marked degraded below 70% live success rate and is skipped in Rank mode while a healthier option exists.
Nobody ships a routing change alone
A Priority Logic that misroutes traffic is a production incident — so creating and activating one is deliberately not a single-click action.
Every Priority Logic is versioned, and a delete only moves it to a recycling bin — retention configurable per merchant, or kept forever — nothing is destroyed outright.
47 gateways profiled in the capability registry
Onboard the processors your business already trusts — the routing engine treats every one of them as an interchangeable, rankable pool member.
| Gateway | Best for | Success rate (prior) | Status |
|---|---|---|---|
| RPRazorpay | UPI · Card · EMI | Healthy | |
| STStripe | Card · Wallet (international) | Healthy | |
| JPJuspay | UPI · Card · EMI | Healthy | |
| CACAMSPay | Netbanking · UPI · Card (hosted redirect) | Healthy | |
| PUPayU | Netbanking · Wallet · EMI | Healthy | |
| HDHDFC PG | Card · UPI · EMI | Healthy | |
| ICICICI PG | Card · UPI · EMI | Healthy | |
| CCCCAvenue | Card · UPI · Netbanking (GCC) | Healthy | |
| + 39 more gateways in the capability registry — BillDesk, Atom PG, Adyen, PayPal, Cashfree, PhonePe… | |||
The rest of the orchestration layer
Every Priority Logic's performance is automatically compared against whichever one was live immediately before it.
One API call — amount, currency, description — returns a link or a hosted checkout session.
Builds and signs the gateway's redirect envelope; card data transits in memory only, never persisted.
Credentials are sealed with AES-256-GCM at rest, never resolved to a real adapter without an active config.
Every charge and refund call is idempotency-keyed, so a retried request can never double-charge.
Every webhook is signature-verified before it's trusted; a Re-Query call resolves status even if a webhook never arrives.