Stripe vs Razorpay for SaaS Subscriptions in India

The Reserve Bank of India (RBI) sets specific rules for recurring payments to protect customers from unauthorized charges. They apply to any subscription product that collects money from Indian customers, whichever gateway you use.

• Card e-mandates. The customer registers a mandate on the first payment with additional authentication, such as an OTP. The card issuer sends a pre-debit notification before each charge, and the customer can view or cancel the mandate. Charges above an RBI-set threshold need fresh authentication each time.
• Issuer support varies. Not every Indian card supports e-mandates, so some customers will fail at sign-up. Offer another method.
• UPI AutoPay. The customer approves a recurring mandate in their UPI app with their UPI PIN. Later debits run automatically after a pre-debit notification, and the customer can pause or revoke the mandate in the app. Debits above a set limit need the PIN again.
• Bank mandates (eNACH). Authorized through net banking or a debit card, suited to larger or B2B amounts. Registration takes longer than cards or UPI.
• No stored card numbers. Under RBI rules, merchants cannot store full card details. Saved cards work through tokens managed by the gateway and card networks.

Expect some renewals to fail that would succeed elsewhere. Build retries, reminder emails and an easy way to update the payment method. Thresholds and rules have changed over time, so confirm the current details with your gateway before launch.

If you sell to customers in the US, UK, Europe, Australia or the Middle East, Stripe is usually the easier fit. It handles many currencies, international cards and wallets, 3D Secure where required, and the self-serve billing international buyers expect, such as plan changes and downloadable invoices.

Razorpay can accept international cards once that is enabled on your account, but its strengths are Indian payment methods. Either way, an Indian business receiving money from abroad has foreign exchange documentation to handle; ask your gateway and your accountant what they need.

Some products use both: Razorpay for customers paying in rupees, Stripe for everyone else, selected by billing country at checkout. That doubles the integration and testing work, so do it only when both customer groups matter to revenue.

Both platforms generate invoices and receipts. Stripe offers invoicing and a tax product that calculates sales tax, VAT and GST in many countries; check that it covers your obligations. Razorpay's invoicing supports GST details for Indian businesses. Neither replaces an accountant: confirm that invoice formats, tax registration numbers and place-of-supply rules match what you owe, and keep your own record of every invoice in your database.

Stripe's documentation, typed SDKs and CLI are mature. The CLI forwards test events to your local machine, which speeds up subscription work. Razorpay has solid documentation, SDKs for the major server languages and a test mode with test cards and UPI flows.

With either provider, webhooks are the source of truth for subscription state. A browser redirect after checkout can be closed or faked; a webhook is signed by the provider.

• Verify signatures. Stripe signs events in the Stripe-Signature header, Razorpay in X-Razorpay-Signature. Verify against the raw request body with your webhook secret before parsing.
• Make handlers idempotent. Both providers retry failed deliveries, so store processed event IDs and skip repeats.
• Expect any order. Events can arrive out of order; fetch the current subscription from the API when in doubt.
• Respond quickly. Return a 2xx status fast and do slow work in a background queue.
• Map events to access. Stripe's invoice.paid and customer.subscription.updated, or Razorpay's subscription.charged and subscription.halted, should update the plan and limits in your database.

Every StackWise Product Build includes Stripe or Razorpay payments and subscriptions; starting prices are on the pricing page. The integration has the same shape with either provider:

1. 1Hosted checkout or the provider's payment fields, so card data never touches your servers and PCI DSS scope stays small.
2. 2Customer and subscription IDs stored on the account or tenant record, never card details.
3. 3Signed, idempotent webhook handlers that update plans, seats and limits.
4. 4A billing page for upgrades, downgrades, cancellations and payment-method updates.
5. 5Test-mode runs of renewals, failed payments and cancellations before launch.

If your product has organizations or teams, billing should attach to the tenant; the multi-tenant SaaS architecture guide explains why. See SaaS development for the rest of the build.