React Native and Flutter Payment Gateways in India: OTP Assist, Headless UPI and SDK Support

React Native and Flutter payment gateways connect mobile apps to payment processing through framework plugins and native Android or iOS SDKs. Razorpay provides official integrations for both frameworks, with separate Standard and Custom Checkout packages. Advanced features such as Native OTP and embedded UPI have their own platform requirements.

If your team is replacing a browser checkout, which SDK supports your required payment methods, OTP assistance and in-app UPI journey? An official package is the starting point; the feature-specific documentation determines what you can implement on each operating system.

Check three things separately: who controls the checkout interface, where authentication happens and whether payment approval switches to another app. A custom interface does not automatically remove a bank-page redirect or UPI app switch.

This guide uses Razorpay Payment Gateway documentation and dated publisher records to explain SDK maintenance, Native OTP, headless UPI and the integration checks to complete before launch.

Which React Native and Flutter Payment SDKs Does Razorpay Officially Support?

Razorpay provides official React Native and Flutter payment integrations for Android and iOS. Each framework has Standard and Custom Checkout options. Use the package and feature guide that matches your chosen flow, then verify its release record and native dependencies before implementation.

Standard Checkout and Custom Checkout Solve Different UI Requirements

Standard and Custom are not styling preferences. They are separate packages with separate repositories, version numbers and release histories.

Review the React Native Standard Checkout documentation, the React Native Custom SDK documentation, the Flutter Standard Checkout documentation and the Flutter Custom SDK documentation. Official documentation recommends Standard for the managed React Native flow; Custom payment methods require their own implementation.

One ownership check is worth two minutes. On pub.dev, the razorpay.com verified publisher page lists the packages published under the verified publisher identity. On npm, check the publisher account and the linked repository. A package name that contains a brand is not the same as a package published by that brand.

What Recent SDK Updates Actually Prove

Release evidence checked 28 October 2026. Registry publication dates and documentation entries are labelled separately below.

A published package, a repository release, a commit and a documentation version table are different evidence types. Use the registry publication record to establish when a package was published and the relevant changelog to identify its changes. A newer Custom package publication does not update the Standard package, and an older documentation table may not list the newest registry version.

DID YOU KNOW: Standard and Custom SDKs can share a framework while following different release histories. The newest version number from one track does not describe the other.

PRO-TIP: Add package version, resolved Android/iOS dependency, framework version and successful test-build date to your release checklist.

How Does Native OTP Assist Work on Android and iOS?

Native OTP keeps eligible card authentication within the checkout experience instead of always opening the bank’s OTP page. Automatic OTP reading and submission are different capabilities. Razorpay documents native iOS Custom Checkout support, while automatic OTP handling must be checked against the relevant Android integration, customer consent and supported card flow.

Separate Native OTP, Auto-Fill and Auto-Submit

Native OTP is a card feature. It does not replace a UPI PIN, and it is not the same thing as Turbo UPI account onboarding. Nor does it apply to every bank or every card.

Android OTP Assistance and the iOS Native OTP Path

Razorpay documents Native OTP for supported card flows, including a native iOS Custom Checkout integration. The iOS guide checks card eligibility and retains a bank-page fallback. Automatic OTP reading and submission are separate capabilities: verify the Android SDK integration and customer consent requirements, then confirm which capabilities your Flutter or React Native wrapper exposes.

The Optimizer Native OTP documentation describes authentication without redirection to the issuing bank’s ACS page. In that product context, auto-read, auto-fill and auto-submit are additional features for merchants using the Android SDK for Standard Checkout. Separately, Google’s SMS Retriever and SMS User Consent API reference explains that these APIs can retrieve the relevant SMS without requesting READ_SMS or RECEIVE_SMS. These platform APIs do not establish which features a particular Razorpay wrapper exposes.

On the native Android side, the Android Custom Native OTP integration guide states that the feature is available from Android Custom SDK version 3.9.3 and above, that eligibility is gated on the card BIN, and that the flow exists to prevent redirection to the issuing bank’s ACS page. See OTP Assist activation guidance for the activation paths by integration type.

In the native iOS Custom flow, check card eligibility before requesting an OTP. Support the documented submit, resend and cancel actions, and retain bank authentication for ineligible cards or transactions.

Why Manual Entry and Bank-Page Fallback Still Matter

A declined permission, an unsupported card or a failed authentication step all need a recoverable customer experience. Design the OTP screen so manual entry is always reachable, and so a fallback to the bank page is a normal outcome rather than an error state.

Confirm that your selected Flutter or React Native integration exposes the required native feature before implementation. Native OTP support does not establish automatic SMS reading or submission on iOS.

DID YOU KNOW: A native OTP screen and automatic OTP submission are separate capabilities. Supporting the first on iOS does not establish support for the second.

What Is Headless UPI, and How Is It Different From UPI Intent?

Headless UPI separates the merchant’s interface from the payment integration, but the term alone does not guarantee that the customer remains in the merchant app. UPI intent can open a separate UPI app. Razorpay Turbo UPI provides an embedded UPI option, with feature-specific SDK prerequisites and account activation.

Custom UI Does Not Decide Where UPI Authentication Happens

Three separate questions sit behind the word headless. Who draws the merchant interface? Which app handles authorisation? Which exact framework and operating-system integration is documented for that flow?

A custom checkout lets you control the merchant-facing interface; UPI intent can still open a separate UPI app for approval. Razorpay Turbo UPI is the documented embedded UPI option. Its Flutter headless integration uses a specific SDK setup and onboarding process, rather than an undocumented shortcut inside the Standard Checkout package. Confirm the available React Native integration path before committing to a headless design.

The React Native Custom SDK documentation directs affected UPI Collect integrations to UPI Intent or UPI QR. Its notice lists exemptions for MCC 6012/6211, iOS mobile app and mobile web transactions, existing mandate execute/modify/revoke operations, eRupi vouchers and PACB businesses. Check the migration guidance against your platform and business category. A UPI intent payment can still switch apps; the UPI payment methods guide identifies Turbo UPI as the embedded alternative.

Flutter Turbo UPI Headless: Verified Scope and Prerequisites

Razorpay’s general Flutter payment plugin wraps native Android and iOS SDKs. The separate Flutter Turbo UPI headless integration guide currently supports Android and describes iOS support as under development. It requires the Flutter Custom integration, approved access to the relevant native libraries and the specified Turbo, SecureComponent and bank dependencies. Plan the supported integration for each operating system rather than assuming that the general plugin exposes every advanced feature.

The Flutter Turbo UPI documentation adds operational conditions that belong in your release plan. Because of the sensitive libraries involved, the integrated app will not run on Android emulators. Google approval for the READ_SMS permission is a stated compliance requirement. Customer onboarding involves adding a bank account, granting SMS permission so the phone number can be validated with the bank, fetching and linking bank details, and selecting a bank; a customer without a UPI PIN is prompted for card details and an OTP to complete setup. Only after that does the ongoing flow become selecting the linked account and entering the UPI PIN.

Plan physical-device testing for this Flutter Turbo integration and account for the documented SMS-permission approval in your Play release process. The guide does not provide a Flutter iOS release date.

React Native and Native iOS: Confirm the Exact Integration Path

Razorpay documents official React Native Standard and Custom wrappers. For headless Turbo UPI, confirm the supported wrapper or native bridge, dependency versions, Android/iOS coverage and test path with the integration team. The reviewed public guides do not establish a dedicated React Native Turbo headless wrapper, so obtain the documented path before committing to that architecture.

Razorpay also publishes a native iOS Turbo UPI integration. That is native iOS evidence. It does not override the Flutter Turbo guide’s scope, and a registry platform badge does not override it either.

PRO-TIP: Write your requirement as “no external UPI app switch on [framework and OS]” rather than only “headless”. That makes the acceptance test specific and testable.

Can In-App Payments Avoid Redirection on Both Android and iOS?

An in-app checkout can avoid opening a separate browser, but the authentication journey still depends on the payment method. UPI intent may switch apps; an activated embedded UPI integration can keep the payment in the merchant app. Card authentication needs its own supported flow and fallback handling.

Compare the Actual Payment Journeys

Razorpay’s app SDKs provide an in-app checkout interface. What happens during authorisation depends on the payment method: a UPI intent payment can open the customer’s UPI app, while activated Turbo UPI supports payment inside the merchant app. Eligible Native OTP card flows can avoid the bank’s OTP page, with fallback when the flow does not qualify.

Turbo UPI is an on-demand feature requiring account activation and customer onboarding. Keep first-time onboarding separate from a subsequent payment in your copy and your metrics. Note too that native Android and iOS Turbo support does not establish Flutter or React Native parity.

Avoid a Universal “No Redirects” Promise

Define the payment methods and operating-system combinations your app must support. Test browser redirection, bank authentication and UPI app switching separately; an in-app checkout interface does not remove every method-specific authentication step.

A gateway SDK answers how you collect payment. App-store policy answers whether you are allowed to collect it that way for what you sell, and treatment of physical goods, real-world services and digital content differs. Review Apple’s App Store Review Guidelines and Google Play’s payments policy, and note the India-specific alternative billing programme.

How Should You Plan a React Native or Flutter Payment Integration?

Start with the official plugin for the selected checkout flow, create the payment order on your backend, launch the SDK with the documented configuration and verify the returned result on your server. Add asynchronous payment-state handling and test the app lifecycle, authentication and fallback cases for both operating systems.

