diff --git a/.gitignore b/.gitignore
index 906b659..2a26295 100755
--- a/.gitignore
+++ b/.gitignore
@@ -42,4 +42,5 @@ success_report.md
 check_output*.txt
 check_detailed.txt
 api_check_detailed.txt
+dock.txt
 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c65b942..615ddc0 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,42 +1,648 @@
 # Contributing to Payego
 
-Thank you for your interest in contributing to Payego! We welcome contributions from everyone.
-
-## Development Workflow
-
-1.  **Fork and Clone**: Fork the repository and clone it locally.
-2.  **Branching**: Create a new branch for your feature or bugfix.
-    ```bash
-    git checkout -b feature/amazing-feature
-    ```
-3.  **Backend Development**:
-    -   Code is in `src/`, `crates/`, and `bin/`.
-    -   Run tests: `cargo test`
-    -   Check linting: `cargo clippy`
-    -   Check formatting: `cargo fmt`
-4.  **Frontend Development**:
-    -   Code is in `payego_ui/`.
-    -   Run dev server: `npm run dev`
-    -   Run tests: `npm run test`
-    -   Run linting: `npm run lint`
-
-## Pull Request Process
-
-1.  Ensure all local tests pass.
-2.  Commit your changes with clear, descriptive commit messages.
-3.  Push to your fork and submit a Pull Request to the `main` branch.
-4.  Our CI pipeline will automatically run to verify your changes.
-
-## Code Style
-
--   **Rust**: Follow standard Rust conventions (`rustfmt`).
--   **JavaScript/React**: Follow ESLint configuration in `payego_ui`.
-
-## Architecture Guide
-
--   **payego-api** (`crates/api`): HTTP handlers and routing.
--   **payego-core** (`crates/core`): Business logic and services.
--   **payego-primitives** (`crates/primitives`): Shared types, DTOs, and errors.
--   **payego-ui** (`payego_ui`): React frontend.
-
-Happy Coding! 🚀
+Thank you for your interest in contributing to Payego! We welcome contributions from everyone and appreciate your help in making this project better.
+
+## 📋 Table of Contents
+
+- [Code of Conduct](#code-of-conduct)
+- [Getting Started](#getting-started)
+- [Development Workflow](#development-workflow)
+- [Testing Requirements](#testing-requirements)
+- [Code Quality Standards](#code-quality-standards)
+- [Pull Request Process](#pull-request-process)
+- [Commit Message Guidelines](#commit-message-guidelines)
+- [Architecture Overview](#architecture-overview)
+- [Security Guidelines](#security-guidelines)
+- [Documentation Standards](#documentation-standards)
+- [Getting Help](#getting-help)
+
+---
+
+## 🤝 Code of Conduct
+
+### Our Pledge
+
+We are committed to providing a welcoming and inclusive environment for all contributors, regardless of experience level, background, or identity.
+
+### Expected Behavior
+
+- Be respectful and considerate
+- Use welcoming and inclusive language
+- Accept constructive criticism gracefully
+- Focus on what's best for the project
+- Show empathy towards other contributors
+
+### Unacceptable Behavior
+
+- Harassment, trolling, or discriminatory comments
+- Personal attacks or insults
+- Publishing others' private information
+- Any conduct that would be inappropriate in a professional setting
+
+---
+
+## 🚀 Getting Started
+
+### Prerequisites
+
+Ensure you have the following installed:
+- **Rust**: v1.75+ (`rustup update`)
+- **Node.js**: v18+
+- **PostgreSQL**: v15+
+- **Diesel CLI**: `cargo install diesel_cli --no-default-features --features postgres`
+- **Git**: Latest version
+
+### Initial Setup
+
+1. **Fork the Repository**
+   ```bash
+   # Click "Fork" on GitHub, then clone your fork
+   git clone https://github.com/YOUR_USERNAME/payego.git
+   cd payego
+   ```
+
+2. **Add Upstream Remote**
+   ```bash
+   git remote add upstream https://github.com/intelliDean/payego.git
+   ```
+
+3. **Environment Configuration**
+   ```bash
+   cp .env.example .env
+   ```
+   
+   Edit `.env` and configure:
+   - Database credentials
+   - JWT secret (32+ characters)
+   - Payment provider keys (Stripe, PayPal, Paystack)
+   - CORS origins
+
+4. **Database Setup**
+   ```bash
+   # Create database
+   diesel setup
+   
+   # Run migrations
+   diesel migration run
+   ```
+
+5. **Install Dependencies**
+   
+   **Backend:**
+   ```bash
+   cargo build
+   ```
+   
+   **Frontend:**
+   ```bash
+   cd payego_ui
+   npm install
+   ```
+
+6. **Verify Setup**
+   
+   **Backend:**
+   ```bash
+   cargo test --workspace
+   cargo run
+   ```
+   
+   **Frontend:**
+   ```bash
+   cd payego_ui
+   npm test
+   npm run dev
+   ```
+
+---
+
+## 🔄 Development Workflow
+
+### 1. Create a Feature Branch
+
+Always create a new branch for your work:
+```bash
+git checkout -b feature/your-feature-name
+# or
+git checkout -b fix/bug-description
+```
+
+**Branch naming conventions:**
+- `feature/` - New features
+- `fix/` - Bug fixes
+- `docs/` - Documentation changes
+- `refactor/` - Code refactoring
+- `test/` - Adding or updating tests
+- `chore/` - Maintenance tasks
+
+### 2. Make Your Changes
+
+**Backend Development:**
+- Code location: `crates/api`, `crates/core`, `crates/primitives`
+- Run tests: `cargo test --workspace`
+- Check linting: `cargo clippy --workspace --tests -- -D warnings`
+- Format code: `cargo fmt --all`
+
+**Frontend Development:**
+- Code location: `payego_ui/src`
+- Run dev server: `npm run dev`
+- Run tests: `npm test`
+- Run linting: `npm run lint`
+- Build: `npm run build`
+
+### 3. Keep Your Branch Updated
+
+Regularly sync with upstream:
+```bash
+git fetch upstream
+git rebase upstream/main
+```
+
+### 4. Commit Your Changes
+
+Follow our [commit message guidelines](#commit-message-guidelines):
+```bash
+git add .
+git commit -m "feat: add user profile endpoint"
+```
+
+### 5. Push and Create PR
+
+```bash
+git push origin feature/your-feature-name
+```
+
+Then create a Pull Request on GitHub.
+
+---
+
+## 🧪 Testing Requirements
+
+### Backend Tests
+
+**Required:**
+- Write integration tests for new API endpoints
+- Write unit tests for service layer logic
+- Ensure all existing tests pass
+
+**Running tests:**
+```bash
+# All tests
+cargo test --workspace
+
+# Specific test file
+cargo test --test auth_tests
+
+# With output
+cargo test -- --nocapture
+```
+
+**Test categories:**
+- `bin/payego/tests/` - Integration tests
+- Service unit tests - In service modules
+
+**Example test:**
+```rust
+#[tokio::test]
+async fn test_user_registration() {
+    let app = setup_test_app().await;
+    let response = app.register_user("test@example.com", "password123").await;
+    assert_eq!(response.status(), StatusCode::CREATED);
+}
+```
+
+### Frontend Tests
+
+**Required:**
+- Write tests for new components
+- Test error handling scenarios
+- Ensure all existing tests pass
+
+**Running tests:**
+```bash
+cd payego_ui
+npm test
+
+# With coverage
+npm test -- --coverage
+
+# Watch mode
+npm test -- --watch
+```
+
+**Test utilities:**
+Use `test-utils.tsx` for component tests:
+```typescript
+import { render, screen } from '../utils/test-utils';
+
+test('renders login form', () => {
+  render(<LoginForm />);
+  expect(screen.getByLabelText(/email/i)).toBeInTheDocument();
+});
+```
+
+### Test Coverage Expectations
+
+- **Backend**: Maintain 70%+ coverage for service layer
+- **Frontend**: Aim for 60%+ coverage for components
+- **Critical paths**: 100% coverage (auth, payments, transfers)
+
+---
+
+## ✅ Code Quality Standards
+
+### Rust Code Quality
+
+**1. Run Clippy (Required)**
+```bash
+cargo clippy --workspace --tests -- -D warnings
+```
+
+All Clippy warnings must be resolved before PR approval.
+
+**2. Format Code (Required)**
+```bash
+cargo fmt --all
+```
+
+**3. Follow Rust Conventions**
+- Use `snake_case` for functions and variables
+- Use `PascalCase` for types and traits
+- Add doc comments for public APIs
+- Avoid `unwrap()` - use proper error handling
+
+**4. Error Handling**
+- Use `Result<T, ApiError>` for all fallible operations
+- Never use `panic!` in production code
+- Log errors appropriately (WARN for expected, ERROR for unexpected)
+
+**5. Security**
+- Wrap secrets in `secrecy::Secret<T>`
+- Never log sensitive data
+- Validate all user input
+
+### Frontend Code Quality
+
+**1. Run Linter (Required)**
+```bash
+npm run lint
+```
+
+**2. TypeScript**
+- Enable strict mode
+- Avoid `any` types
+- Use proper type definitions
+
+**3. Component Standards**
+- Use functional components with hooks
+- Extract reusable logic into custom hooks
+- Keep components focused and small
+
+**4. Error Handling**
+- Use centralized error handler (`errorHandler.ts`)
+- Display user-friendly error messages
+- Log errors for debugging
+
+---
+
+## 📝 Pull Request Process
+
+### Before Submitting
+
+**Checklist:**
+- [ ] All tests pass (`cargo test`, `npm test`)
+- [ ] Code is formatted (`cargo fmt`, `npm run lint`)
+- [ ] No Clippy warnings (`cargo clippy`)
+- [ ] Added tests for new functionality
+- [ ] Updated documentation if needed
+- [ ] Commit messages follow conventions
+- [ ] Branch is up-to-date with `main`
+
+### PR Description Template
+
+```markdown
+## Description
+Brief description of changes
+
+## Type of Change
+- [ ] Bug fix
+- [ ] New feature
+- [ ] Breaking change
+- [ ] Documentation update
+
+## Testing
+How was this tested?
+
+## Checklist
+- [ ] Tests added/updated
+- [ ] Documentation updated
+- [ ] No breaking changes (or documented)
+```
+
+### Review Process
+
+1. **Automated Checks**: CI runs tests and linting
+2. **Code Review**: Maintainer reviews code
+3. **Feedback**: Address review comments
+4. **Approval**: PR approved by maintainer
+5. **Merge**: Squash and merge to main
+
+**Expected timeline:** 2-5 business days for initial review
+
+---
+
+## 💬 Commit Message Guidelines
+
+We follow [Conventional Commits](https://www.conventionalcommits.org/).
+
+### Format
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+<footer>
+```
+
+### Types
+
+- `feat`: New feature
+- `fix`: Bug fix
+- `docs`: Documentation changes
+- `style`: Code style changes (formatting)
+- `refactor`: Code refactoring
+- `test`: Adding or updating tests
+- `chore`: Maintenance tasks
+
+### Examples
+
+**Good:**
+```
+feat(auth): add email verification flow
+
+Implements email verification with expiring tokens.
+Users receive verification emails upon registration.
+
+Closes #123
+```
+
+**Bad:**
+```
+updated stuff
+```
+
+### Rules
+
+- Use present tense ("add" not "added")
+- Use imperative mood ("move" not "moves")
+- Keep subject line under 72 characters
+- Reference issues in footer
+
+---
+
+## 🏗️ Architecture Overview
+
+### Crate Structure
+
+```
+payego/
+├── bin/payego/          # Main binary
+├── crates/
+│   ├── api/             # HTTP handlers
+│   ├── core/            # Business logic
+│   └── primitives/      # Shared types
+└── payego_ui/           # React frontend
+```
+
+### Backend Layers
+
+**1. API Layer** (`crates/api`)
+- HTTP handlers
+- Request/response parsing
+- Route definitions
+- OpenAPI documentation
+
+**2. Core Layer** (`crates/core`)
+- Business logic services
+- External API clients
+- Database operations
+- Email service
+
+**3. Primitives Layer** (`crates/primitives`)
+- Database entities
+- DTOs (Data Transfer Objects)
+- Error types
+- Shared utilities
+
+### Key Patterns
+
+**Service Layer Pattern:**
+```rust
+pub struct TransferService {
+    db: Arc<DatabaseConnection>,
+}
+
+impl TransferService {
+    pub async fn transfer_internal(
+        &self,
+        request: TransferRequest,
+    ) -> Result<Transaction, ApiError> {
+        // Business logic here
+    }
+}
+```
+
+**Entity vs DTO Separation:**
+- **Entities**: Database models (internal only)
+- **DTOs**: API contracts (public-facing)
+- Never expose entities directly in API responses
+
+**Error Handling:**
+```rust
+pub enum ApiError {
+    NotFound(String),
+    Unauthorized,
+    ValidationError(Vec<String>),
+    // ...
+}
+```
+
+### Frontend Architecture
+
+**Component Structure:**
+- Keep components small and focused
+- Extract business logic into hooks
+- Use React Query for server state
+- Use Context API for auth state
+
+**Error Handling:**
+```typescript
+import { getErrorMessage } from '../utils/errorHandler';
+
+try {
+  await api.login(credentials);
+} catch (err) {
+  setError(getErrorMessage(err));
+}
+```
+
+---
+
+## 🔒 Security Guidelines
+
+### Handling Secrets
+
+**DO:**
+- Use `secrecy::Secret<String>` for sensitive data
+- Store secrets in environment variables
+- Use `.env` file locally (never commit!)
+
+**DON'T:**
+- Hardcode secrets in code
+- Log sensitive information
+- Commit `.env` files
+
+### Reporting Vulnerabilities
+
+**If you discover a security vulnerability:**
+1. **DO NOT** open a public issue
+2. Email the maintainer directly
+3. Include detailed description and reproduction steps
+4. Allow time for fix before public disclosure
+
+### Security Best Practices
+
+- Validate all user input
+- Use parameterized queries (Diesel handles this)
+- Implement rate limiting
+- Use HTTPS in production
+- Keep dependencies updated
+
+---
+
+## 📚 Documentation Standards
+
+### Code Comments
+
+**Rust:**
+```rust
+/// Transfers funds between internal Payego users
+///
+/// # Arguments
+/// * `from_user_id` - Source user ID
+/// * `to_username` - Destination username
+/// * `amount` - Transfer amount
+///
+/// # Returns
+/// Transaction record on success
+///
+/// # Errors
+/// Returns `ApiError::InsufficientBalance` if sender lacks funds
+pub async fn transfer_internal(
+    &self,
+    from_user_id: Uuid,
+    to_username: &str,
+    amount: Decimal,
+) -> Result<Transaction, ApiError> {
+    // Implementation
+}
+```
+
+**TypeScript:**
+```typescript
+/**
+ * Extracts user-friendly error message from API error
+ * @param error - Axios error or generic error object
+ * @returns User-friendly error message string
+ */
+export function getErrorMessage(error: any): string {
+  // Implementation
+}
+```
+
+### API Documentation
+
+**OpenAPI/Swagger:**
+- Document all endpoints with `#[utoipa::path]`
+- Include request/response examples
+- Document all status codes
+- Add parameter descriptions
+
+**Example:**
+```rust
+#[utoipa::path(
+    post,
+    path = "/api/auth/login",
+    request_body = LoginRequest,
+    responses(
+        (status = 200, description = "Login successful", body = AuthResponse),
+        (status = 401, description = "Invalid credentials"),
+    ),
+    tag = "Authentication"
+)]
+pub async fn login(/* ... */) -> Result<Json<AuthResponse>, ApiError> {
+    // Implementation
+}
+```
+
+### README Updates
+
+If your changes affect:
+- Setup process → Update README.md
+- Docker deployment → Update README.Docker.md
+- Contributing process → Update CONTRIBUTING.md
+
+---
+
+## 🆘 Getting Help
+
+### Resources
+
+- **Main README**: [README.md](README.md)
+- **Docker Guide**: [README.Docker.md](README.Docker.md)
+- **API Docs**: http://localhost:8080/swagger-ui/ (when running)
+
+### Questions?
+
+- Open a GitHub Discussion for general questions
+- Open an issue for bug reports
+- Check existing issues before creating new ones
+
+### Development Tips
+
+**Debugging Backend:**
+```bash
+# Enable debug logging
+RUST_LOG=debug cargo run
+
+# View database queries
+RUST_LOG=diesel=debug cargo run
+```
+
+**Debugging Frontend:**
+```bash
+# Check React Query cache
+# Install React Query DevTools (already configured)
+```
+
+**Database Inspection:**
+```bash
+# Connect to database
+diesel database reset  # Careful: drops all data!
+psql -U postgres -d payego
+```
+
+---
+
+## 🎉 Thank You!
+
+Your contributions make Payego better for everyone. We appreciate your time and effort!
+
+**Happy Coding!** 🚀
+
+---
+
+## 📄 License
+
+By contributing to Payego, you agree that your contributions will be licensed under the MIT License.
diff --git a/dock.txt b/dock.txt
deleted file mode 100755
index e9fc766..0000000
--- a/dock.txt
+++ /dev/null
@@ -1,194 +0,0 @@
-# syntax=docker/dockerfile:1
-
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Dockerfile reference guide at
-# https://docs.docker.com/go/dockerfile-reference/
-
-# Want to help us make this template better? Share your feedback here: https://forms.gle/ybq9Krt8jtBL3iCk7
-
-ARG RUST_VERSION=1.89.0
-ARG APP_NAME=payego
-
-################################################################################
-# Create a stage for building the application.
-
-FROM rust:${RUST_VERSION}-alpine AS build
-ARG APP_NAME
-WORKDIR /app
-
-# Install host build dependencies.
-RUN apk add --no-cache clang lld musl-dev git
-
-# Build the application.
-# Leverage a cache mount to /usr/local/cargo/registry/
-# for downloaded dependencies, a cache mount to /usr/local/cargo/git/db
-# for git repository dependencies, and a cache mount to /app/target/ for
-# compiled dependencies which will speed up subsequent builds.
-# Leverage a bind mount to the src directory to avoid having to copy the
-# source code into the container. Once built, copy the executable to an
-# output directory before the cache mounted /app/target is unmounted.
-RUN --mount=type=bind,source=src,target=src \
-    --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
-    --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
-    --mount=type=cache,target=/app/target/ \
-    --mount=type=cache,target=/usr/local/cargo/git/db \
-    --mount=type=cache,target=/usr/local/cargo/registry/ \
-cargo build --locked --release && \
-cp ./target/release/$APP_NAME /bin/server
-
-################################################################################
-# Create a new stage for running the application that contains the minimal
-# runtime dependencies for the application. This often uses a different base
-# image from the build stage where the necessary files are copied from the build
-# stage.
-#
-# The example below uses the alpine image as the foundation for running the app.
-# By specifying the "3.18" tag, it will use version 3.18 of alpine. If
-# reproducibility is important, consider using a digest
-# (e.g., alpine@sha256:664888ac9cfd28068e062c991ebcff4b4c7307dc8dd4df9e728bedde5c449d91).
-FROM alpine:3.18 AS final
-
-# Create a non-privileged user that the app will run under.
-# See https://docs.docker.com/go/dockerfile-user-best-practices/
-ARG UID=10001
-RUN adduser \
-    --disabled-password \
-    --gecos "" \
-    --home "/nonexistent" \
-    --shell "/sbin/nologin" \
-    --no-create-home \
-    --uid "${UID}" \
-    appuser
-USER appuser
-
-# Copy the executable from the "build" stage.
-COPY --from=build /bin/server /bin/
-
-# Expose the port that the application listens on.
-EXPOSE 8080
-
-# What the container should run when it is started.
-CMD ["/bin/server"]
-
-
-
-
-//=================
-
-
-
-# Comments are provided throughout this file to help you get started.
-# If you need more help, visit the Docker Compose reference guide at
-# https://docs.docker.com/go/compose-spec-reference/
-
-# Here the instructions define your application as a service called "server".
-# This service is built from the Dockerfile in the current directory.
-# You can add other services your application may depend on here, such as a
-# database or a cache. For examples, see the Awesome Compose repository:
-# https://github.com/docker/awesome-compose
-services:
-  server:
-    build:
-      context: .
-      target: final
-    ports:
-      - 8080:8080
-
-# The commented out section below is an example of how to define a PostgreSQL
-# database that your application can use. `depends_on` tells Docker Compose to
-# start the database before your application. The `db-data` volume persists the
-# database data between container restarts. The `db-password` secret is used
-# to set the database password. You must create `db/password.txt` and add
-# a password of your choosing to it before running `docker compose up`.
-#     depends_on:
-#       db:
-#         condition: service_healthy
-#   db:
-#     image: postgres
-#     restart: always
-#     user: postgres
-#     secrets:
-#       - db-password
-#     volumes:
-#       - db-data:/var/lib/postgresql/data
-#     environment:
-#       - POSTGRES_DB=example
-#       - POSTGRES_PASSWORD_FILE=/run/secrets/db-password
-#     expose:
-#       - 5432
-#     healthcheck:
-#       test: [ "CMD", "pg_isready" ]
-#       interval: 10s
-#       timeout: 5s
-#       retries: 5
-# volumes:
-#   db-data:
-# secrets:
-#   db-password:
-#     file: db/password.txt
-
-
-
-
-//===========
-
-I had a 2 weeks break from work and after spending few days to sleep and rest, I thought of using this spare time to build something simple
-and when i was done with the ideation i chose Rust as the language for the backend and also because i love doing hard stuff. I wanted to
-bring the global payment gateways together in one project so i thought of a fintech project that helps a user manage all of his currencies, convert
-one currency to the other, transfer funds between user and withdraw those currencies into local bank accounts amongst many other features
-and i gave birth to PAYEGO.
-PAYEGO is a secure, user-friendly fintech wallet app designed to make managing digital funds a breeze! 🎉
-Tailored for African markets (supporting NGN alongside USD, EUR, GBP) but globally accessible
-
-
-after this project i understood 2 things.
-1. i understand why lots of people are running away from Rust.
-2. i learnt that there's no better language to write a fintech project than RUST.
-
-why RUST?
-Rust is a game-changer for this fintech project. Here’s why:
-Safety First: Rust’s strict compile-time checks for memory safety and concurrency prevented bugs like null pointer errors or race conditions,
-critical for handling sensitive financial data and concurrent transactions.
-Performance: Rust’s zero-cost abstractions and low-level control delivered blazing-fast API responses, ensuring endpoints handle high traffic efficiently.
-Reliability: Rust’s type system and error handling (e.g., Result and Option) made it easier to build robust APIs with predictable behavior
-Ecosystem Fit: Libraries like Axum, Utoipa, and Diesel provided a modern, type-safe foundation for building secure, scalable fintech APIs
-etc
-
-
-
-anyway, let's talk about PAYEGO
-with payego, user...
-can can keep difference currencies in their wallet,
-can add money to their wallet in any currency
-can transfer any currency to another user
-can concert any currency to another currency with real time exchange rate
-can convert any currency to naira and withdraw it directly into your naira account
-can any currency to naira and send the naira to any nigerian bank account
-etc
-
-all the tools that made this happen
-RUST programming language
-Axum: Rust Web framework
-Diesel: ORM for PostgreSQL
-PostgreSQL: Managed with Diesel migrations for schemas
-Utoipa: OpenAPI documentation for clear API specs.
-Jsonwebtoken: JWT creation and verification with blacklisting for secure logout.
-Reqwest: HTTP requests for external APIs.
-Paypal SDK
-Stripe SDK
-Paystack SDK
-React
-Tailwind
-Axios: API calls with JWT headers for secure endpoints.
-
-Key Learnings
-Building Payego was a deep dive into fintech development. Here’s what I learned:
-
-Rust’s Power: Rust’s type safety and error handling made complex operations (e.g., atomic wallet updates) reliable, while Axum’s async model scaled effortlessly.
-Fintech Challenges: Supporting African markets (e.g., NGN) required careful currency handling and compliance with payment gateway restrictions.
-
-Payego is open to contribution, for example, i hurriedly wrote the frontend so it's not in it's best state, it can get better.
- also the backend could be improved.
-
- I’d love your feedback on features, UX, or potential improvements.
- What fintech projects are you working on? Let’s connect and discuss! 🌍💸 #Fintech #Rust #React #Stripe #PayPal #Paystack #DieselORM #Axum