Return handshake
The customer finishes in Cheggout and comes back. Getting this right is the difference between a feature that feels integrated and one that feels like being thrown out of your app.
The SDK case
For the native SDK, the behaviour is defined:
When the user presses the back button or home button on the Cheggout homepage, the SDK session is terminated and control is returned to the mobile application.
What happens next is your decision:
The documented options, verbatim in effect:
- If the application decides to end the session, the user is redirected to the Login page.
- If the application keeps the session active using Last Activity Time / Heartbeat functionality, the user is redirected back to the Home page.
Why the heartbeat matters
A customer who spends ten minutes browsing offers inside Cheggout has been active — but to your app, which sees no taps, they look idle. In a banking app with a short idle timeout, that means being logged out on return from a session they were engaged in throughout.
The SDK emits an activity signal so your idle timer knows better.
| Platform | Mechanism |
|---|---|
| Android | Implement CHEGHeartBeatListener and override onCheggoutHeartBeat() in the calling Activity or Fragment, and launch with the activity instance parameter |
| iOS | Observe the TrackUserActivity notification, which carries the last activity time and the event |
See Android callbacks and iOS callbacks.
It is a small amount of code and it removes the single most jarring failure in an SDK integration. Feed the signal into the same idle timer your own screens use.
The browser case
TBD Return behaviour for browser-based launches is not documented. There is no published return-URL parameter or postMessage contract for the hosted microsite.
What you can control on your side, by container:
| Container | How the customer returns |
|---|---|
| In-app web view | You own the chrome. Provide a close or back control and handle it yourself. |
| Custom tab / in-app browser | The platform's dismiss gesture returns them to your app. |
| External browser | The customer uses the OS back gesture — least controllable. |
| Same-tab navigation (web) | Browser back, unless you opened a new tab. |
Recommended: use an in-app web view or custom tab for a mobile app, so you keep a close control and can decide what the customer sees when they return.
If you need a return URL or a completion signal — for example to refresh a points balance the moment they come back — ask Cheggout. It is worth raising as a requirement; it is on Open items.
What to do on return
Refresh state that may have changed. A customer who just claimed a reward or spent points expects your screen to reflect it. Refresh the cashback badge and any rewards indicator when your screen becomes visible again.
Return them somewhere sensible. The screen they launched from is usually right. Dropping them at your app's root is disorienting.
Do not re-prompt for authentication if their session is still valid. That is the whole point of the heartbeat.
Handle a fast return. A customer who opens Cheggout and immediately backs out should not see a loading state or a flash of empty content.
Testing the return
- Back from the Cheggout home screen returns control to your app
- Home button behaves the same way
- A long session inside Cheggout does not log the customer out
- The customer lands on the screen they launched from
- Points and reward indicators refresh on return
- An immediate back-out is handled without a flash of loading state
- Killing the app mid-session and reopening behaves sanely
The long-session test is the one teams forget, and it is the one customers hit.