Приём оплат без платформы: как это устроено и что учесть

Платформы для продажи курсов берут процент и держат твою базу у себя. Понятно, за что: они решают оплату, выдачу и доступ.

Но если продукт простой, вся эта конструкция собирается своими руками. Разберу, из чего она состоит и где обычно ломается.

Из чего состоит цепочка

Пять звеньев, и каждое можно сделать неправильно.

1. Кнопка. Человек нажимает купить.
2. Платёж. Уходит на страницу оплаты, платит.
3. Подтверждение. Платёжный сервис сообщает тебе, что деньги пришли.
4. Выдача. Ты открываешь доступ к продукту.
5. Запись. Факт покупки сохраняется, чтобы человек не потерял доступ завтра.

Большинство самодельных решений ломается на третьем и пятом.

Почему редирект — не подтверждение

Самая частая ошибка новичков. Логика кажется очевидной: человек оплатил, его вернуло на страницу «спасибо», значит платёж прошёл — выдаём доступ.

Так делать нельзя. Страницу «спасибо» можно открыть напрямую, скопировав ссылку. Человек может закрыть вкладку до возврата — оплата прошла, доступа нет. Возврат может не сработать из-за сети.

Правильный источник правды — вебхук: платёжный сервис сам стучится на твой адрес и сообщает, что платёж состоялся. Это сообщение приходит от сервиса к тебе, а не через браузер покупателя, и его нельзя подделать открытием ссылки.

Редирект нужен только чтобы человеку было приятно. Решение о выдаче принимается по вебхуку.

Что обязательно проверять в вебхуке

Проверка	Зачем
Подпись запроса	иначе доступ выдаст любой, кто узнал адрес
Сумма платежа	защита от подмены на меньшую
Статус «успешно»	приходят и уведомления об отказе
Повтор того же платежа	сервисы дублируют уведомления, выдавать дважды не надо
Идентификатор заказа	связать платёж с конкретным человеком

Первая строка — не паранойя. Адрес вебхука рано или поздно попадёт в чужие руки, и без проверки подписи это означает бесплатную раздачу продукта.

Как связать платёж с человеком

Задача менее очевидная, чем кажется: платёжный сервис знает про карту, но ничего не знает про твоего подписчика.

Решается идентификатором заказа. Перед оплатой ты создаёшь запись: кто покупает, что покупает, уникальный номер. Этот номер уезжает в платёжную ссылку и возвращается в вебхуке — по нему ты и понимаешь, кому открывать доступ.

Без этой связки начинается ручной разбор: пришли деньги, а от кого — неизвестно.

Выдача доступа

Три способа, от простого к надёжному.

Ссылка в ответ. Проще всего, но ссылку перешлют друзьям. Годится для дешёвых продуктов, где утечка не критична.

Персональная ссылка с ограничением. Одноразовая или привязанная к человеку. Сложнее, зато не расходится.

Доступ в закрытое место. Приглашение в канал или кабинет. Надёжнее всего и заодно оставляет человека рядом с тобой.

Выбор зависит от цены продукта: городить сложное вокруг дешёвого микро-продукта не стоит.

Что записывать обязательно

Покупка — это не разовое событие, а факт, который живёт дальше.

• кто купил и когда;
• что именно и за сколько;
• идентификатор платежа — для разбора спорных случаев;
• статус выдачи: доступ открыт или нет.

Последняя строка нужна для восстановления. Человек потерял ссылку, сменил устройство, написал через месяц — по записи ты за секунду выдаёшь доступ снова. Без записи начинается «пришлите скриншот оплаты».

И ещё: покупатели не должны попадать в цепочку дожимов «купи». Отметка о покупке избавляет от неловкости, когда человеку, который заплатил вчера, приходит предложение купить.

Порядок сборки

1. Подключить платёжный сервис, получить ключи.
2. Сделать создание заказа: запись в базе с уникальным номером.
3. Собрать ссылку на оплату с этим номером.
4. Поднять обработчик вебхука с проверкой подписи и суммы.
5. Сделать выдачу доступа и запись факта покупки.
6. Прогнать весь путь настоящей оплатой на минимальную сумму.

Шестой шаг обязателен. Тестовый режим платёжных сервисов не воспроизводит всё: боевой платёж на сто рублей ловит то, что тест пропускает.

Где эта конструкция ломается в жизни

Четыре случая, каждый из которых я видел.

Вебхук не дошёл. Сервер лежал, сеть моргнула — уведомление не пришло, деньги списаны, доступа нет. Лечится тем, что платёжные сервисы повторяют попытки: обработчик должен отвечать корректно, иначе повторов не будет. Плюс полезно раз в сутки сверять список платежей с выданными доступами.

Двойная выдача. Уведомление пришло дважды, доступ выдался дважды, человек получил два приглашения и запутался. Лечится проверкой «этот платёж уже обработан».

Оплатил один, доступ нужен другому. Покупают в подарок или с чужой карты. Если связка идёт через карту, а не через идентификатор заказа, начинается ручной разбор.

Возврат. Человек вернул деньги, а доступ остался. Отзыв доступа — отдельный шаг, о котором вспоминают только когда это уже случилось.

Общий вывод: цепочка оплаты — это не «прикрутить кнопку», а маленькая система с состояниями. Заложи час на обработку неудачных сценариев, и она будет работать годами.

Частые вопросы

Можно ли принимать оплаты без платформы для курсов?

Да, если продукт простой. Нужны платёжный сервис, обработчик уведомлений о платеже и место, куда выдавать доступ. Платформа полезна, когда появляются тарифы, рассрочки и большой каталог.

Почему нельзя выдавать доступ по возврату на страницу «спасибо»?

Потому что эту страницу можно открыть напрямую, не платя. Единственный надёжный источник — уведомление от платёжного сервиса на твой адрес, с проверкой подписи.

Что делать, если человек потерял доступ?

Найти его в записи покупок и выдать заново. Именно для этого факт покупки сохраняется отдельно, а не только в момент выдачи.

Что проверять в уведомлении о платеже?

Подпись запроса, сумму, статус и то, не обрабатывал ли ты этот платёж раньше. Дубли уведомлений — нормальное поведение платёжных сервисов.