Pre-launch findings

What's wrong

The endpoint that returns a customer's bookings doesn't check who is asking. Supply any phone number in the URL and it returns that customer's record — no login, no token, no ownership check. Because phone numbers are guessable, the entire customer base can be walked one request at a time.

How to reproduce

1. Open a private browser window and confirm you are not logged in.
2. Request the customer bookings endpoint with any registered phone number in the path.
3. Observe a complete customer record in the response.
4. Change the phone number and repeat to retrieve a different customer.

# No authentication header of any kind
GET /api/customer/bookings/%2B15550100123
Host: api.bookwell-demo.example

# Response — 200 OK
{
  "customers": [{
    "firstName": "[CUSTOMER NAME]",
    "phoneNumber": "[PHONE]",
    "venueId": "[ID]"
  }],
  "bookings": [{
    "status": "scheduled",
    "scheduledTime": "2026-07-02T03:30:00.000Z",
    "paymentStatus": "paid",
    "paymentMethod": "card",
    "price": 400,
    "customerInfo": { "name": "[NAME]", "phone": "[PHONE]" }
  }]
}

Note: values above are redacted placeholders. In a real report this block contains the actual response so your developer can confirm the problem in seconds.

What's exposed

• Customer name and phone number
• Full booking history with dates and services
• Prices paid, payment status and payment method
• Internal customer and venue identifiers

Why it matters

What to change

What's wrong

The custom tip field has no maximum and no format validation. Entering an absurdly large number is accepted without error, and the order total is then rendered in scientific notation rather than as currency.

How to reproduce

1. Add any service to the basket and go to checkout.
2. Choose Custom under the tip options.
3. Enter 100000000000000000000000000000.
4. Observe the order total.

Service subtotal   $40.00
Custom tip         100000000000000000000000000000
Order total        $1e+30       ← accepted, no error

Expected

The field should accept currency only — digits with at most two decimal places — enforce a sensible maximum, and reject anything else with a clear message. A monetary total should never render in scientific notation.

Why it matters

What to change

What's wrong

A complimentary reward set up for one specific service can be redeemed against any other service, including more expensive ones. The booked service is never checked against the reward's configuration.

How to reproduce

1. Create a loyalty reward for a low-priced service (a $30 service).
2. Unlock the reward on a test customer account.
3. As that customer, book a different, higher-priced service (a $95 service).
4. Apply the reward at checkout.

Reward configured for:  Service A  ($30)
Customer books:        Service B  ($95)
Reward applied:        accepted — Service B becomes free
Margin lost:           $95 instead of the intended $30

Why it matters

What to change