Do I need a backend for Razorpay integration?
Yes, for a production app. Orders must be created with your key secret on a server, and the payment signature must be verified there. A client-only integration exposes your secret and can be manipulated.
Razorpay checkout wired the way it should be: orders created on your server, payment signature verified before anything is marked paid, webhooks handling the cases the app never sees, and subscriptions that renew without manual work.
UPI · Cards · Netbanking · Wallets · Subscriptions · Payment links
The app asks your backend to create a Razorpay order for a known amount and receipt. The backend returns the order id and key, the Flutter app opens checkout, and Razorpay returns a payment id and signature. The backend verifies that signature with your key secret before marking the order paid.
Skipping server-side verification — or trusting an amount sent from the app — is the most common way Razorpay integrations get exploited.
Users close apps, lose signal and switch devices mid-payment. Razorpay's webhook will still tell you what happened, including failures, refunds and captured payments that the client never reported.
I implement webhook signature validation, idempotent handlers and a status field that the app reads, so the UI always reflects the server's state.
Razorpay subscriptions cover recurring UPI and card mandates. The backend creates the subscription, stores the mandate id, and listens for charged, halted and cancelled events to decide who still has access.
Entitlement is checked server-side on every protected request, not cached forever in the app.
Refunds can be full or partial, and each one needs a record and a customer notification. Settlement reports should reconcile against your own payment table so finance can close the month without exporting CSVs by hand.
For Indian businesses I also wire GST invoice details into the receipt flow.
Explore examples of mobile, Smart TV and integrated product work.
Yes, for a production app. Orders must be created with your key secret on a server, and the payment signature must be verified there. A client-only integration exposes your secret and can be manipulated.
Yes. Recurring mandates are created server-side and the app only handles the authorisation step. Renewals and failures arrive as webhook events.
Yes. That usually means mapping existing plans and mandates, running both providers during a transition and keeping historical payment records intact.
A standard one-time payment flow is usually a few days including testing. Subscriptions, refunds and reconciliation take longer because they touch billing records and reporting.