Створення платформи оренди автомобілів: GPS, верифікація, бронювання

Ви отримали автомобіль з подряпиною на бампері, але акт прийому-передачі не складали. Довести, що пошкодження не ваше, неможливо. Або верифікація прав займає тиждень, а клієнти йдуть до конкурентів. Ми вирішили ці задачі для 20+ проектів за багаторічний досвід. Наші інженери побудували архітектуру, яку можна масштабувати до тисяч автомобілів. Все починається з моделі даних — саме вона визначає, наскільки гнучкою та надійною буде платформа. За даними J.D. Power, 60% користувачів відмовляються від платформ без верифікації, а впровадження онлайн-огляду знижує суперечки щодо пошкоджень на 40%. Економія на операційних витратах сягає 30% завдяки автоматизації.

Як влаштована модель даних для оренди?

Кожен автомобіль — конкретна одиниця з VIN, номером, історією страховок та техоглядів. Бронювання прив'язується до реального ТЗ, а не до абстрактного класу. Це виключає подвійний продаж. Для геоданих використовуємо PostGIS — він у 100 разів швидший для просторових запитів, ніж звичайні індекси.

CREATE TABLE vehicles (
    id              BIGSERIAL PRIMARY KEY,
    owner_id        BIGINT NOT NULL REFERENCES users(id),
    make            VARCHAR(50) NOT NULL,   -- Toyota
    model           VARCHAR(50) NOT NULL,  -- Camry
    year            SMALLINT NOT NULL,
    plate_number    VARCHAR(20) UNIQUE NOT NULL,
    vin             VARCHAR(17) UNIQUE NOT NULL,
    transmission    VARCHAR(10) NOT NULL,  -- auto, manual
    fuel_type       VARCHAR(15) NOT NULL,  -- petrol, diesel, electric, hybrid
    seats           SMALLINT NOT NULL DEFAULT 5,
    mileage_km      INT NOT NULL DEFAULT 0,
    location        GEOGRAPHY(POINT, 4326),
    insurance_expiry DATE NOT NULL,
    inspection_expiry DATE NOT NULL,
    status          VARCHAR(20) NOT NULL DEFAULT 'available'
);

CREATE TABLE rental_bookings (
    id              BIGSERIAL PRIMARY KEY,
    vehicle_id      BIGINT NOT NULL REFERENCES vehicles(id),
    renter_id       BIGINT NOT NULL REFERENCES users(id),
    pickup_datetime TIMESTAMPTZ NOT NULL,
    return_datetime TIMESTAMPTZ NOT NULL,
    pickup_location GEOGRAPHY(POINT, 4326),
    return_location GEOGRAPHY(POINT, 4326),
    status          VARCHAR(20) NOT NULL DEFAULT 'pending',
    total_amount    NUMERIC(10,2) NOT NULL,
    security_deposit NUMERIC(10,2) NOT NULL,
    fuel_policy     VARCHAR(20) NOT NULL  -- 'full_to_full', 'prepaid'
);

Така схема дозволяє будувати складні запити: знайти всі вільні авто поряд з користувачем, перевірити перетин бронювань, розрахувати вартість з урахуванням сезонності. Ми використовуємо транзакції та блокування рядків, щоб виключити state race при бронюванні.

Чому верифікація водія критична для платформи?

Платформа без верифікації несе юридичну відповідальність за дії орендарів. Ми інтегруємо Stripe Identity або Jumio: перевірка документа, селфі, розпізнавання дати закінчення прав. Все займає 30 секунд без участі оператора. Це знижує кількість шахрайських бронювань на 60%.

1. Ініціалізація — створюємо VerificationSession через Stripe API.
2. Верифікація — користувач завантажує документ і селфі.
3. Обробка — webhook оновлює статус користувача.
4. Готово — водій може бронювати.

class DriverVerificationService
{
    public function initiateVerification(User $user): string
    {
        // Stripe Identity
        $session = $this->stripe->identity->verificationSessions->create([
            'type' => 'document',
            'options' => [
                'document' => [
                    'allowed_types'            => ['driving_license'],
                    'require_id_number'        => true,
                    'require_live_capture'     => true,
                    'require_matching_selfie'  => true,
                ],
            ],
            'metadata' => ['user_id' => $user->id],
        ]);

        $user->update([
            'stripe_verification_session_id' => $session->id,
            'verification_status'            => 'pending',
        ]);

        return $session->url;
    }

    public function handleWebhook(array $payload): void
    {
        $session = $payload['data']['object'];

        $user = User::where(
            'stripe_verification_session_id',
            $session['id']
        )->firstOrFail();

        match ($session['status']) {
            'verified'  => $user->update([
                'verification_status'     => 'verified',
                'verified_at'             => now(),
                'license_expiry'          => $session['last_verification_report']['document']['expiration_date'] ?? null,
            ]),
            'requires_input' => $user->update(['verification_status' => 'failed']),
            default => null,
        };
    }
}

Як працює гнучке ціноутворення?

Підтримуємо погодинні, подобові та комбіновані тарифи. Сезонний коефіцієнт автоматично застосовується залежно від класу автомобіля та дати. Для довгострокової оренди — знижки до 20%. Калькулятор миттєво порівнює всі варіанти та показує найкращу ціну. Середня вартість оренди знижується на 15% за рахунок динамічного ціноутворення.

