# Audit Session Summary - 6 January 2026

**Event:** Mohamed Abdo NYE 2025
**Session Focus:** Deep POS Reconciliation Analysis + Revolut API Investigation
**Continuation of:** 5 January 2026 session

---

## SESSION OBJECTIVES

1. Deep dive into POS vs Revolut discrepancies using data analytics methodologies
2. Match card payments to DB orders using multiple matching algorithms
3. Identify patterns (multi-payment, price overrides, duplicate accounting)
4. **NEW**: Query Revolut API for cardholder names to match to DB customers

---

## CRITICAL FINDING: Cardholder Name Matching NOT POSSIBLE

### API Investigation Results

**Tested**: Revolut Merchant API v1.0 with versioning headers
**Endpoint**: `https://merchant.revolut.com/api/1.0/orders/{id}`
**Auth**: Bearer token from `.env` (`sk_91dAixy...`)

### CARD_PRESENT (POS Terminal) Payments Return:

```json
{
  "payment_method": {
    "type": "CARD_PRESENT"
  }
  // NO email, phone, billing_address, cardholder_name, card details
}
```

**Available fields**: id, state, amount, timestamp, fees
**NOT available**: cardholder_name, email, phone, billing_address, card_last_four, card_brand

### ONLINE (APPLE_PAY, CARD) Payments Return:

```json
{
  "email": "user@email.com",
  "phone": "+44...",
  "billing_address": {...},
  "payment_method": {
    "type": "APPLE_PAY",
    "card": {
      "card_brand": "VISA",
      "card_last_four": "1234"
    }
  }
}
```

### Conclusion

**POS payments via Revolut Reader DO NOT capture cardholder information in the API.**

This is a limitation of the Revolut Reader hardware integration - it processes card taps without capturing or exposing cardholder identity data through their merchant API.

---

## METHODOLOGIES APPLIED

### Data Analytics Techniques Used

1. **Exact Match** - Amount + time window (baseline)
2. **Sequential/Ordinal Match** - Nth order = Nth payment per day
3. **Amount Tolerance (Fuzzy)** - Allow ±5% or ±£100 variance
4. **Ticket Decomposition** - N tickets → N separate payments
5. **Name Matching (Levenshtein)** - ❌ **NOT POSSIBLE** (API limitation)
6. **Combination Analysis** - Multiple payments → single order total
7. **Closest Amount** - Find nearest Revolut per POS order

---

## KEY FINDINGS

### Matching Results (All Methods Combined)

| Method | Matches | Amount | Notes |
|--------|---------|--------|-------|
| Exact Match (±30 min) | 33 | £70,250 | Same amount + time proximity |
| Pair Match (combination) | 1 | £4,000 | Order #718: 2x £2,000 = £4,000 |
| Fuzzy Match (±5%) | 2 | £2,550 | Orders #725, #759 |
| **TOTAL MATCHED** | **36** | **£76,800** | 40.5% of POS value |

### Critical Discovery: Order #718

```
DB Order:     £4,000 (Yasser al saleh, 4x £1,000 tickets)
Revolut:      £2,000 at 15:54:52
              £2,000 at 15:55:09  (17 seconds later)
              ─────────────────
TOTAL:        £4,000 ✓ EXACT MATCH via 2 payments
```

**Proof that staff sometimes charged per-partial-amount rather than per-order total.**

### Amount Analysis Summary

| Category | Count | Amount | Notes |
|----------|-------|--------|-------|
| **SHARED** (exists in both) | ~36 | £94,350 | Matchable amounts |
| **DB-ONLY** (no Revolut) | 13 orders | £47,900 | Different terminal or unpaid |
| **REV-ONLY** (no DB) | 38 payments | £44,161 | Door sales without orders |
| **Gap** | - | £51,039 | DB higher than Revolut |

### DB-ONLY Amounts (Zero Revolut at these values)

| Amount | Count | Ticket Composition |
|--------|-------|-------------------|
| £7,800 | 1 | 4x VVIP @ £1,950 |
| £6,650 | 1 | 3x VIP + 2x BROWN |
| £5,550 | 2 | 3x VIP @ £1,850 |
| £4,350 | 4 | 3x BROWN @ £1,450 (dynamic pricing) |
| £1,100 | 4 | 2x BROWN @ £550 |
| £550 | 1 | 1x BROWN |

### REV-ONLY Amounts (Zero DB at these values)