Choose Standard Checkout for the managed payment interface, or the separate Custom SDK when you need to implement the interface yourself. Avoid replacing the documented integration with an improvised WebView flow wrapped around an arbitrary payment page.

A Practical Eight-Step Implementation Plan

1. Define the required payment methods, frameworks, operating-system versions and whether “in-app” excludes browser redirects, bank pages, UPI app switching or all three.
2. Select Standard or Custom Checkout. Match the package, release track, native dependencies and framework architecture against the official documentation. Record the pinned package and native dependency versions.
3. Complete the documented test-account and feature-activation prerequisites before treating a package install as sufficient.
4. Create the payment order on your backend with the intended amount and currency. Pass the order ID and Key ID required by the documented checkout configuration to the app. Keep the Key Secret on the server for API calls and signature verification. Follow the official integration steps for the selected checkout flow.
5. Integrate the official framework plugin and native platform configuration, then register success and error handlers. Follow the React Native Android integration steps, the React Native iOS integration steps and the Flutter integration steps.
6. Verify the payment signature on your server using the server-generated order ID and the documented method. Confirm the payment state and capture configuration before fulfilling the order.
7. Process asynchronous payment events with signature checks, duplicate handling and reconciliation for delayed or missing callbacks. A client success callback is not proof of capture.
8. Run the failure-case matrix below on real devices, then complete the relevant official go-live checklist.

React Native and Flutter Need Different Lifecycle Checks

For React Native, check the native module integration and your project’s architecture rather than following an old manual-linking tutorial. The official repository documents Expo installation with npx expo install react-native-razorpay, followed by npx expo prebuild and a native run. Use a build that can load native modules. See the Android payment integration overview for Android context.

For Flutter, verify event handlers and cleanup against the current plugin API and native project configuration. The razorpay_flutter package page documents support for both iOS dependency managers. For iOS payment integration, also confirm scheme configuration before testing UPI intent.

PRO-TIP: On iOS, UPI intent requires LSApplicationQueriesSchemes entries in Info.plist so the checkout can detect installed UPI apps. Missing entries look like a missing payment method, not a configuration error.

What Should You Test Before Going Live?

Test the complete payment journey, including permission denial, unsupported authentication, external-app cancellation, delayed confirmation and app restart. A checkout that works in a demo is not evidence that every payment method and device combination works.

Test the Failure Paths, Not Only the Success Screen

The lifecycle row is not theoretical. Both Custom wrapper tracks have shipped fixes for activity recreation during process death, which is dated evidence that this failure class is real. Plan for physical devices where a feature guide rules out emulators.

Use the Right Support Evidence

When something breaks, send the exact SDK version, framework version, operating-system version, reproducible steps and redacted payment identifiers to the relevant integration support path. Never post a secret key or raw payment credentials in a public issue, and do not assume an open repository issue represents a current product limitation.

How Do You Choose the Right Integration for Your App?

Choose Standard Checkout when you want the documented managed interface. Evaluate the separate Custom SDK when your app needs to implement its own checkout UI. If you need UPI without a third-party app switch, validate the specific Turbo UPI integration and activation requirements.

A Requirement-Based Decision Table

For an advanced feature, obtain the supported framework and operating-system path before committing to implementation. Match that evidence to the requirement in your acceptance tests.

Frequently Asked Questions

Does Razorpay provide official SDKs for both Flutter and React Native?

Yes. Razorpay documents official React Native and Flutter integrations for Android and iOS, with separate Standard and Custom Checkout options. Verify the selected package and feature guide: availability of the framework SDK does not mean every advanced OTP or embedded UPI capability has identical support on both operating systems.

How can I check whether a payment gateway SDK is actively maintained?

Check the official package publisher, registry version and publication record, first-party release notes, native dependencies and documented framework requirements. Distinguish a repository commit from a published release. Standard and Custom packages have separate histories, so record the exact package and verification date.

Are Native OTP and automatic OTP submission the same feature?

No. Native OTP describes an authentication interface within the supported checkout flow. Automatic reading, filling and submission are additional capabilities. Razorpay documents a native iOS Custom Checkout path, but that does not establish Android-style OTP automation on iOS or automatic exposure through every wrapper.

Does headless UPI mean the customer never leaves my app?

Not necessarily. Headless describes interface control, while a UPI intent can still open another UPI app. Razorpay Turbo UPI provides an embedded UPI path, subject to activation and integration requirements. The reviewed Flutter Turbo guide currently supports Android; validate other combinations against their current documentation.

Can I offer payments without redirection on Android and iOS?

You can use app SDKs for an in-app checkout interface, but the authorisation journey depends on the payment method. Check browser redirection, bank authentication and UPI app switching separately. Use eligible Native OTP or an activated embedded UPI integration where supported, and retain the documented fallback and server-side verification paths.