On Stripe, a failed payment can be retried by two systems at once: Stripe's own native retries, which run automatically for Billing subscriptions, and an outside recovery tool's schedule. Each engine counts its own attempts. Neither, by default, counts the other's. The customer experiences the sum — and the sum can be a card hammered twice as often as either system intended.
The fix is a shared budget. Swipe Again weaves its attempts into the gaps of Stripe's native schedule and holds both under one combined ceiling of fifteen total attempts. The weave reads the live state before acting: if a native attempt is due within about a day, ours defers — unburned, not wasted. If the native plan is light, ours extends to fill the space. If Stripe is exhausted, the full plan runs. Insufficient-funds failures ride their payday ladder regardless, because their constraint is the calendar, not the count.
What merchants should take from this is a question to ask any recovery tool, including us: do you coordinate with the platform's own retries, or do you stack on top of them? Stacking is easier to build and worse in every way that matters — more fees, more issuer friction, more annoyed customers. The Stripe recovery page describes the weave in plain terms; the short version is that two engines sharing one ceiling behave like one engine with better information.
Top comments (0)