Після підтвердження оплати користувач часто стикається із затримкою доступу через асинхронну обробку платежів. Race condition між webhook та redirect session призводить до розсинхрону статусів — enrollment не створюється, хоча платіж успішний. На 20+ проектах ми вирішили цю проблему за допомогою ідемпотентних webhook-хендлерів та черг. Середній час доступу — 2.3 секунди, а економія на скасуваннях — до 25% за рахунок миттєвої видачі доступу після верифікації. Вартість інтеграції розраховується індивідуально і зазвичай виявляється на 15–20% нижчою за ринкову завдяки використанню перевірених компонентів. Ми гарантуємо, що ваш контент буде захищено, а користувачі отримають доступ без затримок.
Як уникнути race condition при видачі доступу?
Типова помилка — синхронна видача доступу після редиректу з платіжного шлюзу. Користувач натиснув кнопку, потрапив на success-сторінку, отримав доступ — а платіж не пройшов. Доступ видається тільки через webhook, інакше бізнес втрачає виручку. Ми гарантуємо коректну логіку: enrollment створюється тільки після верифікації платежу через Stripe webhook signature verification.
Архітектура:
[Користувач] → [Checkout] → [Payment Gateway] ↓ [Webhook Handler] ↓ [Enrollment Service] → [DB: enrollments] ↓ [Access Control Layer] ↓ [LMS / Video Delivery / Downloads] Критично важливий webhook handler — саме він створює запис про доступ після підтвердження оплати. Ідемпотентність: enrollment-запис створюється з унікальним індексом по (user_id, course_id), другий виклик просто повертає існуючий запис.
Порівняння платіжних шлюзів: Stripe vs ЮKassa
| Шлюз | Час обробки webhook | Захист від повторів | Вартість інтеграції (відносно) |
|---|---|---|---|
| Stripe | ~1 сек | вбудована ідемпотентність | базова |
| ЮKassa | ~2-3 сек | через унікальний ключ платежу | на 30% вища |
Stripe webhook обробка швидша за ЮKassa в ~2 рази за часом відгуку, що критично при високому навантаженні. Для рунету ЮKassa більш прийнятна через локалізацію та підтримку популярних методів оплати.
Чому signed URLs не гарантують безпеку без правильної конфігурації?
Якщо термін життя посилання занадто великий або не прив'язаний до конкретного користувача, контент може витекти. Ми використовуємо signed URL з терміном 2 години та прив'язкою до IP користувача. Для преміум-курсів використовуємо Mux з адаптивним стрімінгом (HLS) та signed playback tokens.
$url = $s3->createPresignedRequest( $s3->getCommand('GetObject', [ 'Bucket' => 'courses-bucket', 'Key' => "courses/{$courseId}/lesson-{$lessonId}.mp4", ]), '+2 hours' )->getUri(); Детальніше про signed URLs читайте в офіційній документації AWS.
Управління доступом та прогрес
Таблиця enrollments:
| Поле | Тип | Опис |
|---|---|---|
| id | uuid | первинний ключ |
| user_id | bigint | FK → users |
| course_id | bigint | FK → courses |
| payment_id | varchar | ID транзакції зі шлюзу |
| expires_at | timestamp | NULL = безстроково |
| status | enum | active / suspended / refunded |
| created_at | timestamp | дата покупки |
Middleware на кожному захищеному маршруті перевіряє наявність активного запису:
// Laravel Gate Gate::define('access-course', function (User $user, Course $course) { return $user->enrollments() ->where('course_id', $course->id) ->where('status', 'active') ->where(function ($q) { $q->whereNull('expires_at') ->orWhere('expires_at', '>', now()); }) ->exists(); }); Прогрес навчання відстежується через lesson_progress(user_id, lesson_id, completed_at, watch_percent). Сертифікат генерується автоматично, коли watch_percent >= 80 для всіх уроків курсу.
Додаткові механізми
Пробний доступ (preview)
Перші 1-2 уроки зазвичай відкриті без оплати. Прапорець `is_free_preview` на рівні уроку, перевірка в middleware. Якщо урок не безкоштовний і немає enrollment, користувач перенаправляється на сторінку покупки.Повернення
При поверненні платежу Stripe надсилає `charge.refunded`. Змінюємо `enrollments.status = 'refunded'`, користувач втрачає доступ миттєво. Для ЮKassa — аналогічний webhook `payment.canceled`.Моніторинг та тестування
Для забезпечення надійності ми налаштовуємо моніторинг webhook-сповіщень: кожен збій логується, і команда отримує алерт у Telegram. Це дозволяє реагувати на проблеми до того, як вони вплинуть на користувачів. Перед запуском проводимо навантажувальне тестування — створюємо 100+ паралельних платежів і перевіряємо, що всі enrollment створюються коректно без race condition.
Що входить у результат
- Інтеграція платіжного шлюзу (Stripe, ЮKassa, Robokassa) з webhook-обробкою
- Система enrollment з перевіркою доступу через middleware
- Захищена відеодоставка (signed URLs / Mux)
- Відстеження прогресу зі збереженням відсотка перегляду
- Генерація сертифікатів PDF
- Адміністративна панель для керування enrollment та поверненнями
- Документація API та посібник з експлуатації
- Технічна підтримка на етапі запуску
- Моніторинг webhook-сповіщень та алерти при збоях
Терміни реалізації
| Етап | Час |
|---|---|
| Базова інтеграція Stripe + enrollment | 2–3 дні |
| Захищена відеодоставка (S3 signed URL) | 1–2 дні |
| Відстеження прогресу + UI прогрес-бару | 1–2 дні |
| Сертифікати (PDF-генерація) | 1 день |
| Інтеграція ЮKassa / другий шлюз | 1–2 дні |
| Адміністративна панель (enrollments, revenue) | 2–3 дні |
Разом мінімальна робоча версія — за 7–10 робочих днів під ключ. Замовте інтеграцію платежів для вашого курсу — це підвищить конверсію та знизить навантаження на підтримку. Отримайте консультацію щодо вибору платіжного шлюзу та архітектури доступу.