# Product Validation MSISDN Fix

## Issue
Validating utility services (UMEME, DSTV, etc.) was failing with:
```json
{
    "success": false,
    "message": "Invalid MSISDN format"
}
```

## Root Cause
The `validateProduct()` method was treating the `msisdn` field as a phone number for ALL services. However, for utility services, the `msisdn` field contains the **account/meter number**, NOT a phone number.

### Example:
```json
{
    "msisdn": "94500953297",  // ← This is UMEME meter number, NOT a phone!
    "product_code": "UMEME_PRE_PAID",
    "contact_phone": "+256768464016"  // ← This is the actual phone number
}
```

## The Problem

**Old Code (BUGGY):**
```php
// ❌ Validated msisdn as phone number
if (!$this->validatePhoneNumber($validationData['msisdn'])) {
    return ['success' => false, 'message' => 'Invalid MSISDN format'];
}

// ❌ Formatted msisdn as phone number
'msisdn' => $this->formatPhoneNumber($validationData['msisdn'])
```

This failed for utility account numbers like:
- `94500953297` (UMEME meter number)
- `123456789` (DSTV smart card number)
- `87654321` (GOTV decoder number)

## The Solution

**New Code (FIXED):**
```php
// ✅ Only validate contact_phone as phone number
if (!$this->validatePhoneNumber($validationData['contact_phone'])) {
    return ['success' => false, 'message' => 'Invalid contact phone format'];
}

// ✅ Send msisdn as-is (could be account number or phone number)
'msisdn' => $validationData['msisdn']  // Send as-is
```

## What Changed

### Removed:
- ❌ Phone number validation for `msisdn` field
- ❌ Phone number formatting for `msisdn` field

### Kept:
- ✅ Phone number validation for `contact_phone` field
- ✅ Phone number formatting for `contact_phone` field

## Field Usage Clarification

| Field | Purpose | Format | Validated |
|-------|---------|--------|-----------|
| `msisdn` | Account/meter number OR phone number | As-is (varies by service) | ❌ No |
| `contact_phone` | Customer phone number for notifications | International (+256...) | ✅ Yes |

## Service Examples

### Utility Services (msisdn = account number)
```json
// UMEME
{
    "msisdn": "94500953297",           // Meter number
    "product_code": "UMEME_PRE_PAID",
    "contact_phone": "+256768464016"   // Customer phone
}

// DSTV
{
    "msisdn": "123456789",             // Smart card number
    "product_code": "DSTV",
    "contact_phone": "+256768464016"   // Customer phone
}
```

### Airtime/Data Services (msisdn = phone number)
```json
// MTN Airtime
{
    "msisdn": "256709713160",          // Phone to receive airtime
    "product_code": "MTN_AIRTIME",
    "contact_phone": "+256768464016"   // Could be same or different
}
```

## Testing

### Test 1: UMEME Validation (Utility Service)
```bash
POST /api/mobile-money/validate-product
{
    "msisdn": "94500953297",
    "amount": 1000,
    "product_code": "UMEME_PRE_PAID",
    "contact_phone": "+256768464016"
}
```

**Expected Response:**
```json
{
    "success": true,
    "validation_reference": "47fca11c9fed2df5",
    "charge": "800.0",
    "customer_name": "HUSSEIN IBRAHIM, MWINYI",
    "balance": "9.0"
}
```

### Test 2: MTN Airtime (Phone Service)
```bash
POST /api/mobile-money/validate-product
{
    "msisdn": "256709713160",
    "amount": 5000,
    "product_code": "MTN_AIRTIME",
    "contact_phone": "+256768464016"
}
```

**Expected Response:**
```json
{
    "success": true,
    "validation_reference": "abc123xyz",
    "customer_name": "John Doe"
}
```

## Relworx API Behavior

Relworx API is flexible with the `msisdn` field:
- For **utilities**: Expects account/meter number as-is
- For **airtime/data**: Expects phone number as-is or with country code
- Relworx handles the interpretation based on `product_code`

Our relay now matches this behavior by sending `msisdn` as-is without validation/formatting.

## Files Modified
- `app/Libraries/MobileMoneyService.php` - Fixed `validateProduct()` method

## Benefits
1. ✅ Utility services (UMEME, DSTV, etc.) now work
2. ✅ Airtime/data services still work
3. ✅ No breaking changes to existing implementations
4. ✅ Matches Relworx API behavior exactly
5. ✅ Customer phone is still validated for notifications