# Understanding the Repository Pattern

The Get Smart SDK (`redsys-tpv-business-lib`) is designed around the **Repository Pattern**, a standard in modern Android development that fits naturally into MVVM and Clean Architecture projects.

Instead of exposing low-level service calls directly to your Activities or Fragments, the SDK groups operations into focused repository interfaces (e.g., `InitializationRepository`, `PaymentRepository`, `RefundRepository`, `TransactionRepository`).

## High-Level Architecture

The repository acts as a secure abstraction layer between your application and the Get Smart SDK Payment Service (the background service running on the device).

At a high level, each repository:

- Wraps all communication with the **Get Smart SDK Payment Service** installed on the device.
- Exposes **Kotlin `suspend` functions** that always return a `RepositoryResult<T>` wrapper.
- Automatically moves execution to `Dispatchers.IO`, keeping your main thread free from blocking I/O operations.
- Keeps your UI layer and UseCases independent of the underlying implementation.

### Benefits for your architecture

Using repositories in this way provides several concrete advantages:

- **Decoupling**: Your app depends only on repository interfaces (contracts), not on concrete implementation classes or the service protocol
- **Dependency Injection ready**: Repositories are designed to be provided as singletons via **Dagger Hilt** (or manually via `RepositoryProvider`), keeping your composition root clean.
- **Testability**: Because the SDK is interface-based, you can replace real repositories with fakes or mocks in your unit tests without needing a physical TPV or the Payment Service.
- **Thread safety**: Since all operations are suspend functions that delegate to safe background dispatchers, you do not need to manually manage threads or callbacks.

### Typical usage flow

In a typical MVVM setup:

1. Your DI container (for example a Hilt module) creates a single `RepositoryProvider` instance with the Application `Context`.
2. The provider exposes concrete repository instances such as `initializationRepository`, `paymentRepository`, `transactionRepository`, and so on.
3. ViewModels receive these repositories via constructor injection and call their suspend functions from coroutines.
4. Each call returns a `RepositoryResult<T>` that the ViewModel converts into UI state.

For more details on how to wire repositories into your DI graph, see **`First Steps / Configure Dependency Injection`**. For the semantics of the `RepositoryResult<T>` wrapper and how to interpret its different branches, see **`Core Concepts / Handle Responses and Errors`** and **`Reference / Response and Error Codes`**.