# PSP (Payment Service Provider) Project

This project is a multi-module Android application designed to provide payment and printing services on specialized POS hardware. It uses a modular architecture to separate core logic, hardware SDKs, and different application variants.

## Module Structure

### Core Modules
*   **`:core`**: The backbone of the project. Contains shared domain models (`PaymentResultEntity`, `PrintEntity`), interfaces for services (`PspService`, `Printer`), and common utilities. It has no dependencies on other modules.
*   **`:design_system`**: Contains shared UI components and utilities. The most critical component is `PspWebView`, a highly optimized WebView wrapper used across all app variants for rendering the web-based POS interface. It depends on `:core`.

### Hardware Implementation Modules
These modules contain the specific SDK integrations for different POS hardware.
*   **`:p3`**: Implementation of `PspService` and `Printer` for P3 hardware. Includes SDK-specific logic for handling payments and thermal printing.
*   **`:ps4`**: Implementation for PS4 hardware variants.

### Application Variants
*   **`:app`**: The primary production application.
*   **`:tis_app`**: A specialized version of the application targeting the TIS environment (`https://tis.shift-am.ir`).
*   **`:stage_app`**: A development and staging variant used for testing. It often uses mock implementations (like `StageViewModel`) to simulate POS behavior without requiring physical hardware.

## Architecture & Relationships

```mermaid
graph TD
    subgraph Apps
        tis_app --> core
        tis_app --> design_system
        stage_app --> core
        stage_app --> design_system
        app --> core
        app --> design_system
    end

    subgraph Hardware SDKs
        p3 --> core
        ps4 --> core
    end

    design_system --> core
```

1.  **Dependency Inversion**: Apps depend on interfaces defined in `:core`. The actual hardware implementation (`:p3` or `:ps4`) is injected via Hilt, allowing the same app logic to run on different devices.
2.  **Web-Native Bridge**: The `design_system` module provides `PspJavaScriptInterface`, which allows the Web POS (running inside `PspWebView`) to communicate with native hardware features like the printer and payment terminal.
3.  **Hardware Performance**: The WebView is optimized for weak POS hardware with features like pooled instances, hardware acceleration, and lean rendering profiles.

## Key Features
*   **Thermal Printing**: Optimized for RTL (Persian) text and high-performance bitmap rendering for logos (including VectorDrawable support).
*   **Payment Integration**: Standardized bridge for processing payments and returning structured results to the web-front-end.
*   **Weak Hardware Optimization**: Custom WebView configurations to handle smooth animations (drawers/sheets) on low-spec devices.