Hosted experience
You authenticate the customer, launch a Cheggout microsite with a session, and get them back when they are done. Everything in between is Cheggout's to build and maintain.
AvailableWhen this is the right choice
You want to launch quickly. There is no SDK to integrate, no components to render, and no app release required to change anything inside the experience.
You have no mobile engineering capacity, or a small team with other priorities.
You are web-first. A microsite is a natural fit for a browser-based product.
You want to validate before investing. Launch hosted, learn whether customers engage, and move to the native SDK later. The session contract is the same, so the integration work carries over.
What you build
Three things:
- A launch point — a button, tile or menu item.
- Session or token minting on your backend, after your own authentication.
- Return handling — what your app does when the customer comes back.
Domain options
The microsite can be served from either:
| Option | Example | Feels like |
|---|---|---|
| Cheggout subdomain | https://partnerXYZ.cheggout.com | A partner experience |
| Your own branded domain | https://partnerrewardshop.com | Your product |
The branded domain is worth the setup for a consumer-facing experience — customers notice the URL, particularly in a browser where it is always visible.
Agree the choice during onboarding.
How it opens
| Container | Notes |
|---|---|
| In-app web view | Feels part of your app. You control the chrome and the back behaviour. |
| Custom tab or in-app browser | Better platform integration, less control over chrome. |
| External browser | Simplest. The customer leaves your app. |
| Direct link | For web publishers, a normal navigation. |
For a mobile app, an in-app web view or custom tab keeps the customer in context. Handle the back gesture yourself so the experience does not feel like a dead end.
What's available hosted
| Experience | Available |
|---|---|
| Rewards and scratch cards | TBD |
| Marketplace and offers | TBD |
| Deals and coupons | TBD |
| Gift cards | TBD |
No per-experience availability matrix for the hosted surface is published. Which hosted experiences are provisioned for your channel is confirmed at onboarding — ask for the list in writing before you design around any one of them.
Trade-offs against the native SDK
| Hosted | Native SDK | |
|---|---|---|
| Time to launch | Roughly 1 week | Roughly 2–3 weeks |
| Changes ship | Server-side, instantly | With an app release |
| Feel | Web | Native |
| Offline | No | Partial |
| Deep integration | Limited | Full — banners, badges, callbacks |
| Maintenance | Cheggout's | Shared |
The honest summary: hosted is faster and cheaper to run, native feels better and integrates deeper. Most publishers who intend to make this a core surface end up on the SDK; publishers adding a secondary feature are well served staying hosted.
Responsive behaviour
TBD Specific responsive behaviour, supported browsers and minimum viewport sizes are not published. Verify the experience on your actual device and browser mix during UAT, particularly on older devices, and raise anything that renders poorly with Cheggout.
Before you start
- Signed-envelope authentication implemented, for session or token minting
- A
virtualIdscheme decided - Launch URLs provisioned by Cheggout for your channel
- Domain choice agreed
- A decision on the container — web view, custom tab or browser
- Return behaviour designed
Next
- Launch URLs — the parameters and the handoff.
- Return handshake — bringing the customer back.
- Session & SSO