16
5 Comments

Razorpay merchants can now recover failed subscription payments automatically. we just shipped it.

Most recovery tools were built for Stripe. If you're on Razorpay, you've been watching features that don't apply to you. UPI doesn't exist in those tools. Razorpay's error codes aren't mapped. The retry logic doesn't account for how Razorpay handles halted subscriptions.

So we built the thing that actually works for Razorpay.

Recurflux now connects to Razorpay. When a subscription payment fails, we catch it, classify it, and retry it at the right time. Expired card, insufficient funds, OTP timeout, bank network error, each one gets treated differently because they recover differently.

If retries don't work, here's the part that's specific to India.

We create a Razorpay payment link with UPI enabled and send the customer a recovery email. They tap it, pay through GPay, PhonePe, Paytm, whichever they use, and the subscription continues. No card required. The link stays open for 7 days. We handle the email ourselves so the copy and timing are actually good.

That's the thing no Stripe-native tool gives you. UPI as a recovery path is real in India in a way it isn't anywhere else, and we built around that.

Building this honestly took longer than we planned. Razorpay's webhook payload structure is different from every other processor we've integrated. Their SDK is missing the charge method for subscriptions entirely, so we had to call the raw endpoint directly. Subscription state has to be checked before every retry attempt because their halted state doesn't behave the way you'd expect. We mapped around 50 error codes to build the classifier.

None of it was impossible. It was just a lot of surface area that isn't documented anywhere obvious.

if you're on Razorpay and you've never looked at how many subscription payments are failing silently each month, that's probably the most useful thing you can do in the next 10 minutes. open your dashboard, filter by failed payments in the last 30 days, add them up.

when you're ready to do something about it, connecting Razorpay to Recurflux takes about 10 minutes and requires no code.

recurflux.com

still finding edges in Razorpay's API. if you've built on it and hit things i didn't mention, i'd genuinely like to hear from you.

posted toAvatar for product Recurflux
Recurflux
  1. 2

    The UPI as a recovery path detail is the one that makes this genuinely different from a generic payment recovery story. Building around how payment behaviour actually works in India rather than mapping Stripe assumptions onto a different market is the right architecture decision and it shows in the 50 error codes you had to map yourself. The halted state behaviour you mentioned is exactly the kind of thing that looks documented until you're actually building against it. We talked earlier about how you handle ambiguous failure codes curious whether any of those 50 ended up harder to classify than expected, or whether the Razorpay-specific ones were mostly predictable once you found the patterns.

    1. 1

      love how you framed that.
      yeah, treating UPI as a first class recovery path instead of an afterthought changed a lot of our early assumptions. once we stopped narrowing our thinking in stripe brain and started from actual indian payment flows, the architecture almost redesigned itself. it is important for us to not let a single market be left served, as we are not a company built in the flow of saas era,we are serious about what we make.
      on the error codes side, a bunch of the obvious ones behaved as expected, but there were definitely some weird edge cases. a few razorpay specific codes looked similar on the surface, but the right action was totally different once we correlated them with webhook timing and bank responses. after we grouped them by underlying cause instead of just message text, patterns started to appear and classification got a lot more predictable
      the “halted” style states were the trickiest, because they sit in that uncomfortable middle zone where you can’t tell if you should wait, retry, or mark it as a hard fail from a recovery perspective. we ended up building more conservative rules there and leaning on extra context before triggering retries
      would actually love to compare notes on how you think about modelling those limbo states in your own integrations sometime


  2. 1

    A CRYPTO/DATA BASE RECOVERY EXPERT WITH A LICENSE: ALPHA KEY

    After contacting Alpha Key Recovery, a licensed cryptocurrency recovery expert, about my case, I was able to get back on track after a month of being depressed over being conned out of $379,800 in cryptocurrency investments with the wrong broker. Alpha Key Recovery Hacker Expert is a recovery hacker that I will be proud to refer anyone to because of what I have seen out here with scammers.

    WhatsApp : +15714122170

    Signal : +15403249396

  3. 1

    ¡Felicidades por las mejoras de seguridad! Implementar parches sin interrumpir la experiencia del usuario siempre es un equilibrio delicado. Como desarrolladora que construye codebases de SaaS, sé lo fácil que es que algo se rompa durante estas actualizaciones. ¿Tuvieron que hacer pruebas de regresión exhaustivas para este despliegue?

    1. 1

      thanks, totally agree, that balance is the hardest part

      we did run a pretty solid regression pass before the rollout, especially around the flows most likely to be affected by the patch. the goal was to improve security without creating any friction for users, so we were extra careful with testing and rollout timing

      honestly, the tricky part is never just the patch itself, it’s making sure nothing else in the surrounding flow gets impacted. that’s where the extra checks really matter