Is sticky.io's Built-In Cascading and Smart Dunning Enough?

sticky.io's cascade re-presents a declined rebill to a second merchant ID, and Smart Dunning re-times the next attempt. This post separates the declines those two mechanisms fix from the ones they repeat, and names the per-MID measurement sticky.io does not produce.

You already pay for sticky.io. The honest question is not whether cascading and dunning work. It is which declines they work on. A cascade re-presents a declined rebill to a second merchant ID (MID). Smart Dunning picks the date and hour of the next attempt. Both address a decline caused by where the charge was sent. Neither changes what the cardholder's bank decided about the card. This post names what sticky.io genuinely covers. It names what sticky.io leaves unmeasured. It names the decline mix and volume at which keeping what you have is the right answer.

What does sticky.io's cascading actually do when a rebill declines?

It re-presents the same declined transaction to a different gateway. The standard Cascade Profile gives you a single fallback. You set one Initial Cascade Gateway for new orders and one Subscription Cascade Gateway for rebills. Intelligent Cascade is the multi-MID version of the same idea. It allows up to five cascade gateways and five conditions per profile.

The conditions you can route on are the tell. sticky.io's Intelligent Cascade condition list covers billing cycle, bank identification number (BIN), campaign, card type, country and decline reason. The list continues with gateway spend percentage, Kount score, prepaid status, salvage attempt, transaction type, product and payment method. That is 13 conditions. Only one of them touches what the bank said: decline reason. sticky.io matches that reason against decline-reason strings you type in by hand, not against a normalized network response code.

Two details decide what the second attempt is worth. The docs instruct you to remove the card security code (CVV) requirement on any cascade gateway. That makes the fallback attempt structurally weaker than the original. You set the cascade order, and the platform never learns it. Gateways rank by user-defined priority. Traffic moves to the next gateway when the higher-precedence one is maxed out against its monthly cap, not when its approval rate slips.

So the yield is bounded, and sticky.io's own numbers bound it. Its published telehealth case study put cascaded attempts at a 7% approval rate over a year. That splits into 8.8% on credit, 6.5% on debit and 4.5% on prepaid. The codes it reported recovering were the soft ones: call issuer, do not honor, credit floor, processor decline. Solidgate, an independent orchestrator, reports the same magnitude from a different angle. Its cascade recovers about 8% of what the primary acquirer declined. That is 2% to 3% of total volume once you are already above a 90% approval rate. If you run several MIDs, recovering failed rebills across multiple MIDs is the same arithmetic at account level.

What does sticky.io's smart dunning retime, and what does it never retry?

It re-times retries, and that is the whole documented mechanism. Smart Dunning is a managed model. It picks the date and hour of the next attempt on an already declined subscription charge, capped at 1 to 5 retries. You change that cap through your Client Success Manager, not in the interface.

The model reads decline responses, payment provider, product price, consumer behavior, BINs and 50 or more other predictors. The output of all that input is a timestamp. Nothing in the documented output tells you which MID is degrading or why. The article never describes it changing routing, gateway or MID. Re-timing is still worth having. Fixed-interval ladders now draw more declines, because banks read the pattern as brute-forcing. So a timing model beats a static 3, 5 and 7 day cycle. It is one lever, and it is the timing lever. We cover the routing question separately in payment retry strategies.

You define what gets excluded from retrying. Hard Decline Rules are free-text decline reasons you create. sticky.io matches them as substrings against the raw gateway decline text, with a % wildcard. The string has to match what that gateway returns, or the rule does nothing at all. sticky.io ships pre-coded hard decline rules for three providers (Flex Pay, NMI and Fluid Pay). On any other gateway you build the do-not-retry list from scratch. A code you have not typed in keeps cascading and keeps getting retried. Normalized decline reasons only began appearing in March 2026, and only on the Reprocess Declined Orders page.

• The order will not cascade to another gateway.
• The decline will not count against the payment router's gateway decline limit.
• The order cannot be manually reprocessed.
• The order will not go through Decline Manager.

