Every Glomo SDK can tell the checkout page which colour scheme to present. The property is called appColorScheme on all five surfaces, and it behaves the same way everywhere except for one thing: what the automatic value resolves to. That part is a per-platform decision, and it is the only part worth reading carefully.
appColorScheme is a request. The checkout page decides, against your merchant dashboard settings. Passing dark does not guarantee a dark checkout.
Dark mode is enabled per account. Until it is enabled for yours, checkout stays light whatever you pass - so you can ship the integration ahead of time and it will start matching once the account is switched on. Contact Glomo support to enable it. White-labelled checkouts always stay light.
On the web SDK, the loading screen starts light and switches once checkout has confirmed dark mode is enabled for your account.
If you want a specific scheme, pass light or dark. Those two values are the portable ones: they mean exactly the same thing on every Glomo SDK, and an integration that drives the property from its own theme state behaves identically across platforms.
The automatic value is the one that differs.
| SDK | Value | Resolves to |
|---|---|---|
| Unified SDK (Web) | 'system' | The customer's device setting, including changes made while checkout is open. |
| Flutter | GlomoColorScheme.auto | Theme.of(context).brightness where the checkout is mounted - your app's own appearance, not the device's. An app on ThemeMode.system therefore gets the device setting, because that is what its theme already reports. |
| React Native | "auto" | Appearance.getColorScheme(), which is your app's effective appearance. If your app calls Appearance.setColorScheme(), that value is what the SDK sees - React Native overwrites the device value in place and exposes nothing that reports what it overwrote. |
| iOS | .auto | The checkout's own trait collection, so an app that sets overrideUserInterfaceStyle gets what it set rather than what the device is on. |
| Android | GlomoColorScheme.AUTO | Your app's own appearance, from the most specific source that can answer: AppCompatDelegate.getDefaultNightMode() if you have set one, otherwise your theme's isLightTheme, otherwise the device configuration. |
Note the web SDK differs twice over: the value is spelled 'system' rather than auto, and it is not the default. Leave appColorScheme out on the web and checkout stays light. On all four mobile SDKs the automatic value is the default, so an integration that sets nothing already follows the host app.
The mobile SDKs spell it auto rather than system on purpose. On a mobile host the value the SDK can reach is the application's appearance, not the operating system's underlying setting - calling it system would promise something three of the four platforms cannot deliver.
Supported on every SDK, and on none of them does it reload the page - the live page is told directly, so a payment in flight survives the change.
| SDK | How |
|---|---|
| Unified SDK (Web) | checkout.setAppColorScheme('dark') |
| Flutter | Pass a new value to the GlomoPayCheckout widget |
| React Native | Pass a new value to the GlomoCheckout component |
| iOS | handle.setAppColorScheme(.dark) on the handle returned by startCheckout |
| Android | handle.setAppColorScheme(GlomoColorScheme.DARK) on the handle returned by startCheckout |
Do not remount, dismiss or restart the checkout to change the scheme. That reloads the WebView and loses the payment. This is the one way to get this wrong that costs something.
Two caveats on the mobile SDKs:
- A change that lands while the page is still loading may be missed. The SDK hands it over and does not reload the checkout to force it through, so nothing errors and the payment is never interrupted - the page simply keeps the scheme it started with. For a guaranteed scheme, set
appColorSchemebefore the checkout opens. - Whether a device toggle reaches an open checkout depends on the platform. On iOS and on Android it does, while the scheme is automatic and the host's own appearance follows the device. On Android, a host that has never called
AppCompatDelegate.setDefaultNightModeis resolved from its theme once at launch, so a raw device toggle mid-checkout is not followed; drive it yourself withsetAppColorSchemefrom your configuration callback if you need it. On React Native the automatic value is read when you callstart().
This one is not about appColorScheme, and it is not new - but it matters more now that users have a reason to toggle their theme mid-payment.
Your checkout activity needs uiMode in its android:configChanges:
<activity
android:name=".MainActivity"
android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|screenSize|smallestScreenSize|uiMode">Without it, an OS dark-mode toggle destroys and recreates your activity mid-checkout and loses the payment in flight. Flutter's MainActivity template already includes it. This applies to the Flutter and React Native SDKs, which render inside your activity; the native Android SDK owns its own activity and declares this itself.
The property is appColorScheme on every SDK. The query parameter the checkout page reads is colorScheme. The two were not renamed together, so a checkout URL captured from a proxy or a debug log will not match the property name you set. Nothing to configure either way.