Skip to main content
The Kount SDK supports two environments: Test and Production. Using the correct environment ensures your data goes to the right place during development and after launch.
Critical: Always use ENVIRONMENT_TEST during development and testing. Switch to ENVIRONMENT_PRODUCTION only when deploying to production.

​
Environment Overview

Kount provides separate environments to isolate development activity from real production data:

Test Environment

Purpose: Development, testing, and integration
  • Safe for experimentation
  • No impact on production fraud detection
  • Uses test servers and test data
  • Free to use during integration

Production Environment

Purpose: Live applications with real users
  • Processes real fraud detection
  • Affects your Kount billing
  • Uses production servers
  • Requires valid merchant credentials

​
Setting the Environment

Configure the environment during SDK initialization, before calling collectForSession():

​
Test Environment (Default for Development)

import com.kount.api.KountSDK

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        KountSDK.setMerchantId("999999")
        
        // Set to TEST environment
        KountSDK.setEnvironment(KountSDK.ENVIRONMENT_TEST)
        
        // Safe to experiment
        KountSDK.collectForSession(this, { sessionId ->
            Log.d("Kount", "Test collection: $sessionId")
        }, { _, error -> 
            Log.e("Kount", "Error: $error")
        })
    }
}

​
Production Environment (For Live Apps)

import com.kount.api.KountSDK

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        KountSDK.setMerchantId("YOUR_PRODUCTION_MERCHANT_ID")
        
        // Set to PRODUCTION environment
        KountSDK.setEnvironment(KountSDK.ENVIRONMENT_PRODUCTION)
        
        // Production data collection
        KountSDK.collectForSession(this, { sessionId ->
            Log.d("Kount", "Production collection: $sessionId")
        }, { _, error -> 
            Log.e("Kount", "Error: $error")
        })
    }
}

​
Java Example

import com.kount.api.KountSDK;

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        
        KountSDK.INSTANCE.setMerchantId("999999");
        
        // For development: TEST
        KountSDK.INSTANCE.setEnvironment(KountSDK.ENVIRONMENT_TEST);
        
        // For production: PRODUCTION
        // KountSDK.INSTANCE.setEnvironment(KountSDK.ENVIRONMENT_PRODUCTION);
    }
}
Development tip: Use build variants or build config fields to automatically switch environments based on your build type:
val environment = if (BuildConfig.DEBUG) {
    KountSDK.ENVIRONMENT_TEST
} else {
    KountSDK.ENVIRONMENT_PRODUCTION
}

KountSDK.setEnvironment(environment)

​
Environment Constants

The SDK provides two environment constants:
ConstantValuePurpose
KountSDK.ENVIRONMENT_TEST0Development, QA, and testing
KountSDK.ENVIRONMENT_PRODUCTION1Live production applications
These are integer constants. Don’t use string values or custom numbers—always use the SDK-provided constants.

​
When to Use Each Environment

Use ENVIRONMENT_TEST in these scenarios:
1

Initial Integration

When first integrating the SDK into your app. Test that data collection works without affecting production.
KountSDK.setEnvironment(KountSDK.ENVIRONMENT_TEST)
2

Local Development

During feature development on your local machine or emulator.
3

QA Testing

When your QA team tests the app before release. This includes:
  • Manual testing
  • Automated UI tests
  • Integration tests
4

Beta Releases

For beta builds distributed to testers (TestFlight, Firebase App Distribution, etc.).
5

Staging Environments

If you have a staging server, use TEST environment to match your staging backend.
Test environment data is separate from production and won’t affect your fraud detection models or billing.

​
Build Configuration Patterns

Automate environment switching using Android build configurations:

​
Using Build Types

build.gradle
android {
    buildTypes {
        debug {
            buildConfigField "boolean", "KOUNT_USE_PRODUCTION", "false"
        }
        release {
            buildConfigField "boolean", "KOUNT_USE_PRODUCTION", "true"
        }
    }
}
Then in your code: 
class Application : Application() {
    override fun onCreate() {
        super.onCreate()
        
        val environment = if (BuildConfig.KOUNT_USE_PRODUCTION) {
            KountSDK.ENVIRONMENT_PRODUCTION
        } else {
            KountSDK.ENVIRONMENT_TEST
        }
        
        KountSDK.setEnvironment(environment)
    }
}

​
Using Product Flavors

build.gradle
android {
    flavorDimensions "environment"
    
    productFlavors {
        dev {
            dimension "environment"
            buildConfigField "int", "KOUNT_ENVIRONMENT", "0" // TEST
        }
        prod {
            dimension "environment"
            buildConfigField "int", "KOUNT_ENVIRONMENT", "1" // PRODUCTION
        }
    }
}
In your code: 
KountSDK.setEnvironment(BuildConfig.KOUNT_ENVIRONMENT)

​
Using Remote Config

For maximum flexibility, use Firebase Remote Config or a similar service: 
class Application : Application() {
    override fun onCreate() {
        super.onCreate()
        
        // Fetch from Remote Config
        val useProduction = RemoteConfig.getBoolean("kount_use_production")
        
        val environment = if (useProduction) {
            KountSDK.ENVIRONMENT_PRODUCTION
        } else {
            KountSDK.ENVIRONMENT_TEST
        }
        
        KountSDK.setEnvironment(environment)
    }
}
Security note: Never hard-code production merchant IDs or environment settings in your code. Use build configurations or secure remote config.

​
Displaying Current Environment