Those four toggles are independent. Set one toggle and not the others, and sticky.io excludes a code from the cascade while still feeding it to dunning retries. The reverse happens too: sticky.io suppresses a code from dunning and still cascades it across MIDs. Decline Manager targeting narrows the coverage further. You get three rules per profile at most, matched with AND logic across campaign, product, decline reason, cart type, gateway and payment method. Its decline-reason options come from your own Hard Decline Rules list. Audit every rule against all four toggles before you trust the configuration.

Which declines does a customer relationship management (CRM) cascade fix, and which ones does it only repeat?

A cascade fixes acquirer-side failures: a gateway that is capped, inactive, or having a bad hour. It repeats issuer-side ones. The card fixes which bank answers, and a second acquirer does not change that answer. Visa's four decline categories sort your own report into those two buckets most cleanly.

Visa's current rules permit up to 20 reattempts in 30 days on Category 2, 3 and 4 declines, and zero after a Category 1 decline. Two things about that ban matter for cascading. Visa writes it against the payment credential, not the merchant ID, so re-presenting to a second MID creates no fresh allowance. The issuer must also keep sending the same Category 1 code once it has sent one. The second attempt therefore gets the same answer. Issuers are trained to block the pattern of a code 43, stolen card, re-presented across three MIDs.

Visa also bars changing the data elements of the original authorization on a reattempt. The forbidden list begins with the Acquiring Identifier, the field that identifies your MID. Read that rule next to a blind MID cascade, and a measured cascade lift deserves a second look rather than a celebration. Visa's rules treat a post-decline resubmission as a continuation of the same transaction, not a fresh stored-credential charge.

Visa categories are from the 18 April 2026 edition of the Visa Rules, and Mastercard advice codes arrive in the authorization response.

Your own decline mix decides how much of this is academic. Across 1,168,245 failed business-to-consumer subscription payments between April 2025 and March 2026, Redux Payments puts insufficient funds at 31.7% of failures and Do Not Honor at 11.3%. That makes 43% of failures balance-shaped or judgment-shaped, and leaves 57% spread across every other shape. Recovery rates in the same dataset diverge: 37.9% for insufficient funds, 21% for Do Not Honor and 5.2% for transaction not allowed. A single blended recovery rate hides which of those three your stack is failing.

How do you tell whether a cascade is helping or eroding issuer trust?

Read four numbers rather than one. Compare gross approval rate next to net approval rate. Track the share of attempts coming back with a do-not-retry advice code. Read the reattempt fee lines on your acquirer statement. Count attempts per card per MID against the network counters. The first pair tells you whether a lift is approval or volume.

Gross approval rate counts every authorization you sent, including the ones that failed. Net approval rate counts whether the order ended up approved, however many attempts it took. Adding a cascade raises the net number. It can lower the gross one on identical traffic. That is why a dashboard reads healthy while a MID degrades behind the retry volume. Adyen puts it plainly. A provider can report a strong acceptance rate while part of that rate comes from retry volume. That retry volume erodes margin in the background.

The second number is the erosion signal, and it already sits in your gateway response. Mastercard's count-based allowances carry exceptions for merchant advice code (MAC) 03, 21 and the timed codes 24 to 30. Ignoring one of those is billable on the next attempt, not on the 36th. The counters themselves are scoped to the card plus the card acceptor ID. A cascade to MID 2 therefore starts a fresh 10-declines-in-24-hours count instead of reducing the underlying attempts. The fee is $0.50 per excess declined authorization in the US, triggered past 10 in 24 hours or 35 in 30 days. A rising share of attempts carrying MAC 03 or 21 is the clearest sign that the cascade now spends issuer trust.

• Read gross approval rate next to net approval rate each week, because a cascade raises the net number and can lower the gross one on identical traffic.
• Track the share of attempts returning Mastercard advice code 03 or 21, since a resubmission inside 30 days of either carries a fee and sits outside the count-based allowance.
• Pull the reattempt fee lines off the acquirer statement, $0.10 per attempt domestically and $0.25 cross-border as of 25 April 2026, because those charges do not appear in the CRM.
• Count attempts per card per MID against Mastercard's 10 in 24 hours and 35 in 30 days, where each excess declined authorization costs $0.50 in the US.
• Ask your acquirer in writing whether it enforces 15 reattempts in 30 days or Visa's current 20, then set your cascade and dunning ceiling to the lower number.
• Check that every hard decline rule suppresses all four subsystems you intended, because cascade, gateway decline limit, reprocess and Decline Manager toggle independently.
• Compare approval rate by gateway profile and by decline code week over week, and note which first-attempt declines the second MID actually approved.
• Request your monthly VAMP ratio from the acquirer, since 150bps with 1,500 counted events is the Excessive Merchant line and no CRM report computes it.

