For an Indian SaaS business, begin with merchant eligibility and the customers' required payment methods. Stripe's current India documentation says new access is invite-only, so it cannot be treated as an immediately available default. Razorpay is a practical candidate for domestic collections, but payment methods and recurring billing still need account-specific confirmation before you design the checkout.
Resolve merchant access first
Last verified: October 2026. India's onboarding policies and account capabilities can change; confirm them directly before committing engineering work.
Stripe's India international payments guide states that Indian businesses must request an invitation rather than create a new account through ordinary website signup. It describes support for a selected set of businesses, with a focus on international expansion.
This is an access constraint, not a judgment about the quality of the API. A successful test integration does not establish that your legal entity can collect live payments. Obtain confirmation for the entity, business category, and intended flow.
For Razorpay, inspect the live account's enabled methods and required approvals. Its payment methods documentation distinguishes methods available in Checkout from those requiring approval or additional integration. A broad product page does not prove that every capability is active for your account.
Record the merchant entity, settlement bank account, expected customer locations, currencies, and whether you collect your own revenue or route money to third parties. Marketplace payments are a different requirement from selling a subscription to your own software.
Separate domestic payments from exports
A domestic-first product may prioritize UPI, cards, and netbanking. Razorpay documents these methods, making it a candidate worth evaluating against the intended customer journey. Validate the supported flow on the devices and apps your customers use.
An export-focused SaaS business must consider more than a customer paying in a foreign currency. Provider onboarding, permitted transaction types, required customer information, and settlement behavior can affect the application design.
Stripe's India export guide describes additional onboarding and transaction information, including business and export details. For example, the integration may need customer address and service-description information that a minimal email-only checkout never collected. Use the provider's current requirements rather than copying a checkout built for a different country.
Do not assume that a feature shown for another Stripe or Razorpay merchant country is available to an Indian account. Ask the provider to confirm your complete scenario, including currency, payment method, billing model, and settlement requirements.
Treat recurring billing as a separate integration
A successful one-time payment does not prove that a later automatic debit will succeed. Mandates, customer authentication, issuer support, notifications, and payment state all affect recurring collections.
Stripe's India recurring payments guide explains its mandate and authentication behavior. Design for processing delays and customer action instead of assuming every renewal is an immediate card charge. Method-specific details and thresholds should be checked in the current documentation.
Razorpay's Subscriptions guide documents recurring plans and supported methods including cards, UPI AutoPay, and e-mandates. It also distinguishes fixed subscription schedules from other recurring-payment use cases. Confirm the supported method and flow for the account you will deploy.
For either provider, define product behavior when a renewal is pending, fails, requires authentication, or is canceled. Decide whether access continues during a grace period and how the customer recovers. Those are product decisions, not defaults to infer from a provider status name.
Last verified: October 2026. Recurring-payment support, method limits, and account policies change. This article intentionally avoids quoting a universal mandate threshold because your method and provider flow determine the applicable behavior.
Compare the actual decision points
| Decision | Stripe evaluation | Razorpay evaluation |
|---|---|---|
| Indian merchant onboarding | Confirm invitation and live-account eligibility | Confirm activation and required capabilities |
| Domestic collections | Verify account-specific payment methods | Test required UPI, card, and netbanking flows |
| Export revenue | Validate India export requirements | Confirm international activation and required flow |
| Subscription renewal | Test mandates, customer action, and pending states | Test the chosen recurring method and lifecycle |
| Financial operations | Reconcile local records to provider reports | Reconcile local records to provider reports |
Last verified: October 2026. This table is a due-diligence framework, not a promise of approval or feature parity. Provider policies and enabled account capabilities can change.
Build an internal billing model
Keep a local customer, subscription, invoice, and payment-attempt model appropriate to the product. Store provider identifiers as references. Avoid making a provider's object structure the only definition of your business state.
Your server should determine the product, amount, currency, and owning organization. The browser should not be able to invent an amount and ask the backend to mark it paid. A checkout success screen is a user interface signal, not sufficient evidence to grant permanent access.
Verify payment state through the provider's supported server flow and authenticated webhooks. Persist events, deduplicate them, and tolerate reordering. Use the webhook design guide for that implementation, and background jobs for deferred work.
Keep payment collection and subscription entitlements connected through explicit rules. If a refund is issued, decide whether access changes immediately or at the end of a period. If an invoice remains unpaid, decide which features are restricted and what data remains accessible.
Compare total cost with your payment mix
Last verified: October 2026. The relevant pricing pages are Stripe India pricing and Razorpay pricing. Rates, taxes, negotiated terms, and enabled products can change. Obtain account-specific terms in INR and confirm any foreign-currency components before budgeting.
Build a worksheet with domestic and international volume, average transaction value, recurring billing charges, currency conversion, refunds, disputes, and settlement-related services. Include engineering and finance effort where the workflows differ.
Do not infer that every UPI-related commercial service is free from a general statement about a payment rail. Identify the product being billed and the actual agreement. Likewise, a headline processing rate may not include every billing or cross-border charge relevant to a SaaS subscription.
Use estimates clearly labeled as scenarios. The useful comparison is the expected monthly cost and operational burden under your payment mix, rather than the lowest percentage visible on a marketing page.
Validate before committing the launch date
Test checkout success, abandonment, duplicate callbacks, delayed notifications, failed renewals, refunds, and reconciliation. Check that support can identify a payment without asking a customer for sensitive card information.
Confirm live eligibility and required methods early. Then choose the provider whose verified capabilities fit the product and whose failure paths your team can operate. These are engineering considerations; obtain qualified advice for legal, tax, or regulatory decisions affecting your business.
For the rest of the product boundary, see SaaS MVP architecture.