It’s helpful to display the current environment in your UI during development: 
class DebugActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        val environmentText = findViewById<TextView>(R.id.environment)
        
        // Display current environment
        val env = when (getCurrentEnvironment()) {
            KountSDK.ENVIRONMENT_TEST -> "Test"
            KountSDK.ENVIRONMENT_PRODUCTION -> "Production"
            else -> "Unknown"
        }
        
        environmentText.text = "Kount Environment: $env"
        
        // Add visual warning for production
        if (getCurrentEnvironment() == KountSDK.ENVIRONMENT_PRODUCTION) {
            environmentText.setTextColor(Color.RED)
            environmentText.setTypeface(null, Typeface.BOLD)
        }
    }
    
    private fun getCurrentEnvironment(): Int {
        // Query SDK configuration
        return KountSDK.getEnvironment() // Hypothetical method
    }
}
Add a visual indicator in debug builds to remind developers which environment is active:
if (BuildConfig.DEBUG) {
    val badge = when (environment) {
        KountSDK.ENVIRONMENT_TEST -> "[TEST]"
        KountSDK.ENVIRONMENT_PRODUCTION -> "[PROD]"
        else -> ""
    }
    supportActionBar?.title = "$badge ${supportActionBar?.title}"
}

​
Environment Differences

Understand how the two environments differ:
Test and production environments use different server URLs. The SDK handles this automatically—you don’t need to configure endpoints manually.
Version 4.3.1 updated the QA environment URL. Always use the latest SDK version for correct endpoint routing.
Data collected in test environment is completely separate from production:
  • Test session IDs only work with test backend queries
  • Production session IDs only work with production queries
  • No cross-environment data sharing
Don’t mix environments: If you collect data in TEST, your backend must query the test environment.
You may have different merchant IDs for test and production:
val merchantId = if (BuildConfig.DEBUG) {
    "999999" // Test merchant ID
} else {
    "YOUR_PROD_ID" // Production merchant ID
}

KountSDK.setMerchantId(merchantId)
  • Test: Free, no billing impact
  • Production: Counts toward your Kount subscription
Both environments have similar performance characteristics. Test servers may occasionally be slower during Kount’s internal testing.

​
Migration from Test to Production

When you’re ready to launch:
1

Verify Test Integration

Ensure your test integration works perfectly:
KountSDK.setEnvironment(KountSDK.ENVIRONMENT_TEST)
KountSDK.collectForSession(this, { sessionId ->
    assert(sessionId.isNotEmpty())
}, { _, _ -> })
2

Update Configuration

Change environment constant and merchant ID:
// Before (Test)
KountSDK.setMerchantId("999999")
KountSDK.setEnvironment(KountSDK.ENVIRONMENT_TEST)

// After (Production)
KountSDK.setMerchantId("YOUR_PRODUCTION_MERCHANT_ID")
KountSDK.setEnvironment(KountSDK.ENVIRONMENT_PRODUCTION)
3

Update Backend

Ensure your backend queries the production environment:
# Update backend configuration
kount_client = KountClient(
    merchant_id="YOUR_PRODUCTION_MERCHANT_ID",
    environment="production"  # Changed from "test"
)
4

Test Production Build

Build a production APK/AAB and test on a real device before releasing:
./gradlew assembleRelease
5

Monitor First Collections

After release, monitor logs to confirm production collections succeed:
KountSDK.collectForSession(this, { sessionId ->
    // Log to analytics service
    analytics.logEvent("kount_collection_success", mapOf(
        "environment" to "production",
        "sessionId" to sessionId
    ))
}, { _, error -> 
    // Alert on production failures
    crashlytics.log("Kount production failure: $error")
})

​
Common Mistakes

Mistake #1: Using production environment during development
// Wrong: This will count toward billing
KountSDK.setEnvironment(KountSDK.ENVIRONMENT_PRODUCTION)
// During development...
Solution: Always use TEST during development.
Mistake #2: Forgetting to switch to production for release
// Wrong: Production app using test environment
KountSDK.setEnvironment(KountSDK.ENVIRONMENT_TEST)
// In Google Play release...
Solution: Use build configurations to automatically switch environments.
Mistake #3: Mixing environments between app and backend
// App: Using TEST
KountSDK.setEnvironment(KountSDK.ENVIRONMENT_TEST)

// Backend: Querying PRODUCTION
kount_client.inquire(environment="production", session_id=sessionId)
// This won't work!
Solution: Keep app and backend environments in sync.
Mistake #4: Using magic numbers instead of constants
// Wrong: Hard-coded environment value
KountSDK.setEnvironment(1)

// Correct: Use SDK constants
KountSDK.setEnvironment(KountSDK.ENVIRONMENT_PRODUCTION)

​
Troubleshooting

Symptom: Backend says session ID doesn’t exist.Cause: App and backend are using different environments.Solution: Verify both app and backend use the same environment (both TEST or both PRODUCTION).
Symptom: Charged for test collections.Cause: Accidentally using PRODUCTION environment in debug builds.Solution: Review build configuration and ensure debug builds use ENVIRONMENT_TEST.
Symptom: Environment change doesn’t take effect.Cause: Calling setEnvironment() after collectForSession() has already started.Solution: Always call setEnvironment() during app initialization, before any collection calls.

​
Best Practices Summary

Use Build Configs

Automate environment switching with build types and flavors. Never manually change environments.

Verify Before Release

Always test production builds before submitting to Play Store. Confirm production environment is active.

Keep Environments Synced

Ensure app and backend use matching environments. Document your environment configuration.

Monitor Production

Log environment and collection status in production. Set up alerts for failures.

​
Next Steps

Configuration Guide

Complete SDK configuration reference

Backend Integration

Learn how to query Kount’s API from your backend

Build Configurations

Set up build variants for automatic environment switching

API Reference

Explore the complete SDK API

Build docs developers (and LLMs) love

Get started for freeTalk to us