Getnet DocsGetnet Docs

Understanding the Repository Pattern

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

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.