# Security and Device Binding

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.

<Callout type="warning">

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

</Callout>

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

---

## Related Resources

* [**Transaction Lifecycle**](/en/get-mini/android-sdk/core-concepts/transaction-lifecycle) – Understand secure transaction flow stages
* [**Quickstart: Your First Sale**](/en/get-mini/android-sdk/first-steps/android-sdk-quickstart) – Login, PIN pad initialization, and payment execution
* [**Add the SDK to Your Project**](/en/get-mini/android-sdk/first-steps/add-sdk-to-project) – Environment configuration and permissions