A key aspect of WebView app behaviour is controlling which URLs open inside the app's WebView and which open in the device's external browser (typically Chrome). Getting this right affects both user experience and functionality: particularly for payment flows, OAuth sign-ins, and third-party service redirects.
Default Behaviour
By default, WebToAppConvert uses a whitelist approach:
- Your main domain and its subdomains open inside the app
- All other domains open in the external browser
For example, if your website is yourdomain.com, then:
yourdomain.com/shop: opens in appshop.yourdomain.com/checkout: opens in app (subdomain)facebook.com/yourpage: opens in Chromepaypal.com/...: opens in Chrome (default)
Adding Allowed Domains
Some third-party services need to open inside the app as part of a continuous user flow. OAuth sign-in with Google, for example, redirects to accounts.google.com and then back to your site. If accounts.google.com opens in Chrome instead of the WebView, the redirect back to your site after login happens in Chrome, not in the app: breaking the sign-in flow.
To add a domain to the in-app allowed list:
- In your app configuration, navigate to WebView Settings → Allowed Domains
- Add the domain you want to open in-app (e.g.,
accounts.google.com) - Save and rebuild
Payment Gateway Handling
Payment gateways present a nuanced case. The correct approach depends on the gateway:
Stripe Checkout (Hosted)
Stripe's hosted checkout opens a new page at checkout.stripe.com. Because this is a different domain, it opens in Chrome by default. After payment, Stripe redirects to your success URL: this redirect also happens in Chrome.
For a seamless in-app payment experience, use Stripe's Payment Element embedded directly in your website rather than hosted Checkout. The payment form loads on your own domain, stays in the WebView, and completes without leaving the app.
Alternatively, add checkout.stripe.com to your allowed domains. The payment will complete in-app, but be aware that this opens the full Stripe checkout UI inside the WebView, which may have limitations depending on your Stripe configuration.
PayPal
PayPal's redirect flow opens paypal.com for user authentication. Users with the PayPal app installed may see a prompt to open it via the PayPal URL scheme. Adding paypal.com to allowed domains keeps the PayPal login inside the WebView.
For WooCommerce sites, the PayPal for WooCommerce plugin supports an embedded payment flow that avoids the redirect entirely.
Social Share Links
Links to social media (Facebook, Twitter/X, Instagram, WhatsApp) typically open in the external browser by default. This is usually the correct behaviour: users expect share links to open in their social app or browser, not inside your WebView.
If you want these to trigger native app sharing (e.g., tapping a "Share on WhatsApp" button opens the WhatsApp app), this is handled by the URL scheme (whatsapp://, fb://), which Android handles automatically: no configuration needed.
Special URL Types
The following URL types are handled by Android's intent system and behave consistently regardless of your domain settings:
mailto:: Opens the device's email clienttel:: Opens the Phone app to make a callsms:: Opens the Messages appintent://: Opens the specified Android app if installed- App store links (
market://): Opens the Play Store
These cannot and should not be intercepted: they're part of expected Android behaviour and users will tap phone numbers and email addresses expecting them to work.
File Downloads
When a user taps a download link in the WebView, Android's download manager handles it. Downloaded files appear in the notification tray and are saved to the device's Downloads folder. No special configuration is required: this works by default for standard file types (PDF, ZIP, images, etc.).