How the booking experience uses information

This page describes the categories of information and operational uses visible in Singh's Black Car SUV's current booking, waitlist, contact, dispatch, and hosted-payment flows. It does not add practices that are not established by the app.

Effective / last updated: Owner confirmation required — no effective date has been established yet.

1. Information collected

Depending on the flow you use, the app asks for:

Booking: name, email, phone, pickup location, drop-off location, pickup time, vehicle class, stops, and wait estimates.
Waitlist: email address, pickup location, and drop-off location.
Contact form: name, email address, and message.
Booking edit and live-trip links: the opaque link token or URL needed to open the requested booking or trip status page.

2. Operational uses

The app uses submitted information for the operations visible in the product, including:

creating and maintaining a booking and its status history;
dispatch review, driver assignment, pickup coordination, and live trip status;
sending and honoring edit or cancellation links and showing a shareable trip-status page;
responding to contact requests and booking support needs;
maintaining a waitlist request and contacting a person when the flow says a driver is available.

3. Communications

Booking and dispatch details may be used for email and calls needed to operate or coordinate a trip. If you choose the optional SMS consent in the booking flow, texts may include ride confirmations and status/ETA updates. Message frequency varies by ride, message and data rates may apply, and you can reply HELP for help or STOP to opt out. Consent is not required to book.

4. Hosted payment flows

The booking edit flow can offer a deposit, full prepayment, or an inside-the-window cancellation-fee checkout when those paths are enabled. The app hands the customer to hosted Stripe Checkout for those flows. The repository does not establish the complete payment-data, provider-recipient, refund, or dispute disclosures, so those details remain placeholders.

5. Page-load beacon

When the deployment provides the analytics configuration, the app's page-load beacon creates or reuses a local visitor ID named polsia_vid and sends the configured app slug and visitor ID to the configured Polsia beacon endpoint. This is an observed conditional behavior; the repository does not establish a broader cookies or analytics policy.

6. Sharing and retention

The current app code does not establish a complete list of service providers or recipients, international-transfer language, retention periods, or a deletion process. Those matters are intentionally listed for owner confirmation rather than described as settled policy.

7. Privacy questions and requests

The repository does not establish a final rights-request process or privacy contact. For now, policy questions can be directed to singhs-black-car-suv@polsia.app. The owner should replace this with the approved privacy contact and request process.

8. Booking

Review the Terms & Conditions and return to the booking flow when you are ready.

Placeholders to confirm

The following material privacy details are not established by the current app:

The legal business identity and public privacy contact address.
Service providers and recipient categories, including the approved Stripe and email disclosures.
Data retention periods, deletion rules, and the process for requesting deletion.
International transfer language, if applicable.
Applicable privacy rights and the process, identity checks, and response timing for requests.
Cookies, local storage, analytics choices, and any consent controls beyond the observed beacon.
The owner still needs to configure the live SMS provider, sender identity, A2P registration, and delivery operations; no sender number or delivery schedule is promised here.
The effective and last-updated date.