Launching the Android SDK

Launching hands control of the screen to Cheggout. The user lands inside the shopping module already signed in, browses, and comes back to you when they press back or home. This page covers the call, the payload it takes, what has to be true before you make it, and how control returns.

The launch flow

The important structural point: your app never mints the session itself. GenerateSessionInfoV2 requires a signed envelope, which requires your RSA private key, which must never ship inside an APK. Your backend mints it and passes it down.

Prerequisites

Both identifiers must be present and valid before you call launchCheggout.

Prerequisite	Where it comes from	Why it matters
virtualId	Your own virtual ID service	A stable, non-PII identifier for the user. Cheggout ties rewards, coupons and points to it.
sessionId	GenerateSessionInfoV2	Generated from the virtualId. Enables single sign-on so the user is not asked to log in again.
channelName	Issued by Cheggout at onboarding	Identifies your channel; must match the value passed to init.
IP whitelisting	Onboarding	Cheggout verifies the session ID against your backend, so your egress IPs must be registered.

The session ID is generated using the virtual ID, and the same pair must be used at launch. Passing a session ID that was minted for a different virtual ID breaks SSO.

The launchCheggout signature

CheggoutApplication.launchCheggout(
    context,          // Context
    virtualId,        // String
    sessionId,        // String
    payload,          // String — see below
    activityContext,  // Context
    channelName       // String
)

Parameter	Type	Required	Description
context	Context	Yes	Application or Activity context used to start the SDK.
virtualId	String	Yes	The user's virtual ID. Unique, stable, contains no PII.
sessionId	String	Yes	The session ID returned by GenerateSessionInfoV2 for this same virtualId.
payload	String	Yes	A JSON-shaped string of launch options. See Payload.
activityContext	Context	Yes	The context of the calling Activity, used for navigation and for returning control.
channelName	String	Yes	Your Cheggout channel identifier.

Kotlin

val payload =
    "{'Component':'CHEGGOUT','IsEmployee':'0','Language':'','DeeplinkInfo':'','customerId':''}"

CheggoutApplication.launchCheggout(
    this,
    "pub_8f14e45fceea167a",   // virtualId
    sessionId,                 // from your backend
    payload,
    this,                      // activity context
    "YOURCHANNEL"
)

Java

String payload =
    "{'Component':'CHEGGOUT','IsEmployee':'0','Language':'','DeeplinkInfo':'','customerId':''}";

CheggoutApplication.Companion.launchCheggout(
    this,
    "pub_8f14e45fceea167a",
    sessionId,
    payload,
    this,
    "YOURCHANNEL"
);

Payload

The payload is passed as a string, not as a Map or a JSON object. The documented form uses single quotes:

Default payload

"{'Component':'CHEGGOUT','IsEmployee':'0','Language':'','DeeplinkInfo':'','customerId':''}"

Payload carrying a deep link

"{'Component':'CHEGGOUT','IsEmployee':'0','Language':'EN','DeeplinkInfo':'$href','customerId':''}"

On any campaign, banner or store click, pass the href you received from the corresponding API into DeeplinkInfo. That is what makes the SDK open the specific offer or store page instead of the Cheggout home page.

Payload keys

Key	Values	Required	Description
Component	CHEGGOUT, HEALTH, PHARMA, HEALTHPACKAGE	Yes	Which component to launch. CHEGGOUT is the default shopping module.
IsEmployee	0 / 1 (also Yes / No)	No	Marks the user as a publisher employee, so employee-specific offers apply. Treated as 0 if omitted.
Language	2-character ISO code, e.g. EN	No	Interface language. Empty string uses the default.
DeeplinkInfo	The href from a banner, store or scratch card API	No	Redirects to an offer or store-specific page inside the SDK. Present only when the SDK is invoked from a deep link, a banner click or a push notification.
customerId	String	No	A publisher-side customer reference.
pushnotificationID	String	TBD	The Firebase identifier for the logged-in user, when Cheggout manages push. This key is documented for the iOS payload; the documented Android payload string is Component / IsEmployee / Language / DeeplinkInfo / customerId. Confirm with Cheggout whether Android accepts it before relying on it. See Push notifications.

Build the payload, don't hand-write it

Assemble the string from a helper so you cannot ship a payload with a missing quote. A malformed payload does not throw — the SDK simply launches with defaults, and the deep link you meant to pass is silently dropped.

When the identifiers are wrong

There is no error callback for a bad identifier. The documented behaviour is blunt:

Invalid IDs produce a white page

An invalid userID/virtualId or an invalid session key prevents the SDK from proceeding beyond the claimer page, resulting in a white page. There is no exception, no toast and no callback.

Because failure is silent, validate before you launch:

• Confirm your backend returned a non-empty sessionId before calling launchCheggout. Treat a failed GenerateSessionInfoV2 as "do not launch", and show your own error.
• Do not reuse a sessionId across users, and do not cache one beyond the user's own session.
• Log the virtualId and a hash of the sessionId at launch so a white-page report can be traced back to the session that produced it.
• Verify the channelName at launch matches the one you passed to CheggoutApplication.init().

Exit and the back handshake

The user leaves Cheggout by pressing back or home on the Cheggout home page. When that happens:

1. The SDK session is terminated.
2. Control returns to your mobile application.

What you do next is your decision, and the documented behaviour splits on whether your app still considers the user logged in:

Your app's state	Where the user should land
The application decides to end the session	Your login page
The application keeps the session active using Last Activity Time or Heartbeat	Your home page

This is why the heartbeat below matters. Without it, a user who spent fifteen minutes shopping inside Cheggout looks idle to your app's session timer and gets dumped back at a login screen.

Heartbeat

The heartbeat lets the SDK tell your app that the user is still active, so your session timeout does not fire while they are browsing inside Cheggout.

Implement CHEGHeartBeatListener on the Activity or Fragment that launches the SDK, and override onCheggoutHeartBeat():

class ShopActivity : AppCompatActivity(), CHEGHeartBeatListener {

    override fun onCheggoutHeartBeat() {
        // The user is active inside the Cheggout SDK.
        // Reset your own inactivity timer here.
        sessionManager.recordActivity()
    }
}

Then launch using the overload that takes the calling instance as an extra parameter:

// From an Activity — pass `this`
CheggoutApplication.Companion.launchCheggout(
    this, virtualId, sessionId, payload, instanceOfActivity
)

// From a Fragment — pass the host Activity
CheggoutApplication.Companion.launchCheggout(
    this, virtualId, sessionId, payload, activity
)

Two overloads, two purposes

The six-parameter form takes activityContext and channelName. The heartbeat form takes the instance implementing CHEGHeartBeatListener as its final parameter. Use the heartbeat form whenever your app enforces an inactivity timeout — which, for a banking app, is always.

The iOS equivalent uses a NotificationCenter broadcast rather than a listener interface; see iOS callbacks.

Deep payment relaunch

When the user buys something inside Cheggout that your app must pay for, the SDK exits with payment data, your app runs the payment, and then you relaunch the SDK with an updated deep link. The launch call is the same one documented here; only DeeplinkInfo changes.

The flow, the CHEGPaymentManager callback and the decoded payment payload are covered in Deep payment and Callbacks.

Next

• SDK methods — fetching banners, stores, points and scratch cards.
• Callbacks and notifications — every listener interface, plus push setup.
• Session and SSO — the identity model behind the launch.