What does sticky.io not show you at the MID level?

It does not show you attribution. No documented mapping connects its decline text to Visa response categories or Mastercard advice codes. It shows you a good deal otherwise. You get decline reasons broken down by gateway ID. You get a Gateway Health report built around volume share and remaining cap space. You get an Original Declines by Gateway panel that compares original gateways against cascade gateways.

The automatic safeguards have the same shape. The Gateway Decline Limit counts consecutive declines during initial order processing, and a single approval resets it to zero. So it never benches a MID whose rebill approval rate is sliding but which still approves intermittently. Round robin load balancing distributes volume regardless of the result from the gateway. Preserve Gateway pins a subscription to the gateway that first approved it. A declining MID therefore keeps receiving the same subscriber until someone removes the preservation. Strict Preservation queues rebills as non-billable when the preserved gateway is capped. That state looks like neither a decline nor a recovery in decline reporting. You need a different cross-tab: approval rate by gateway and by decline code, week over week. We cover it in rebill approval rates.

When does a separate approval-rate layer pay for itself, and when should you keep what you have?

Keep what you have in three cases. First: your declines are mostly stale credentials and Account Updater runs on your gateway. Second: your failed payments sit under 2,000 a month, so no lift is provable. Third: your cascade already excludes hard declines and you review it weekly. Add a layer when you route across several MIDs and want issuer-level routing.

Start with the credential class, because sticky.io already covers it. Its Account Updater queries the card association servers a few days before recurrence. It handles expiry changes, new account numbers and closed accounts across Visa, Mastercard, Amex and Discover. The same docs name the limits. It does not validate that returned values are correct. Only two response codes produce an update. An order returning ACL (account closed) or CCH (contact cardholder) becomes permanently ineligible. It is incompatible with tokenized gateways, including Affirm, PayPal, and Stripe when Stripe tokens are passed. If your declines are mostly Visa Category 3 revalidation codes and you send raw card data, turn Account Updater on. That costs less than buying a routing layer.

A separate layer adds attribution and issuer-level choice. In Yuno's 12 controlled payment configuration tests, routing by the cardholder's issuer country delivered 2 to 5 percentage points of approval rate. That route sent each payment to the provider with the strongest issuer relationship. It was the highest-impact variable tested. Blind percentage rotation across providers produced noise rather than lift. That is the difference between choosing a next MID and choosing the right MID for that BIN. Network tokens sit in the same bucket. Visa reports a 4.6% authorization lift on tokenized card-not-present transactions versus raw card numbers (PANs), and Mastercard reports 2.1%. sticky.io's 2026 release notes show no network-token capability. A real layer also logs why a BIN went to a given acquirer and what approval it predicted. A cascade does not.

Then price it against your own failed volume. Standalone orchestration and approval-rate platforms run $0.01 to $0.10 per transaction, or 0.5 to 5 basis points of volume. Platform fees run $2,000 to $15,000 a month for simpler multi-provider setups. Card-not-present authorization rates run 85% to 92%, so the recoverable gap is single digits of percentage points. The layer has to beat the cascade you already own, net of its own cost.

Take one case. Northfield Supply bills 38,000 renewals a month through sticky.io across four MIDs. Assume 8% of renewals fail and the average renewal is $49. That is 3,040 failed renewals and $148,960 of failed volume a month. At the published 8% cascade yield, the cascade returns about $11,900 of that. A layer priced at $2,000 a month plus $0.01 per transaction costs $2,380. It has to lift recovery by 1.6 points of failed volume to break even. At 3,040 failed payments a month, Northfield has the volume to measure whether it did. The 8% failure rate and the $49 renewal are assumptions. The 8% cascade yield and the price points are published figures.

How do you measure the lift before and after you add one?

You do not measure it with a before-and-after read. Split live failed payments at random into two arms: a control arm on your current logic and a treatment arm on the new one. Run both at the same time. Fix the sample size before you look. Seasonality and billing-cycle timing move recovery enough to swamp a 2-point difference on their own.