| Amount | Count | Analysis |
|--------|-------|----------|
| £4,200 | 1 | Non-standard |
| £2,900 | 4 | Round, near £3,000 |
| £2,100 | 3 | Possibly 3x £700 |
| £1,000 | +excess | Door sales |
| £700 | 5 | Round manual entry |
| £500 | 11 | Standard ticket? |
| Various | 13 | Non-standard amounts |

---

## HYPOTHESIS EVALUATION (UPDATED)

| Hypothesis | Evidence | Verdict |
|------------|----------|---------|
| **A. Second terminal used** | £47,900 in DB-only amounts | **POSSIBLE** |
| **B. Wrong amounts entered** | Order #718 split 2x £2,000 | Partial evidence |
| **C. Never actually charged** | Cannot verify without cardholder | **LIKELY for some** |
| **D. Door sales without orders** | £44,161 in non-standard amounts | **STRONG** |

---

## REVOLUT API DETAILS

### Working Endpoint

```bash
curl -s "https://merchant.revolut.com/api/1.0/orders/{ORDER_ID}" \
  -H "Authorization: Bearer sk_91dAixyftAVd1Uy00makIiJ00liMejo9hELrfhuzwQqVLaS73RVHhXHds0len9NT" \
  -H "Accept: application/json" \
  -H "Revolut-Api-Version: 2024-09-01"
```

### API Versions Available

- 2023-09-01
- 2024-05-01
- 2024-09-01
- 2025-10-16
- 2025-12-04

### Authentication

- Bearer token from `.env` REVOLUT_API_KEY
- Base URL: `https://merchant.revolut.com/api/1.0`

---

## TIMELINE ANALYSIS: Orphaned Payments

### Payment Clusters (Potential Multi-Tap)

**Dec 30 15:54-15:55** (17 seconds):
- £2,000 at 15:54:52
- £2,000 at 15:55:09
- **→ Matches Order #718 (£4,000)**

**Dec 29 18:56-18:57** (65 seconds):
- 4x £700 payments
- **→ Could be 4 tickets @ £700 each**

**Dec 30 21:24-21:25** (61 seconds):
- 3x £500 payments
- **→ Could be 3 tickets @ £500 each**

---

## FILES CREATED/UPDATED

### Local (`/Users/charlie/code/showprima/storage/audit/`)

| File | Purpose |
|------|---------|
| `SESSION_SUMMARY_2026-01-06.md` | This session summary |
| `DEEP_RECONCILIATION_FINAL_2026-01-06.md` | Complete analysis report |
| `POS_DISCREPANCY_ANALYSIS_2026-01-06.md` | Initial discrepancy breakdown |

### Server (`storage/audit/`)

| File | Purpose |
|------|---------|
| `pos_orders_detailed.json` | All 97 POS orders with ticket details |
| `revolut_all_completed.json` | 500 Revolut payments (from Jan 5) |
| `orphaned_with_cardholders.json` | 148 orphaned payments |

---

## CONCLUSIONS

### What We Can Prove

1. **36 matches confirmed** (£76,800 = 40.5% of POS value)
2. **Staff split payments** - Order #718 proved 2x £2,000 pattern
3. **Door sales occurred** - £44,161 in Revolut without DB orders
4. **Some orders unaccounted** - £47,900 in DB with no matching Revolut

### What We Cannot Prove (API Limitation)

1. ❌ **Cardholder ↔ Customer name matching** - Not available for POS payments
2. ❌ **Which card was used** - No card details for CARD_PRESENT
3. ❌ **Definitive payment verification** - Can only match by amount+time

### Recommendations

1. **MBS Terminal Cross-Reference**: Get terminal batch report to identify secondary terminal usage
2. **Customer Spot-Check**: Contact 3-5 customers from DB-ONLY orders to verify payment method
3. **Accept Reconciliation Gap**: £51,039 gap is structural (door sales + untracked orders)
4. **Process Improvement**: Require order creation before payment, disable Custom Amount

---

## KEY INSIGHT

**Single Terminal Assumption ≠ Guaranteed Matching**

Even with a single Revolut terminal:
- Payments can be charged under different amounts (staff discretion)
- Payments can be split (2x £2,000 instead of 1x £4,000)
- Orders can be created without actual payment
- Payments can be taken without order creation

**Without cardholder name matching, definitive reconciliation is impossible for POS transactions.**

---

*Session completed 6 January 2026*
*Revolut API limitation confirmed: No cardholder data for CARD_PRESENT payments*