Integration surfaces

A surface is the place your users actually see Cheggout: a screen you drew yourself, a component the SDK renders inside your app, a banner injected into your web page, or a Cheggout-hosted site you send them to. The modules — scratch cards, advertisement, marketplace, coupons — are the same underneath. The surface only decides who owns the pixels.

This page compares the four surfaces available today, so you can commit to one before you start building. Changing surface later is not a small refactor: it changes which credentials you hold, where your session lives, and how much UI your team maintains forever.

The four surfaces

Surface	Who draws the UI	What you integrate	Best when
Headless API	You, entirely	HTTPS + JSON from your backend	You have design opinions and engineering capacity, or you are on a channel with no Cheggout SDK
Native SDK components	Cheggout, inside your app	An AAR or an iOS framework	You have a native app and want the full marketplace without building commerce
JavaScript / Web	Cheggout, inside your page	One <script> tag and a container <div>	You publish a website and want rewards on article or transaction pages
Hosted experience (PWA)	Cheggout, on its own domain	An authenticated launch URL	You want the shortest path to live, or you have no app surface to embed into

You are not choosing one forever, and you are not choosing one for everything. Mixing is normal: a bank commonly ships the native SDK for the marketplace in its app and uses the headless Rewards Center API for post-transaction scratch cards on its internet-banking website.

Choosing

Three questions settle it in practice:

1. Do you have a native app? If not, headless, JavaScript or hosted are your only options.
2. Do you want to own the visual design? If yes, headless is the only surface that gives it to you. Every other surface renders Cheggout's components.
3. How much engineering time do you have? Hosted is days. The widget is days. The native SDK is two to three weeks. Headless is two weeks for one module and grows with each screen you build.

Components are a rendering layer, not a decision engine

This is the most important thing to understand before you pick a surface, and it is what makes mixing surfaces safe.

Nothing about eligibility, targeting, reward selection or inventory lives in a component. The Android getTopBannerDetails call, the iOS getCheggoutTopBanners call, the widget's bannerTriggerEvent, and a raw headless HTTP request all reach the same server-side decisioning. The component fetches a decision that has already been made and paints it.

The practical consequences:

• You cannot change behaviour by changing surface. If a user is not eligible for a campaign, no SDK method will make them eligible. Campaign rules, frequency caps and reward pools are configured on Cheggout's side.
• The same tracking obligations apply everywhere. Impression on display, click on tap. The SDK gives you a helper (trackLink on Android, impression on iOS); headless integrators fire the URL with a plain GET. Skipping it breaks attribution and reporting regardless of surface.
• Reward assignment is late-binding. A scratch card is created empty and only gets a reward when it is revealed. That is a server behaviour, so it is identical whether the card is drawn by your code, by the SDK, or by the hosted PWA. See Scratch card lifecycle.
• Migrating surfaces keeps your data. virtualId identifies the same user everywhere, so a reward earned through the widget is visible in the SDK and through GetAllScratchCardsByUserId.

Treat SDK components as a convenience: they save you from building a scratch-card animation and a 600-retailer storefront. They do not save you from thinking about identity, idempotency or tracking.

What each surface requires

Headless API

• A backend that can hold an RSA private key and sign requests, or hold an app key pair for the Deals Store product line.
• Server IPs whitelisted with Cheggout.
• Your own UI for every screen: cards, reveal animation, reward detail, history.
• Storage for revealed rewards — reveal is one-shot.

Start at Headless overview.

Native SDK components

• Android: Target 35, minSdk 24, Kotlin 2.0.0, an AAR supplied by Cheggout during onboarding.
• iOS: Swift 5.9 built on Xcode 26, deployment target iOS 15.6 through iOS 26, a framework supplied by Cheggout.
• A backend that can mint a sessionId via GenerateSessionInfoV2 — the SDK cannot do this itself, because it requires your private key.
• A virtualId generation service, available to both Cheggout and your app vendor.

Start at Android installation or iOS installation.

JavaScript / Web

• HTTPS on the pages that host the widget.
• Exchanged public key certificates, because the token the widget carries is minted by a signed server-side call.
• A container <div> with an exact id, and a backend endpoint that mints user tokens.

Start at JavaScript overview.

The web widget is distributed from a UAT host today

The only published script URL is a UAT blob host. There is no production URL yet. Treat the widget as Beta and confirm the production distribution point during onboarding.

Hosted experience

• An authenticated user on your side, and a backend that can mint either a user token or a sessionId.
• A launch point in your UI, and a decision about where the user returns to.
• A domain decision: a Cheggout subdomain, or a branded domain you provide.

Start at Hosted overview.

Module availability by surface

Module	Headless	Android	iOS	JS / Web	Hosted
Scratch Cards & Rewards	Available	Available	Available	Beta	Available
Advertisement	Beta	Available	Available	TBD	—
Lifestyle Marketplace	—	Available	Available	—	Available
Coupons & Deals	Available	via SDK	via SDK	TBD	Available
Deep payment	—	Available	Available	—	Available
Refer & Earn	Not available	Not available	Not available	TBD	TBD

A dash means the combination does not make sense by design — the marketplace is a full storefront, so there is nothing headless to expose, and deep payment requires a host app that can open a payment sheet.

Flutter and React Native

TBD There is no Flutter SDK and no React Native SDK today. No package, plugin or bridge is published, and no API surface has been specified. If your app is built on either framework, your options are platform channels over the native SDKs, or the headless API and hosted experience, which are framework-agnostic.

Read Flutter and React Native before planning around either.

Next

• Integration models — named module-and-surface combinations with effort estimates.
• Environments and endpoints — which hosts each surface talks to.
• Onboarding — key exchange and credential issuance, the long pole on every surface.