1. Strip the codes nothing re-routes out of the denominator first, including Visa Category 1 codes and the non-retryable list Stripe publishes: incorrect number, lost card, pickup card, stolen card, revocation of authorization, authentication required, highest risk level and transaction not allowed.
2. Run an A/A phase, where both arms get identical treatment, and only trust a later lift if the two arms recovered at the same rate during it.
3. Randomize at the invoice or subscription level upstream of the first retry, so the same card cannot land in both arms and the split cannot sort by MID, plan price or billing day.
4. Set the window longer than the retry tail: Stripe's recommended default is 8 tries within 2 weeks, and Visa requires you to notify the cardholder in writing and allow at least 7 calendar days to pay by other means after a declined stored-credential charge.
5. Hold Account Updater and token enrollment constant across both arms, because a card-updater batch landing mid-test moves approval rates by itself.
6. Carry chargeback and refund rate next to approval rate in the same read, so a retry-driven lift that buys disputes shows up rather than hiding.
7. Net the per-attempt fees out of incremental recovered revenue before you report anything, and report a confidence interval rather than a recovery percentage on its own.

Volume decides whether any of this resolves. Detecting a 10% lift at p below 0.05 takes 2,000 to 5,000 failed payments a month. Primer's arithmetic shows why the threshold moves so fast. Lifting a 70% conversion rate to 80% needs 330 payments per variant. Moving it from 70% to 71% needs 33,000 per variant. Checkout.com runs each optimization against a permanently withheld control group rather than a pre and post baseline. It reports a portfolio-average 3.8 percentage points of acceptance rate. Ask any vendor for that shape of claim. Compare it against sticky.io's own marketing figures: up to 75% of declined transactions recovered and 40% or more first-attempt approvals. sticky.io states those as potentials and names no control group.

One more trap sits in the window itself. A recovery rate measured on the month you switched something on compares a finished cohort against an unfinished one. That month's retries are still running. Stripe's analytics carry an in-recovery bucket for exactly that reason. Its recovery rate counts volume recovered by any means, including the customer paying on their own. Set the baseline before you change anything, and split it by decline code and MID. That is the measurement half of failed payment recovery. Then read the result one full retry tail after the switch, not on the 7th day.

Frequently Asked Questions

Does sticky.io cascading improve approval rates?

It improves them on one slice of declines. A cascade re-presents the declined charge to another MID, which helps when the first gateway was capped, inactive or having a bad hour. Published figures put cascade yield at about 8% of what the primary acquirer declined, or 2% to 3% of total volume above a 90% approval rate.

What is the difference between sticky.io cascading and smart dunning?

Cascading changes where the retry goes, and Smart Dunning changes when it goes. The cascade re-presents the same declined transaction to a second gateway you designate. Smart Dunning picks the date and hour of the next attempt, capped at 1 to 5 retries, and the documented mechanism does not choose which MID the retry lands on.

How many times does sticky.io retry a failed payment?

It depends which engine is running. Decline Manager allows anywhere from no retries up to 10 attempts before the subscription goes on hold, on daily, weekly, monthly or custom schedules. Smart Dunning is capped at 1 to 5 retries per transaction, and changing that cap goes through a sticky.io Client Success Manager.

Can you retry a hard decline on a different MID?

No, and the first retry is the violation rather than the 21st. Visa bars any reattempt after a Category 1 decline, and the ban is written against the payment credential rather than the merchant ID. The issuer is also required to keep returning the same code, so the second MID receives the identical answer.

Does sticky.io show approval rate by MID?

It shows gateway-level views rather than attributed per-MID measurement. Gateway Health reports volume share and remaining cap space, the Decline Reasons report breaks declines down by gateway ID, and the Intelligent Cascade dashboard compares original against cascade gateways. None of those maps the decline text to Visa response categories or Mastercard advice codes.

Do I need payment orchestration if I already use sticky.io?

Not if your declines are credential-shaped and your failed payments run under roughly 2,000 a month, since below that volume a 10% lift cannot be shown at p below 0.05. Consider a separate layer when you route across several MIDs and want issuer-level routing, which tested at 2 to 5 percentage points of approval rate.