WebView
This guide covers how to integrate the Kard Rewards WebView in your mobile or web application.
Introduction
Kard’s Rewards WebView provides a turnkey front-end offers experience, complete with a rewards map and intuitive offer discovery for their users. Issuers can integrate Kard’s WebView seamlessly into their existing experiences allowing them to launch and iterate on their rewards program quickly and easily.
It is designed to be embedded in:
- Mobile apps via native WebView components (iOS WKWebView, Android WebView, React Native WebView)
- Web applications via iframe
Environment URLs
Query Parameters
token (required)
A JWT authentication token that identifies the user and organization.
Required JWT claims:
The token is used for API authentication when the WebView makes requests to Kard services.
theme (optional)
A base64url-encoded JSON string containing design token overrides for customizing the appearance. Uses RFC4648 base64url encoding which is URL-safe (uses - instead of +, _ instead of /, and omits padding). No encodeURIComponent is needed when using base64url encoding.
Structure:
Color & theme tokens (styles.light / styles.dark)
These tokens are mode-dependent and can differ between light and dark themes:
All color values must be valid CSS color values (hex, rgb, hsl, oklch, named colors, etc.).
Layout tokens (styles.layout)
These tokens are mode-independent and apply to both light and dark themes:
labels (optional)
The labels property within the theme parameter allows customization of page titles displayed in the WebView. All label properties are optional — if not specified, the default values are used.
layout (optional)
The layout property within the theme parameter controls the visibility of page sections. All layout properties are optional — if not specified, the default values are used.
Deep linking to a single offer
By default the WebView opens the full offers list. You can also deep link a user straight to a single offer’s detail page — useful for push notifications, emails, SMS, or banners that promote a specific offer.
Load the offer detail route instead of the root URL:
The page is server-rendered with the issuer’s theme and no entrance animation, so it paints immediately with no loading flash.
Eligibility is enforced per user — the offer only renders if it’s available to the user identified by the token. If the offer is unavailable (for example, it has expired or the user isn’t eligible), a graceful “offer not available” message is shown instead.
Attribution source
When a cardholder opens the offer detail page, the WebView fires image impression pixels for the offer’s assets. By default those impressions are attributed to in-app browsing (BROWSE). When you deep link straight to an offer from a campaign — an email, a push notification, a map pin, or search — add the optional source query parameter so the impression is attributed to how the user actually arrived:
The WebView normalizes the value (it is uppercased) and overrides the medium on each tracking image URL before the pixels fire.
The source parameter is case-insensitive — email, Email, and EMAIL are equivalent. Any value outside the set above falls back to BROWSE. The parameter only affects attribution analytics; it does not change which offer is shown or whether it is eligible.
Fetching a WebView JWT Token
The Kard SDK provides methods to generate WebView tokens. The SDK is available in multiple languages:
SDK Method:
This returns a signed JWT that should be passed as the token query parameter.
WebView tokens can also be generated via REST API. Refer to the API documentation for Get WebView Token.
Location Message Passing Contract
The WebView uses a message-passing protocol to request location data from the container application. This is required for the rewards map feature to display nearby offers.
The WebView intentionally does not time out while waiting for location — this gives the user unlimited time to respond to the OS permission prompt. Because of that, the container must always reply to every REQUEST_LOCATION with exactly one LOCATION_RESPONSE or ERROR — including when permission is denied, location services are off, or the underlying request fails. If the container never replies, the rewards map stays in its “Finding offers near you…” loading state indefinitely.
How the WebView selects a location source
When the map needs location, the WebView chooses a source in this order:
window.KardWebview.postMessage(orwindow.ReactNativeWebView.postMessage) — if present, the WebView sendsREQUEST_LOCATIONthrough it and waits for the container to post a response back. This is the path native containers use.- iframe parent — if the WebView is running inside an iframe (
window.self !== window.top), it postsREQUEST_LOCATIONtowindow.parent. navigator.geolocation— otherwise it falls back to the browser’s geolocation API.
Native iOS (WKWebView) and Android (WebView) containers must expose a window.KardWebview.postMessage function — a small bridge injected at document start (shown in the examples below). A bare WKWebView / Android WebView does not provide it, and navigator.geolocation is unreliable inside native web views, so without this bridge the WebView never asks the container for location and the map will not load. (window.ReactNativeWebView is also accepted for backwards compatibility — react-native-webview injects it automatically, which is why the React Native example below doesn’t add a bridge.)
Message Types
Request Format (from WebView)
When the WebView needs location data, it sends:
Success Response Format (to WebView)
When location is successfully retrieved:
Coordinate fields:
Error Response Format (to WebView)
When location cannot be retrieved:
Platform Integration Examples
React Native
iOS (Swift)
Android (Kotlin)
Android (Jetpack Compose)
Web (iframe)
Theming Resources
Below is an example showing how to apply custom branding: