Payment Configuration
The Hubble SDK supports two payment methods:
- UPI payments: Users can pay using UPI apps like Google Pay, PhonePe, Paytm, and CRED. On mobile devices, users tap the UPI app icon within the SDK to be redirected to the app to complete payment.
- Credit/Debit card payments: Users can pay using credit or debit cards directly within the SDK. Card payments are not enabled by default - contact Hubble support to enable card payments for your integration.
The rest of this section focuses on UPI Intent configuration, which requires platform-specific setup on iOS and Android.
If you are doing a web-only integration (iframe in a browser), the UPI Intent configuration described in this section does not apply and you can skip to Part VI. However, if a user opens your web integration from a mobile device, UPI Intent can still be triggered by the system to open installed UPI apps.
iOS UPI Configuration
The iOS Limitation
On iOS, a WebView cannot detect which UPI apps are installed on the user's device. This is a platform restriction that cannot be bypassed. Because of this limitation, the SDK displays icons for the most popular UPI apps (Google Pay, PhonePe, Paytm, CRED, BHIM) regardless of whether they are actually installed. When the user taps an app icon, the system attempts to open that app - if it is not installed, the intent will fail silently or show a system error.
Passing Installed UPI Apps
To provide a better user experience, your native iOS app can detect which UPI apps are installed and pass this list to the SDK. The SDK will then display only the UPI apps that are actually available on the device, instead of showing all popular apps.
To detect installed UPI apps, your app must declare the URL schemes it wants to query. Add the following to your app's Info.plist under the LSApplicationQueriesSchemes key:
<key>LSApplicationQueriesSchemes</key>
<array>
<string>phonepe</string>
<string>tez</string>
<string>paytmmp</string>
<string>cred</string>
<string>bhim</string>
</array>
With these schemes declared, your app can use UIApplication.shared.canOpenURL() to check which UPI apps are installed, and then pass the list of installed app identifiers to the SDK. The SDK will filter its payment UI to show only those apps.
Without passing the installed apps list, users may tap a UPI app icon only to find it is not installed on their device. This creates a poor payment experience. Passing the installed apps list eliminates this friction.
iOS WebView Background Behavior
When a user taps a UPI app (e.g., Google Pay) in the SDK, they leave your app to complete the payment. On iOS, the WKWebView may suspend JavaScript execution while your app is in the background. This means the SDK's payment status polling can pause.
When the user returns to your app after completing the payment in the UPI app, the WebView resumes and the SDK picks up polling again. In most cases, this works fine. However, if the WKWebView has been suspended for a long time, the payment status screen may appear stuck for a few seconds while it catches up.
Listen for the app returning to the foreground (applicationDidBecomeActive or sceneDidBecomeActive) and reload the WebView if the payment screen appears stuck. This forces the SDK to re-check the payment status immediately.
Android Configuration
On Android 11 (API level 30) and above, apps must declare which packages they query. Add the following to your AndroidManifest.xml:
<queries>
<intent>
<action android:name="android.intent.action.VIEW" />
<data android:scheme="upi" />
</intent>
</queries>
This allows the WebView to post the UPI intent to the system, which then transfers control to the appropriate UPI app to complete the payment.
If UPI apps are not appearing in the Android WebView, verify that the <queries> block is present in your AndroidManifest.xml and that your WebView is configured to handle external intents. The WebView must allow the UPI deep link to open the appropriate app.