Shopping Portal Mobile Integration - Wildfire Support Center
Shopping Portal Mobile Integration
The Shopping Portal is a cashback and coupons marketplace that lives inside your mobile app as an embedded web view. Your users browse merchant offers, click through to shop, and earn cashback on qualifying purchases. This page summarizes how the integration works and the key decisions your team needs to make.
The User Flow The User Flow
| ✓ Stay in the App RECOMMENDED The merchant’s website opens inside your app. The user shops, checks out, and returns to the portal without ever leaving your app. - Best attribution — tracking stays intact - Seamless UX — no context switch - Requires more WebView configuration |
↗ Open in Browser HIGHER RISK The merchant link opens in Safari, Chrome, etc. The user leaves your app to shop and has to manually switch back to your app. - Simpler to build — standard URL handoff - Attribution risk — browser privacy features can block tracking cookies - User leaves your app entirely |
|---|
Why does this matter?
Cashback depends on an unbroken tracking chain:
user click → affiliate redirect → tracking cookie → purchase → commission.
If any step breaks, the user doesn’t get cashback. Browser privacy features (Safari ITP, Firefox ETP, and ad blockers) actively work against this chain. Keeping the experience in-app gives you the most control over protecting it.
2. How the Integration Works 2. How the Integration Works
- Build entry points. Your team creates the surfaces that lead users to the portal — a menu item, home screen card, push notification, etc.
- Host the WebView. Your app opens a web view that loads the portal. We provide the URL; you provide the native app shell (header, nav, back button).
- Handle authentication. For most partners, your app passes a user ID in the URL when launching the portal. No login UI needed inside the portal itself.
- Configure link routing. IN-APP ONLY Merchant clicks and affiliate redirects need to stay inside the WebView. Links to your own help center or legal pages can open externally.
- Suppress app-to-app handoffs. IN-APP ONLY If a merchant has a native app (e.g., Amazon), the WebView must not let the OS hijack the link. The redirect chain has to complete in the WebView for tracking to work.
- Test attribution end-to-end. Click a merchant offer → complete a test purchase → verify the conversion appears in our tracking dashboard. Repeat across multiple merchants.
Steps 1–3 and 6 apply to both integration models. Steps 4 and 5 IN-APP ONLY are specific to the recommended stay-in-app experience — they don’t apply if you choose browser click-out.
3. Pre-Launch Checklist 3. Pre-Launch Checklist
- WebView supports JavaScript, cookies, and local storage
- Third-party cookies enabled (especially Android)
- Affiliate redirect chains are complete without interruption
- No universal link / App Link hijacking on merchant URLs
- Back button steps through WebView history correctly
- Authenticated session persists across app backgrounding
- Tested across iOS and Android (current + prior major OS version)
- Tested with ad blockers, password managers, and VPNs active
- Attribution validated end-to-end with test purchases
- Monitoring/logging in place for broken flows
More Resources:
- Wildfire Universal Data Dictionary
- Shopping Portal Mobile Embedded Experience: Technical Implementation Guide
Updated 17 Jun 2026