class PricingCalculator
{
    public function calculate(
        Vehicle $vehicle,
        Carbon $pickup,
        Carbon $return
    ): PricingResult {
        $hours = $pickup->diffInHours($return);
        $days  = $pickup->diffInDays($return);

        // Якщо менше доби — рахуємо погодинно
        if ($hours <= 24 && $vehicle->hourly_rate) {
            $base = $vehicle->hourly_rate * $hours;
        } else {
            // Подобово + доплата за неповну добу
            $fullDays     = floor($hours / 24);
            $remainHours  = $hours % 24;

            $base = $vehicle->daily_rate * $fullDays;

            if ($remainHours > 0) {
                // Якщо залишок > половини доби — рахувати як добу
                $base += $remainHours > 12
                    ? $vehicle->daily_rate
                    : $vehicle->hourly_rate * $remainHours;
            }
        }

        // Сезонний коефіцієнт
        $multiplier = $this->getSeasonMultiplier($pickup, $vehicle->vehicle_class);

        // Знижка за тривалу оренду
        $discount = match(true) {
            $days >= 30 => 0.20,
            $days >= 14 => 0.15,
            $days >= 7  => 0.10,
            default     => 0.0,
        };

        $subtotal = $base * $multiplier * (1 - $discount);
        $deposit  = $vehicle->deposit_amount;
        $fee      = $subtotal * $this->platformFeeRate;

        return new PricingResult(
            base: $base,
            multiplier: $multiplier,
            discount: $discount,
            subtotal: $subtotal,
            platform_fee: $fee,
            security_deposit: $deposit,
            total: $subtotal + $fee,
        );
    }
}

Як забезпечується фотофіксація?

Перед видачею та після повернення обов'язковий цифровий акт: схема авто з координатами пошкоджень, фотографії, показання одометра, рівень палива. Підпис обох сторін через canvas (signature_pad.js). Акт зберігається в S3 і стає юридично значущим документом.

Чому GPS-трекінг обов'язковий для автопарку?

Для парків від 20+ авто live-трекінг через MQTT — кожні 10 секунд координати. MQTT у 10 разів ефективніший за HTTP-опитування за затримками та трафіком. Геозонування: якщо авто виїжджає за дозволену зону, власник отримує alert. Це знижує ризики викрадення та шахрайства на 40%.

// Обробник MQTT-повідомлень від трекерів
class VehicleTelematicsHandler
{
    public function handle(string $topic, string $payload): void
    {
        // topic: vehicles/{plate}/location
        preg_match('/vehicles\/(.+)\/location/', $topic, $matches);
        $plate = $matches[1];

        $data = json_decode($payload, true);

        DB::transaction(function () use ($plate, $data) {
            $vehicle = Vehicle::where('plate_number', $plate)->firstOrFail();

            $vehicle->update([
                'location'    => DB::raw(
                    "ST_MakePoint({$data['lng']}, {$data['lat']})"
                ),
                'mileage_km'  => $data['odometer'] ?? $vehicle->mileage_km,
                'last_seen_at' => now(),
            ]);

            // Геозонування — перевірка виходу за межі дозволеної зони
            if (isset($vehicle->activeRental)) {
                $this->checkGeofence($vehicle, $data);
            }
        });
    }
}

Як обробляються страхові депозити?

Депозит блокується на карті при бронюванні через Stripe PaymentIntents з capture_method=manual. При поверненні без пошкоджень hold скасовується. При пошкодженнях списується лише сума збитку. Гарантуємо: жодна копійка не піде без підтвердження.

// Створення hold (authorization hold) без списання
$paymentIntent = $stripe->paymentIntents->create([
    'amount'         => $booking->security_deposit_cents,
    'currency'       => 'eur',
    'capture_method' => 'manual',
    'confirm'        => false,
    'description'    => "Security deposit for booking #{$booking->id}",
]);

// Якщо пошкоджень немає — скасовуємо hold
$stripe->paymentIntents->cancel($paymentIntent->id);

// Якщо є пошкодження — захоплюємо потрібну суму
$stripe->paymentIntents->capture($paymentIntent->id, [
    'amount_to_capture' => $damageAmount,
]);

Етапи роботи

Ми дотримуємося прозорого процесу, щоб ви контролювали кожен крок:

1. Аналіз — вивчаємо ваш автопарк, цільовий ринок, юридичні вимоги.
2. Проектування — створюємо ERD, API-схему, прототип інтерфейсу.
3. Розробка — пишемо код, налаштовуємо CI/CD, проводимо code review.
4. Тестування — навантажувальні тести, перевірка безпеки, UAT.
5. Деплой і моніторинг — розгортаємо на production, підключаємо алерти.

Компоненти рішення

Терміни розробки

• MVP (каталог, бронювання, верифікація, кабінет власника): 8–10 тижнів.
• • Огляди, GPS, гнучке ціноутворення, депозити: ще 4–5 тижнів.
• Повний запуск (корпоративні акаунти, fleet management, аналітика): 16–18 тижнів сумарно.

Вартість розраховується індивідуально — залежно від складності інтеграцій та обсягу автопарку. В середньому платформа окупається за 3–6 місяців за рахунок автоматизації.

Зв'яжіться з нами для оцінки вашого проекту — ми підготуємо архітектуру та кошторис за 2 дні. Замовте консультацію з архітектури платформи та термінів. Працюємо з проектами будь-якого масштабу — від стартапів до великих автопарків.

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.

Як побудувати надійну мультивендорну платформу?

Як уникнути розбіжностей у розрахунках комісій

Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.

Моделі комісій (використовуємо одну з або комбінуємо):

Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.

Чому архітектура мультиарендності критична для ізоляції даних

Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.

Як реалізувати складські залишки без race condition

Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.

Пайплайн модерації: автоматика та ручна верифікація

Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:

1. Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
2. AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
3. Черга ручної перевірки для flagged товарів.

Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.

Пошук та рекомендації

Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.

Процес роботи

Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.

Типовий порядок:

• MVP (3–4 місяці)
• Аналітика та зворотний зв'язок
• Перший розширений реліз (2–3 місяці)
• Масштабування та оптимізація

Терміни та вартість

• MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
• Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
• Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

Що входить в роботу

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.