Platform modules
Cheggout is not one product. It is a set of modules that share an identity model, an authentication model and a tracking model, and that you adopt independently. This page tells you what each module does, what it is worth, what it costs you to build, and how to pick.
Everything below assumes you have read Core concepts — the
virtualId, channelName, extTransactionId and tracking-link vocabulary is shared by every
module and is not repeated on each page.
The modules
| Module | What it is | What the user sees |
|---|---|---|
| Scratch Cards | A gamified reward issued after a qualifying event | A card they scratch to reveal a coupon, points, or "better luck next time" |
| Advertisement | Merchandising placements you host in your own UI | Rotating offer banners and a row of store icons |
| Marketplace | Cheggout's whole shopping experience, dropped into your app | A shop with 600+ retailers, vouchers, dining, travel and gift cards |
| Coupons & Deals | A headless voucher catalogue you merchandise yourself | Your storefront, your design, Cheggout supplies the offers and codes |
| Refer & Earn | Referral and registration event tracking | Not available Not currently integrable — see the page |
Business value
Each module answers a different commercial question. Pick the one that matches the problem you actually have.
| Module | The problem it solves | Typical reason to adopt |
|---|---|---|
| Scratch Cards | Transactions are functional but unmemorable, and repeat frequency is flat | Attach a surprise to an action you already want more of — a payment, an article read, a bill paid |
| Advertisement | You have valuable screen real estate and nothing commercially useful to put in it | Monetise home and feed placements without building a merchandising stack |
| Marketplace | You want a full rewards destination but cannot fund building one | Ship a complete shopping and rewards experience without designing or operating it |
| Coupons & Deals | You already run a points or coin economy and need something worth redeeming | Give your currency a redemption catalogue you fully control the look of |
Scratch Cards and Advertisement are additive to an existing screen. Marketplace is a destination you send users to. Coupons & Deals is a supply contract behind a storefront you build.
Integration complexity
Complexity here means engineering effort and the number of moving parts you own, not difficulty.
| Module | Effort | Backend work required | You own the UI |
|---|---|---|---|
| Marketplace via SDK | Lowest | Session generation only | No — Cheggout renders everything |
| Advertisement | Low | Token or key management | Yes — you render creatives |
| Scratch Cards via SDK | Low to moderate | Signed server call recommended | Partly — the SDK renders the card |
| Scratch Cards headless | Moderate | Token lifecycle, reveal, persistence | Yes — entirely |
| Coupons & Deals | Highest | Catalogue cache, coin burn, refunds, reconciliation | Yes — entirely |
The pattern is consistent: the more of the experience you own, the more state you own. Headless Scratch Cards make you responsible for persisting revealed rewards, because reveal is one-shot. Coupons & Deals makes you responsible for the coin burn and its refund path, because Cheggout has no wallet API.
Surface support
A surface is how the module reaches the user. Not every module is available on every surface.
| Module | Android SDK | iOS SDK | JavaScript widget | Hosted PWA | Headless API |
|---|---|---|---|---|---|
| Scratch Cards | Yes | Yes | Beta | Yes | Yes |
| Advertisement | Yes | Yes | TBD | Within the experience | Partly — see below |
| Marketplace | Yes | Yes | No | Yes | No |
| Coupons & Deals | Within the experience | Within the experience | No | Within the experience | Yes |
Two clarifications on that table:
- Advertisement headless. The banner and store endpoints are documented as SDK method calls. A headless HTTP contract for the same data is not published. TBD Confirm with Cheggout before planning a server-side ad integration. Tracked in Open Items.
- "Within the experience" means the module is present because the SDK or microsite renders it, not because you call it yourself.
Capability matrix
| Capability | Scratch Cards | Advertisement | Marketplace | Coupons & Deals |
|---|---|---|---|---|
| Requires signed envelope | Yes | Via token or session | Yes | No — API key |
| Requires an API key pair | No | No | No | Yes |
| Publisher renders the UI | Optional | Yes | No | Yes |
| Publisher stores delivered artefacts | Yes — revealed rewards | No | No | Yes — coupon codes |
| Idempotency key required | Yes — extTransactionId | No | No | Yes — extTransactionId |
| Impression and click tracking required | Yes | Yes | Handled by the SDK | No documented tracking contract |
| Involves publisher-side currency | No | No | No | Yes — coin burn |
| Publisher must expose an endpoint | No | No | For deep payment only | Recommended for the invalidation webhook |
| Product line host | Rewards Center | Bank & SDK | Bank & SDK | Deals Store |
The last row matters more than it looks. The three product lines have different hosts and different authentication, so adopting two modules can mean implementing two auth mechanisms. See Environments and Authentication overview.
How to choose
Work through these in order.
1. What moment are you trying to improve? A completed transaction points to Scratch Cards. An under-monetised home screen points to Advertisement. A missing rewards destination points to Marketplace. An unspent loyalty balance points to Coupons & Deals.
2. How much of the experience do you want to own? If the answer is "none, ship it", use the Marketplace SDK. If the answer is "all of it, it must look like us", use the headless paths. Anything in between is the SDK plus your own placements.
3. What can your backend commit to?
Every module needs some server work — at minimum a scheduled job that mints and caches a token.
Coupons & Deals needs materially more: a transactional coin burn with a refund path, plus
reconciliation by extTransactionId. Do not start there if you cannot fund that.
4. Which platforms must launch together? Android and iOS SDKs are at parity. Web is served by the JavaScript widget, which today is a scratch-card surface only and is published from a UAT host. Flutter and React Native wrappers are not available. TBD
5. Start with one. Modules share identity and authentication, so adding a second later is mostly configuration. Ship one module end to end — including tracking — before you start the next.
Recommended reading order
- How Cheggout works — the shape every integration takes.
- Core concepts — the shared vocabulary.
- Integration models — SDK against hosted against headless.
- The overview page for the module you picked.
- Authentication overview — before you write any code.