Getnet DocsGetnet Docs

Security and Device Binding

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page
Connect to CursorUse these docs in CursorConnect to VS CodeUse these docs in VS Code

Security in the Get Mini Android SDK is achieved by delegating all sensitive payment operations to a certified external PIN pad and by enforcing controlled terminal association through backend-managed authentication and activation flows. The Android application acts solely as a host controller and never handles raw card data or cryptographic keys.

This document describes the actual security and association mechanisms implemented by the Android SDK, based on the login and transparent login (device activation) system.

Terminal Association Model

The Android SDK security model ensures that each terminal configuration (merchant and terminal identifiers) can only be operated by authorized devices and users. This prevents unauthorized use of merchant credentials and enforces accountability for all transactions processed through the SDK.

Terminal association in Get Mini Android SDK is administrative and logical, not hardware-based. It is managed by the backend and enforced through controlled login and activation procedures.

Terminal Identifiers

Each Get Mini terminal is identified by two mandatory parameters:

  • FUC (Merchant Identifier) – Uniquely identifies the merchant within the authorization system (e.g., a unique merchant code).
  • Terminal Number – Identifies a specific logical terminal under the merchant account (values from 1 to 99).

Additional terminal metadata includes:

  • NSerie – Serial number of the terminal
  • Type – Terminal type (Virtual = 1, PC = 2)
  • Csb – Terminal entity identifier
  • Currency – Numeric currency code (e.g., 978 for EUR)

These identifiers are assigned during merchant onboarding and are returned to the application as part of the login response in RedCLSTerminalData objects. All payment operations require a valid combination of FUC and Terminal Number.

Device Authorization and Login Binding

Before a terminal can be used on an Android device, it must be explicitly authorized through the Android SDK login mechanisms.

The SDK supports the following authorization flows:

Credential-Based Login

The standard login method authenticates users with username and password:

RedCLSLoginSsmResponse response =
    RedCLSMerchantConfigurationManager.login(loginData);

This returns:

  • A list of merchants (RedCLSMerchantData) the user has access to
  • For each merchant, a list of terminals (RedCLSTerminalData) available for operations
  • User metadata (password expiration, user type)

The application cannot perform payment operations without a successful login and valid terminal selection.

Transparent Login (Device Activation)

Transparent login allows a device to operate terminals without requiring username/password on every launch. This is a three-step process:

1. Initial Activation Request

After a successful credential-based login, the application can request device activation for specific terminals:

RedCLSLoginTransLoginResponse response =
    RedCLSMerchantConfigurationManager.autoLogin(context, autoLoginData);

The RedCLSLoginTransAutoLoginData object contains:

  • The list of terminals to activate (List<RedCLSTerminalData>)
  • The original login data and response
  • An optional email notification flag (typically false)

This creates a device activation request that must be approved by the merchant administrator.

2. Administrator Approval

The merchant administrator receives the activation request and must explicitly approve it through the merchant administration portal. Until approval, the device cannot use transparent login.

3. Subsequent Logins Without Credentials

Once approved, the device can retrieve terminal data on subsequent launches without credentials:

RedCLSLoginTransLoginResponse response =
    RedCLSMerchantConfigurationManager.loginWithoutUser(context);

This returns the same terminal data structure as the credential-based login, allowing the application to proceed with payment operations.

Adding Additional Terminals

After initial activation, additional terminals can be added to an already-activated device:

ResponseData response =
    RedCLSMerchantConfigurationManager.addTerminal(context, terminalData);

This requires administrator approval before the new terminal appears in subsequent loginWithoutUser() responses.

Deactivating Transparent Login

To remove device authorization:

RedCLSMerchantConfigurationManager.disableLoginTrans(context);

This unbinds the device from all activated terminals, requiring a new activation process to restore access.

Cryptographic Key Management

In the Android SDK architecture, all cryptographic operations are executed on the external PIN pad.

The following operations:

  • Card data capture (EMV, contactless, magnetic stripe)
  • PIN entry and verification
  • EMV transaction processing
  • Encryption and secure key usage

are performed entirely within the certified PIN pad hardware.

Key Storage and Loading

Cryptographic keys are stored in secure “drawers” (cajones) within the PIN pad. During initialization (inicializarPinpad()), the SDK reports:

  • estadoUltimaCargaClaves – Status of the last key load operation

    • 0 = No keys uploaded to the PIN pad
    • 1 = Keys loaded correctly

  • Cajones – List of available key drawers, each containing:

    • Key version information (CI, CA, CTC, CPIN)
    • Control values for each key type
    • Key loading status (0 = loaded correctly, 1 = not loaded)

If key updates are required, the SDK handles this transparently during initialization. The application never accesses or manages these keys directly.

What Your Application Handles

As a result of this architecture:

  • The Android application never accesses raw card data.
  • No encryption keys exist in the application process or device storage.
  • The application only receives masked card numbers and transaction identifiers suitable for receipts and record-keeping.

Security Best Practices

When implementing the Get Mini Android SDK, follow these guidelines:

  • Never store or log card data. Use only the masked values and identifiers returned in RedCLSTransactionData (e.g., masked card numbers, authorization codes, transaction references).
  • Enforce user authentication within your application before allowing payment operations.
  • Separate environments strictly. Use integration or certification (CCAL) terminals for development and testing, and production terminals only in live environments.
  • Handle error codes explicitly. Always evaluate the status field and error codes from RedCLSErrorCodes before assuming a transaction outcome.
  • Keep the SDK updated to benefit from security fixes and protocol updates.
  • Protect login credentials. Never hardcode usernames or passwords in your application code.
  • Use transparent login carefully. Only activate production terminals on production devices, as deactivation requires administrative action.

Environment Considerations

The Android SDK supports multiple execution environments, configured via:

RedCLSConfigurationLibrary.setiEntorno(environment);

Available environments:

  • ENTORNO_DESARROLLO – Development (reserved for internal use)
  • ENTORNO_INTEGRACION – Integration testing
  • ENTORNO_CCAL – Certification environment
  • ENTORNO_REAL – Production

Each environment has its own:

  • Terminal configurations and credentials
  • Backend authorization systems
  • Key management infrastructure

Terminal associations are environment-specific and cannot be reused across environments.

Always use non-production credentials during development and testing. Activating production terminals on development devices may require administrative intervention to undo.

During development, always initialize the SDK with non-production environments to avoid accidental binding or live transaction processing.